diff --git a/apps/api/tests/unit/deployments/test_techniques_not_stale.py b/apps/api/tests/unit/deployments/test_techniques_not_stale.py
index aec771b962a..3f204567dcf 100644
--- a/apps/api/tests/unit/deployments/test_techniques_not_stale.py
+++ b/apps/api/tests/unit/deployments/test_techniques_not_stale.py
@@ -1,26 +1,27 @@
-"""Fitness guard: a beamline's techniques.md cannot call an AUTHORED Method pending.
+"""Fitness guard: a beamline's Techniques section cannot call an AUTHORED Method pending.
 
-The per-beamline `docs/deployments/<id>/techniques.md` pages are hand-authored
-intent prose (unlike the generated `beamline.md`). When a technique was cited as
-"a new Method, pending (TECH-1)" and that Method is later authored into the
-catalog (the operations-layer re-derivation Lock 1), the page rots: it describes
-a future that already arrived.
+The per-beamline `docs/deployments/<id>/notes.md` pages are hand-authored intent
+prose (unlike the generated `beamline.md`), and each carries a `## Techniques`
+section. When a technique was cited as "a new Method, pending (TECH-1)" and that
+Method is later authored into the catalog (the operations-layer re-derivation
+Lock 1), the section rots: it describes a future that already arrived.
 
-This guard catches that specific drift. A techniques.md table row is STALE when
-it both:
+This guard catches that specific drift. A Techniques-section table row is STALE
+when it both:
   - cites a backtick method slug that now exists in `catalog/catalog.yaml`, and
   - frames that row as not-yet-real (pending / "new Method" / "not yet in
     catalog" / a bare TECH-tag).
 
 A stale row must be either fixed (drop the pending framing now that the Method
 exists) or listed in `_KNOWN_STALE` below. `_KNOWN_STALE` is an enumerated
-backlog: the rows already stale when Lock 1 landed, deliberately left for the
-in-flight beamline-page redesign to clear (that work regenerates these pages, so
-hand-editing them now would churn / collide). The guard's value is catching NEW
-drift: a newly-authored Method whose citing page still says pending fails the
-build unless explicitly parked here.
-
-Keyed by (beamline, method_slug). Removing an entry once its page is fixed is
+backlog: the rows already stale when Lock 1 landed, deliberately left for a
+future content pass to clear (the four hand-authored pages per beamline were
+merged into one `notes.md` afterward, a structural move only; it did not touch
+row content, so the backlog carries over unchanged). The guard's value is
+catching NEW drift: a newly-authored Method whose citing row still says pending
+fails the build unless explicitly parked here.
+
+Keyed by (beamline, method_slug). Removing an entry once its row is fixed is
 required: a _KNOWN_STALE entry that is no longer stale fails the no-dead-entry
 check, so the backlog cannot rot silent.
 """
@@ -51,10 +52,11 @@
     re.IGNORECASE,
 )
 _SLUG = re.compile(r"`([a-z][a-z0-9_]+)`")
+_SECTION = re.compile(r"^## (.+)$", re.MULTILINE)
 
 # Rows already stale when Lock 1 landed (2026-07-02): the page cites a now-authored
-# Method but still frames it pending. Backlog for the beamline-page redesign to
-# clear; each removal is verified by the no-dead-entry check below.
+# Method but still frames it pending. Backlog for a future content pass to clear;
+# each removal is verified by the no-dead-entry check below.
 _KNOWN_STALE: set[tuple[str, str]] = {
     ("13-id", "powder_diffraction"),
     ("cdi", "ptychography"),
@@ -92,13 +94,31 @@ def _catalog_methods() -> set[str]:
     return {m.name for m in catalog_descriptor.load(_CATALOG).methods}
 
 
+def _techniques_section(notes_text: str) -> str:
+    """The `## Techniques` section body, up to the next `## ` heading or EOF.
+
+    notes.md carries Techniques, Governance, Model, and Open questions as
+    sibling sections; Open questions has its own pipe-table rows that must not
+    leak into this scan (a "pending" confirmation there is not a stale Method
+    citation).
+    """
+    headings = list(_SECTION.finditer(notes_text))
+    for i, m in enumerate(headings):
+        if m.group(1).strip() != "Techniques":
+            continue
+        end = headings[i + 1].start() if i + 1 < len(headings) else len(notes_text)
+        return notes_text[m.end() : end]
+    return ""
+
+
 def _stale_rows() -> set[tuple[str, str]]:
-    """Every (beamline, authored-method-slug) whose techniques.md row is stale."""
+    """Every (beamline, authored-method-slug) whose Techniques row is stale."""
     methods = _catalog_methods()
     stale: set[tuple[str, str]] = set()
-    for techniques_md in sorted(_DEPLOYMENTS_DOCS.glob("*/techniques.md")):
-        beamline = techniques_md.parent.name
-        for line in techniques_md.read_text(encoding="utf-8").splitlines():
+    for notes_md in sorted(_DEPLOYMENTS_DOCS.glob("*/notes.md")):
+        beamline = notes_md.parent.name
+        section = _techniques_section(notes_md.read_text(encoding="utf-8"))
+        for line in section.splitlines():
             if not line.startswith("| ") or not _PENDING_PHRASE.search(line):
                 continue
             for slug in _SLUG.findall(line):
@@ -108,14 +128,18 @@ def _stale_rows() -> set[tuple[str, str]]:
 
 
 def test_techniques_pages_discovered() -> None:
-    pages = list(_DEPLOYMENTS_DOCS.glob("*/techniques.md"))
-    assert len(pages) >= 80, f"expected the full fleet of techniques.md, found {len(pages)}"
+    pages = [
+        p
+        for p in _DEPLOYMENTS_DOCS.glob("*/notes.md")
+        if _techniques_section(p.read_text(encoding="utf-8"))
+    ]
+    assert len(pages) >= 80, f"expected the full fleet of Techniques sections, found {len(pages)}"
 
 
 def test_no_new_stale_technique_rows() -> None:
     new_stale = sorted(_stale_rows() - _KNOWN_STALE)
     assert not new_stale, (
-        "techniques.md row(s) call a Method 'pending' / 'new' / 'not in catalog' that now "
+        "notes.md Techniques row(s) call a Method 'pending' / 'new' / 'not in catalog' that now "
         "EXISTS in catalog/catalog.yaml. Drop the pending framing now the Method is authored, "
         "or add to _KNOWN_STALE with intent:\n"
         + "\n".join(f"  {bl}: `{slug}`" for bl, slug in new_stale)
diff --git a/docs/deployments/12-id/governance.md b/docs/deployments/12-id/governance.md
deleted file mode 100644
index 0cd8116a0b1..00000000000
--- a/docs/deployments/12-id/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 12-ID, and the trust shape that will gate it. First cut.*
-
-Governance at 12-ID follows the same model as the other APS beamlines: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-12-ID is not yet driven by CORA, so this shape is not yet instantiated. As a reverse-engineered scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The instrument config exposes device tables, not the human roster, so the APS operator pool and safety-review structure is carried pending at the [APS Site](../aps/index.md#safety-and-governance), shared across the beamlines (`GOV-1`).
-
-The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the instrument config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 12-ID adds the hazard classes that come with a hard X-ray USAXS endstation under vacuum and the in-situ temperature environments at the sample (the Linkam T96 and PTC10 stages, `TEMP-1`); those land with the instruments that bring them, and an experiment Clearance would carry them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 12-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/12-id/model.md b/docs/deployments/12-id/model.md
deleted file mode 100644
index 795dfb5edf7..00000000000
--- a/docs/deployments/12-id/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 12-ID content lives, the first Bonse-Hart USAXS deployment that coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 12-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes 12-ID new
-
-12-ID is CORA's first Bonse-Hart ultra-small-angle X-ray scattering (USAXS) beamline. The fleet already has pinhole small- and wide-angle scattering (i22, 8-ID), grazing-incidence scattering (9-ID), total scattering and powder diffraction (i15-1, i11), and coherent XPCS (8-ID, CHX), but no crystal-analyzer USAXS. The novelty is the acquisition shape: a matched pair of channel-cut crystal stages, the collimator upstream of the sample and the analyzer downstream, is rocked through the Bragg condition while a single photodiode counts the transmitted intensity through an autoranging transimpedance amplifier across several gain decades. The rocking curve resolves momentum transfer far below the pinhole-SAXS regime. That angular rocking fly-scan with a multi-decade autoranging point detector is a new Capability, deferred as a question (USAXS-1, BONSE-1). The same instrument also runs pinhole SAXS and WAXS on area detectors, which reuse the existing scattering Capabilities. The novelty forces no new device families: every device below reuses an existing catalog or loose Family.
-
-## No new families
-
-12-ID coins no new Family and changes nothing in the catalog. The two devices that could have tempted a new kind both fold into existing vocabulary:
-
-- **The Bonse-Hart crystal stages bind the catalog `RotaryStage`, not a new optic family.** The collimator and analyzer are channel-cut crystal stages whose operative axis is the crystal rocking rotation (plus alignment translations and a piezo fine-tilt). The rocking rotation is what `RotaryStage` already models; channel-cut versus multi-bounce is a per-Asset setting, not a new optic Family. The rocking-curve scan against the matched crystal is the USAXS measurement, an acquisition shape (USAXS-1), not a device class.
-
-- **The autoranging photodiode binds the catalog `FluxMonitor`, not a new detector family.** The UPD photodiode is the primary USAXS detector, but it is a current-integrating point detector read through an autoranging Femto transimpedance amplifier, the same anatomy as the I0 / I00 / I000 / TRD monitors and the counting scalers. This is the BMM precedent (a quad-electrometer-as-primary-detector). The multi-decade gain autorange is a device-state setting, not a new family (DET-1). The pinhole SAXS and WAXS Pilatus area detectors bind the catalog `Camera`.
-
-The Linkam T96 and the PTC10 reuse the graduated `TemperatureController` Family (presents the `Regulator` Role), the same Family three Diamond beamlines and IXS already use. The attenuator binds the `Filter` Family (the i03 / i15-1 precedent, ATTN-1). The machine source state reuses the loose `StorageRing` (MACHINE-1).
-
-## Deliberately not here yet
-
-- **The Bonse-Hart pair as an Assembly (`BONSE-1`).** Whether the matched collimator and analyzer crystal stages compose one `Assembly` (a Bonse-Hart camera presenting a single rocking-pair unit) is deferred, exactly as the diffractometer beamlines deferred materializing their Assemblies in descriptor mode. The first cut is two flat `RotaryStage` Assets with the Assembly named as the follow-on. An Assembly is earned at n=2 across independent beamlines; coining one at n=1 would be over-modelling.
-
-- **The channel-cut crystal identity.** Each crystal stage carries its crystal as a setting on the one `RotaryStage` Asset; promoting a crystal to a child Asset via `parent_id` is the nested-component-identity convention, itself at a rule-of-three gate (applied only for `RotaryDriveChassis` so far). The first cut carries the crystal as a setting rather than asserting a child Asset.
-
-- **The in-situ load frame (`LOADFRAME-1`).** A load frame exists in the instrument's device library but is not in the active instrument config, so it is not modelled here. No Family is coined for an un-instantiated device; it lands if it enters the active beamline.
-
-- **The USAXS Method.** Whether the Bonse-Hart rocking-curve technique enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`USAXS-1`). The pinhole SAXS / WAXS Practices share the i22 SAXS / WAXS Methods, also pending (TECH-1 at the Site level).
-
-- **The simulated devices and full asset-tree scenarios.** No `test_12_id_e_*.py` registers the asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/12-id/notes.md b/docs/deployments/12-id/notes.md
new file mode 100644
index 00000000000..1abf5cb0445
--- /dev/null
+++ b/docs/deployments/12-id/notes.md
@@ -0,0 +1,135 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 12-ID is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md) is how a facility adapts it. 12-ID is CORA's first Bonse-Hart ultra-small-angle X-ray scattering (USAXS) beamline, and it also runs pinhole SAXS and WAXS on area detectors. The lead technique, USAXS, is a new Capability for the fleet, so its Method renders unlinked and is carried pending until a technique enters scope (USAXS-1); the SAXS and WAXS Methods share the [i22](../i22/notes.md#techniques) scattering vocabulary and are pending the same owner-scope decision (TECH-1).
+
+### Bonse-Hart ultra-small-angle scattering
+
+USAXS reaches momentum transfer q far below the pinhole-SAXS regime by rocking a matched pair of channel-cut crystal stages through the Bragg condition: the collimator sits upstream of the sample, the analyzer downstream, and as the analyzer rocks against the collimator a single photodiode counts the transmitted intensity through an autoranging transimpedance amplifier across several gain decades (BONSE-1, USAXS-1). The measurement is the rocking curve, the transmitted intensity as a function of the small angular offset between the two crystals, which maps to q. This angular rocking fly-scan against a multi-decade autoranging point detector is the acquisition shape that is new for the fleet, not a new device class.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Ultra-small-angle scattering (USAXS) | `ultra_small_angle_scattering` | the Bonse-Hart rocking curve: the [analyzer crystal stage](detector.md) rocks against the [collimator crystal stage](sample.md) through the Bragg condition while the [UPD photodiode](detector.md) point-counts the transmitted flux through an autoranging amplifier; new Capability, pending (USAXS-1, BONSE-1) |
+| Pinhole small-angle scattering (SAXS) | `small_angle_scattering` | low-q on the [SAXS Pilatus area detector](detector.md); shares the i22 SAXS Capability, pending (TECH-1) |
+| Wide-angle scattering (WAXS) | `wide_angle_scattering` | wide-q on the [WAXS Pilatus area detector](detector.md) on its translation; shares the i22 WAXS Capability, pending (TECH-1) |
+
+USAXS needs the [incident beam chain](source.md) (the shared 12-ID double-crystal monochromator and the attenuator filter bank), the [sample stack](sample.md) (positioning stage, rotator, and the Linkam and PTC10 temperature stages), the [Bonse-Hart crystal stages](detector.md), and the [autoranging photodiode with its flux monitors and scaler](detector.md) for normalization. The same instrument runs pinhole SAXS and WAXS on their Pilatus area detectors, which reuse the existing scattering Capabilities and the same beam.
+
+### A new operating axis for the fleet
+
+USAXS is genuinely new for the fleet. The catalog already carries pinhole and grazing-incidence scattering on area detectors (i22, SMI) and a range of imaging, microprobe, and spectroscopy methods, but no crystal-analyzer rocking-curve technique. The new axis is the acquisition shape itself: rock one optic (the analyzer crystal) against a second, fixed-geometry optic (the collimator crystal) while a current-integrating point detector autoranges across several gain decades, rather than expose an area detector at one geometry (BONSE-1, USAXS-1). Pinhole SAXS resolves the scattering pattern by where photons land on a 2D detector; USAXS resolves much smaller angles by where the analyzer crystal passes the beam, read as one transmitted current per angular step. That is a new Capability, deferred as a question (USAXS-1).
+
+The new acquisition shape forces no new device families. The Bonse-Hart crystal stages bind the catalog `RotaryStage`: the operative axis is the crystal rocking rotation, and channel-cut versus multi-bounce is a per-Asset setting, not a new optic Family (BONSE-1). The autoranging photodiode binds the catalog `FluxMonitor`: it is a current-integrating point detector read through an autoranging Femto amplifier, the same anatomy as the I0 / I00 / I000 / TRD flux monitors and the counting scaler, and the multi-decade gain autorange is a device-state setting (DET-1). The SAXS and WAXS Pilatus detectors bind the catalog `Camera`. So what is new is the science Capability and the acquisition shape, not a device class; see [Model](#model) for why nothing graduates and the catalog is unchanged.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the rocking-curve angular ranges, the gain-autorange behaviour and counting times for the photodiode, the pinhole-SAXS and WAXS camera geometries, and the temperature-ramp sequences) are not written yet; they join as the deployment approaches the point where CORA conducts over the floor. Whether USAXS enters CORA's catalog is an owner-scope decision and is deferred (USAXS-1); minting a cross-facility Method is not done from a modelling exercise until a technique enters a real scope, the same earn-the-abstraction discipline the SAXS and WAXS Methods follow (TECH-1). The Practices are carried pending on the [APS Site](../aps/index.md): `12ID_usaxs_practice` (`ultra_small_angle_scattering`, USAXS-1), `12ID_saxs_practice` (`small_angle_scattering`), and `12ID_waxs_practice` (`wide_angle_scattering`). See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at 12-ID, and the trust shape that will gate it. First cut.*
+
+Governance at 12-ID follows the same model as the other APS beamlines: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+12-ID is not yet driven by CORA, so this shape is not yet instantiated. As a reverse-engineered scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The instrument config exposes device tables, not the human roster, so the APS operator pool and safety-review structure is carried pending at the [APS Site](../aps/index.md#safety-and-governance), shared across the beamlines (`GOV-1`).
+
+The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the instrument config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 12-ID adds the hazard classes that come with a hard X-ray USAXS endstation under vacuum and the in-situ temperature environments at the sample (the Linkam T96 and PTC10 stages, `TEMP-1`); those land with the instruments that bring them, and an experiment Clearance would carry them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 12-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 12-ID content lives, the first Bonse-Hart USAXS deployment that coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 12-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes 12-ID new
+
+12-ID is CORA's first Bonse-Hart ultra-small-angle X-ray scattering (USAXS) beamline. The fleet already has pinhole small- and wide-angle scattering (i22, 8-ID), grazing-incidence scattering (9-ID), total scattering and powder diffraction (i15-1, i11), and coherent XPCS (8-ID, CHX), but no crystal-analyzer USAXS. The novelty is the acquisition shape: a matched pair of channel-cut crystal stages, the collimator upstream of the sample and the analyzer downstream, is rocked through the Bragg condition while a single photodiode counts the transmitted intensity through an autoranging transimpedance amplifier across several gain decades. The rocking curve resolves momentum transfer far below the pinhole-SAXS regime. That angular rocking fly-scan with a multi-decade autoranging point detector is a new Capability, deferred as a question (USAXS-1, BONSE-1). The same instrument also runs pinhole SAXS and WAXS on area detectors, which reuse the existing scattering Capabilities. The novelty forces no new device families: every device below reuses an existing catalog or loose Family.
+
+### No new families
+
+12-ID coins no new Family and changes nothing in the catalog. The two devices that could have tempted a new kind both fold into existing vocabulary:
+
+- **The Bonse-Hart crystal stages bind the catalog `RotaryStage`, not a new optic family.** The collimator and analyzer are channel-cut crystal stages whose operative axis is the crystal rocking rotation (plus alignment translations and a piezo fine-tilt). The rocking rotation is what `RotaryStage` already models; channel-cut versus multi-bounce is a per-Asset setting, not a new optic Family. The rocking-curve scan against the matched crystal is the USAXS measurement, an acquisition shape (USAXS-1), not a device class.
+
+- **The autoranging photodiode binds the catalog `FluxMonitor`, not a new detector family.** The UPD photodiode is the primary USAXS detector, but it is a current-integrating point detector read through an autoranging Femto transimpedance amplifier, the same anatomy as the I0 / I00 / I000 / TRD monitors and the counting scalers. This is the BMM precedent (a quad-electrometer-as-primary-detector). The multi-decade gain autorange is a device-state setting, not a new family (DET-1). The pinhole SAXS and WAXS Pilatus area detectors bind the catalog `Camera`.
+
+The Linkam T96 and the PTC10 reuse the graduated `TemperatureController` Family (presents the `Regulator` Role), the same Family three Diamond beamlines and IXS already use. The attenuator binds the `Filter` Family (the i03 / i15-1 precedent, ATTN-1). The machine source state reuses the loose `StorageRing` (MACHINE-1).
+
+### Deliberately not here yet
+
+- **The Bonse-Hart pair as an Assembly (`BONSE-1`).** Whether the matched collimator and analyzer crystal stages compose one `Assembly` (a Bonse-Hart camera presenting a single rocking-pair unit) is deferred, exactly as the diffractometer beamlines deferred materializing their Assemblies in descriptor mode. The first cut is two flat `RotaryStage` Assets with the Assembly named as the follow-on. An Assembly is earned at n=2 across independent beamlines; coining one at n=1 would be over-modelling.
+
+- **The channel-cut crystal identity.** Each crystal stage carries its crystal as a setting on the one `RotaryStage` Asset; promoting a crystal to a child Asset via `parent_id` is the nested-component-identity convention, itself at a rule-of-three gate (applied only for `RotaryDriveChassis` so far). The first cut carries the crystal as a setting rather than asserting a child Asset.
+
+- **The in-situ load frame (`LOADFRAME-1`).** A load frame exists in the instrument's device library but is not in the active instrument config, so it is not modelled here. No Family is coined for an un-instantiated device; it lands if it enters the active beamline.
+
+- **The USAXS Method.** Whether the Bonse-Hart rocking-curve technique enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`USAXS-1`). The pinhole SAXS / WAXS Practices share the i22 SAXS / WAXS Methods, also pending (TECH-1 at the Site level).
+
+- **The simulated devices and full asset-tree scenarios.** No `test_12_id_e_*.py` registers the asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 12-ID team to confirm before the model can be trusted.*
+
+12-ID was reverse-engineered from the beamline's own bluesky / BITS instrument ([BCDA-APS/usaxs-bits](https://github.com/BCDA-APS/usaxs-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `src/usaxs/configs/*.yml` device tables and `src/usaxs/devices/*.py` classes rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Is 12-ID one experiment hutch served by a shared upstream 12-ID optics zone, or do the optics live in the same hutch? | Two enclosures: a shared `12-ID-optics` zone and the `12-ID-E` experiment hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The 12-ID undulator period and type (absent from the USAXS instrument config). | An insertion-device sector; the undulator gap is not exposed as a device. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state 12-ID reads (current, fill, top-up). | Observe-only machine state, a loose `StorageRing`; the exact PVs are pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The 12-ID monochromator crystal cut / d-spacing, the incident-energy range, and the real energy PVs (the instrument wraps it as a soft device). | A double-crystal `Monochromator`; cut and range carried pending. | The monochromator Asset. |
+| ATTN-1 | Nice-to-have | The attenuator foil set (`12idPyFilter:`) and whether it folds into the `Filter` Family or earns a distinct `Attenuator` kind (the fleet-wide question). | An Al/Ti filter bank bound to `Filter`, the i03 / i15-1 precedent. | The attenuator's catalog home. |
+| OPT-2 | Nice-to-have | The blade-axis roles of each slit (guard, USAXS-defining) and the detector / SAXS translation stage axes. | Four-blade variable openings bound to `Slit`; translation stages bound to `LinearStage`. | The slit and stage axis detail. |
+
+### USAXS optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| BONSE-1 | Blocks-build | The Bonse-Hart crystal cut (channel-cut versus multi-bounce), the collimator / analyzer rocking-axis map, and the rocking-curve tolerance. | Matched channel-cut crystal stages on `RotaryStage`, each a rocking rotation plus alignment translations and a piezo fine-tilt. | The Bonse-Hart geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| USAXS-1 | Blocks-go-live | Does the Bonse-Hart rocking-curve ultra-small-angle-scattering technique enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice, no `cora.capability.usaxs` coined. | The USAXS Capability. |
+
+### Sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The sample-stage axis set, the PI C-867 sample rotator role, and what is mounted on them. | A `LinearStage` sample stage plus a `RotaryStage` rotator; the axis set carried pending. | The sample-stage modelling. |
+| TEMP-1 | Nice-to-have | The Linkam T96 temperature range and the PTC10 channel map, and whether they coexist or swap per experiment. | Two `TemperatureController` Assets presenting the `Regulator` Role; range and channels pending. | The temperature-environment modelling. |
+| LOADFRAME-1 | Nice-to-have | Is the in-situ load frame (in the device library but not the active instrument config) part of the operating beamline, and what is it? | Not modelled: deferred until it appears in the active config; no Family coined for an un-instantiated device. | The load-frame modelling. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The UPD autoranging photodiode gain-decade map, the I0 / I00 / I000 / TRD flux-monitor channel assignment, the scaler channels, and the SAXS / WAXS area-detector prefixes. | The UPD photodiode + the I0 family + the scalers bound to `FluxMonitor` (gain autorange a device-state setting); the SAXS / WAXS Pilatus detectors bound to `Camera`. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the usaxs-bits instrument current and correct? | The handles in the descriptor are taken from the instrument config and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (absent from the instrument config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent of the optics and flight paths. | Photon beam, cooling water, and vacuum on the optics and flight paths. | The Supply observations. |
+| GOV-1 | Nice-to-have | The APS operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the APS Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/12-id/questions.md b/docs/deployments/12-id/questions.md
deleted file mode 100644
index 3205dcacbd0..00000000000
--- a/docs/deployments/12-id/questions.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Open questions
-
-*What CORA needs the 12-ID team to confirm before the model can be trusted.*
-
-12-ID was reverse-engineered from the beamline's own bluesky / BITS instrument ([BCDA-APS/usaxs-bits](https://github.com/BCDA-APS/usaxs-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `src/usaxs/configs/*.yml` device tables and `src/usaxs/devices/*.py` classes rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Is 12-ID one experiment hutch served by a shared upstream 12-ID optics zone, or do the optics live in the same hutch? | Two enclosures: a shared `12-ID-optics` zone and the `12-ID-E` experiment hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The 12-ID undulator period and type (absent from the USAXS instrument config). | An insertion-device sector; the undulator gap is not exposed as a device. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state 12-ID reads (current, fill, top-up). | Observe-only machine state, a loose `StorageRing`; the exact PVs are pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The 12-ID monochromator crystal cut / d-spacing, the incident-energy range, and the real energy PVs (the instrument wraps it as a soft device). | A double-crystal `Monochromator`; cut and range carried pending. | The monochromator Asset. |
-| ATTN-1 | Nice-to-have | The attenuator foil set (`12idPyFilter:`) and whether it folds into the `Filter` Family or earns a distinct `Attenuator` kind (the fleet-wide question). | An Al/Ti filter bank bound to `Filter`, the i03 / i15-1 precedent. | The attenuator's catalog home. |
-| OPT-2 | Nice-to-have | The blade-axis roles of each slit (guard, USAXS-defining) and the detector / SAXS translation stage axes. | Four-blade variable openings bound to `Slit`; translation stages bound to `LinearStage`. | The slit and stage axis detail. |
-
-## USAXS optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| BONSE-1 | Blocks-build | The Bonse-Hart crystal cut (channel-cut versus multi-bounce), the collimator / analyzer rocking-axis map, and the rocking-curve tolerance. | Matched channel-cut crystal stages on `RotaryStage`, each a rocking rotation plus alignment translations and a piezo fine-tilt. | The Bonse-Hart geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| USAXS-1 | Blocks-go-live | Does the Bonse-Hart rocking-curve ultra-small-angle-scattering technique enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice, no `cora.capability.usaxs` coined. | The USAXS Capability. |
-
-## Sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The sample-stage axis set, the PI C-867 sample rotator role, and what is mounted on them. | A `LinearStage` sample stage plus a `RotaryStage` rotator; the axis set carried pending. | The sample-stage modelling. |
-| TEMP-1 | Nice-to-have | The Linkam T96 temperature range and the PTC10 channel map, and whether they coexist or swap per experiment. | Two `TemperatureController` Assets presenting the `Regulator` Role; range and channels pending. | The temperature-environment modelling. |
-| LOADFRAME-1 | Nice-to-have | Is the in-situ load frame (in the device library but not the active instrument config) part of the operating beamline, and what is it? | Not modelled: deferred until it appears in the active config; no Family coined for an un-instantiated device. | The load-frame modelling. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The UPD autoranging photodiode gain-decade map, the I0 / I00 / I000 / TRD flux-monitor channel assignment, the scaler channels, and the SAXS / WAXS area-detector prefixes. | The UPD photodiode + the I0 family + the scalers bound to `FluxMonitor` (gain autorange a device-state setting); the SAXS / WAXS Pilatus detectors bound to `Camera`. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the usaxs-bits instrument current and correct? | The handles in the descriptor are taken from the instrument config and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (absent from the instrument config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent of the optics and flight paths. | Photon beam, cooling water, and vacuum on the optics and flight paths. | The Supply observations. |
-| GOV-1 | Nice-to-have | The APS operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the APS Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/12-id/techniques.md b/docs/deployments/12-id/techniques.md
deleted file mode 100644
index 64c1d1214f0..00000000000
--- a/docs/deployments/12-id/techniques.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Techniques
-
-*What the modelled part of 12-ID is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md) is how a facility adapts it. 12-ID is CORA's first Bonse-Hart ultra-small-angle X-ray scattering (USAXS) beamline, and it also runs pinhole SAXS and WAXS on area detectors. The lead technique, USAXS, is a new Capability for the fleet, so its Method renders unlinked and is carried pending until a technique enters scope (USAXS-1); the SAXS and WAXS Methods share the [i22](../i22/techniques.md) scattering vocabulary and are pending the same owner-scope decision (TECH-1).
-
-## Bonse-Hart ultra-small-angle scattering
-
-USAXS reaches momentum transfer q far below the pinhole-SAXS regime by rocking a matched pair of channel-cut crystal stages through the Bragg condition: the collimator sits upstream of the sample, the analyzer downstream, and as the analyzer rocks against the collimator a single photodiode counts the transmitted intensity through an autoranging transimpedance amplifier across several gain decades (BONSE-1, USAXS-1). The measurement is the rocking curve, the transmitted intensity as a function of the small angular offset between the two crystals, which maps to q. This angular rocking fly-scan against a multi-decade autoranging point detector is the acquisition shape that is new for the fleet, not a new device class.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Ultra-small-angle scattering (USAXS) | `ultra_small_angle_scattering` | the Bonse-Hart rocking curve: the [analyzer crystal stage](detector.md) rocks against the [collimator crystal stage](sample.md) through the Bragg condition while the [UPD photodiode](detector.md) point-counts the transmitted flux through an autoranging amplifier; new Capability, pending (USAXS-1, BONSE-1) |
-| Pinhole small-angle scattering (SAXS) | `small_angle_scattering` | low-q on the [SAXS Pilatus area detector](detector.md); shares the i22 SAXS Capability, pending (TECH-1) |
-| Wide-angle scattering (WAXS) | `wide_angle_scattering` | wide-q on the [WAXS Pilatus area detector](detector.md) on its translation; shares the i22 WAXS Capability, pending (TECH-1) |
-
-USAXS needs the [incident beam chain](source.md) (the shared 12-ID double-crystal monochromator and the attenuator filter bank), the [sample stack](sample.md) (positioning stage, rotator, and the Linkam and PTC10 temperature stages), the [Bonse-Hart crystal stages](detector.md), and the [autoranging photodiode with its flux monitors and scaler](detector.md) for normalization. The same instrument runs pinhole SAXS and WAXS on their Pilatus area detectors, which reuse the existing scattering Capabilities and the same beam.
-
-## A new operating axis for the fleet
-
-USAXS is genuinely new for the fleet. The catalog already carries pinhole and grazing-incidence scattering on area detectors (i22, SMI) and a range of imaging, microprobe, and spectroscopy methods, but no crystal-analyzer rocking-curve technique. The new axis is the acquisition shape itself: rock one optic (the analyzer crystal) against a second, fixed-geometry optic (the collimator crystal) while a current-integrating point detector autoranges across several gain decades, rather than expose an area detector at one geometry (BONSE-1, USAXS-1). Pinhole SAXS resolves the scattering pattern by where photons land on a 2D detector; USAXS resolves much smaller angles by where the analyzer crystal passes the beam, read as one transmitted current per angular step. That is a new Capability, deferred as a question (USAXS-1).
-
-The new acquisition shape forces no new device families. The Bonse-Hart crystal stages bind the catalog `RotaryStage`: the operative axis is the crystal rocking rotation, and channel-cut versus multi-bounce is a per-Asset setting, not a new optic Family (BONSE-1). The autoranging photodiode binds the catalog `FluxMonitor`: it is a current-integrating point detector read through an autoranging Femto amplifier, the same anatomy as the I0 / I00 / I000 / TRD flux monitors and the counting scaler, and the multi-decade gain autorange is a device-state setting (DET-1). The SAXS and WAXS Pilatus detectors bind the catalog `Camera`. So what is new is the science Capability and the acquisition shape, not a device class; see [Model](model.md) for why nothing graduates and the catalog is unchanged.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the rocking-curve angular ranges, the gain-autorange behaviour and counting times for the photodiode, the pinhole-SAXS and WAXS camera geometries, and the temperature-ramp sequences) are not written yet; they join as the deployment approaches the point where CORA conducts over the floor. Whether USAXS enters CORA's catalog is an owner-scope decision and is deferred (USAXS-1); minting a cross-facility Method is not done from a modelling exercise until a technique enters a real scope, the same earn-the-abstraction discipline the SAXS and WAXS Methods follow (TECH-1). The Practices are carried pending on the [APS Site](../aps/index.md): `12ID_usaxs_practice` (`ultra_small_angle_scattering`, USAXS-1), `12ID_saxs_practice` (`small_angle_scattering`), and `12ID_waxs_practice` (`wide_angle_scattering`). See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/13-id/governance.md b/docs/deployments/13-id/governance.md
deleted file mode 100644
index 6ab9ffbcd1c..00000000000
--- a/docs/deployments/13-id/governance.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Governance
-
-*Who will act at 13-ID, and the trust shape that will gate it. First cut.*
-
-Governance at 13-ID follows the same model as the other APS beamlines: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-13-ID is not yet driven by CORA, so this shape is not yet instantiated. As a reverse-engineered scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The GSECARS EPICS support tree exposes device templates and startup scripts, not the human roster, so the APS / GSECARS operator pool and the safety-review structure are carried pending at the [APS Site](../aps/index.md#safety-and-governance), shared across the beamlines (`GOV-1`).
-
-## The safety envelope
-
-The safety tier is the other piece that is not yet settled, and at 13-ID it carries an extra leg the other APS beamlines do not. Clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and 13-ID links up to them rather than restating them. What is specific to this station is the stack of hazard classes that an experiment Clearance would have to carry together: a hard X-ray beamline, plus the class-4 double-sided heating lasers at the sample, plus the pressurized gas membrane system that loads the diamond anvil cell. Those three land with the instruments that bring them, and the high-pressure sample environment is the novelty here (`HP-1`).
-
-The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the EPICS-native config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`).
-
-## The laser-safety permit leaf
-
-13-ID adds a distinct enclosure permit axis the rest of the fleet has not needed: a dedicated laser-safety permit gating laser emission, separate from the X-ray PSS leaf. A Koyo safety PLC governs whether the heating lasers may emit into the enclosure. CORA models this as an Enclosure permit concern on the laser-emission axis, not as a device. It is carried pending and its logic is not invented here (`LASER-1`, `PSS-1`); the heating capability of the cell stays open-loop on commanded power and is not a closed-loop controller (`HEAT-1`).
-
-## Where this lands
-
-The concrete Zone, Conduit, and Policy instances, the operator pool, and both safety leaves (the PSS X-ray permit and the laser-emission permit) materialize when the deployment approaches the point where CORA drives 13-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/13-id/model.md b/docs/deployments/13-id/model.md
deleted file mode 100644
index 46e757b3cc4..00000000000
--- a/docs/deployments/13-id/model.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 13-ID content lives, the first extreme-conditions deployment (high-pressure diamond anvil cell), and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 13-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes 13-ID new
-
-13-ID is CORA's first extreme-conditions deployment. The fleet has modelled thermal sample environments (the graduated `TemperatureController`), magnetic ones (the graduated `Magnet`), and pump-probe lasers (the graduated `Laser`), but never a high-pressure one. 13-ID holds the sample in a diamond anvil cell (DAC): the anvils are squeezed by a gas membrane (a PACE5000 pneumatic controller) to the megabar regime, the sample is heated from both sides by two fibre lasers to thousands of kelvin, and the pressure and temperature are read optically in situ (thermal-emission spectroradiometry for temperature; ruby fluorescence, Raman, and Brillouin for pressure). The X-ray probe is otherwise familiar powder and single-crystal diffraction; the novelty is entirely the sample environment.
-
-## The PressureCell family (graduated)
-
-13-ID introduced one device class no existing catalog Family then covered: the high-pressure sample cell. It has since graduated to the catalog, earned across 13-ID and PETRA III P02 (the fleet's second diamond-anvil-cell environment). The name was chosen via the naming-r3 gate.
-
-| Catalog family | Presents | What it is | Earned across |
-| --- | --- | --- | --- |
-| `PressureCell` | Regulator (membrane pressure) | a high-pressure sample environment (the diamond anvil cell): membrane gas pressure loading, double-sided laser heating, and in-situ pressure / temperature metrology, as one Asset | 13-ID and PETRA III P02 (`PRESSURE-1`) |
-
-The name is deliberately the bare, regime-generic role-noun `PressureCell`, not `HighPressureCell` (the qualifier names the regime, the `OpticalTable` to `Table` mistake), nor `DiamondAnvilCell` (the qualifier names the implementation mechanism, which would force a near-duplicate family for the large-volume press or a clamp cell). `PressureCell` spans the DAC, the large-volume press, and clamp cells, so it did not fragment when the next high-pressure environment landed. It graduated to the catalog across 13-ID and PETRA III P02; further high-pressure environments (APS HPCAT 16-ID, the sibling 13-BM-D large-volume press in the same GSECARS source tree, the 4-ID pressure cell) now bind the graduated Family (`PRESSURE-1`).
-
-The cell is modelled as **one Asset** presenting the `Regulator` Role for its membrane pressure (the PACE5000 setpoint and readback, settling to a target). Its double-sided laser heating and its in-situ pressure / temperature metrology are capabilities of the same cell, not separate families. It does not swallow the metrology spectrometer (which binds the catalog `Camera`) or the X-ray detectors; those are sibling Assets.
-
-## The heating lasers are not the Laser family
-
-The two fibre lasers that heat the DAC sample do **not** bind the catalog `Laser` Family. CORA binds by Role, not mechanism: a heating laser is a power-delivery / thermal-actuation role, distinct from the pump-probe `Laser` (4-ID, LCLS-MFX, whose model-versus-hazard question heating does not touch). Binding them to `Laser` would corrupt the signal that hold protects. They are the heating capability of the `PressureCell`. Whether that capability is ever a clean `TemperatureController` is `HEAT-1`: the live heating is open-loop on commanded power (`13IDD:US_LaserPower` / `DS_LaserPower`) with temperature inferred from emission, so today it is a power actuator, not a temperature `Regulator`. The upstream and downstream beams are one device with two sides (balanced double-sided heating), not two instances.
-
-## No new families on the XRD spine
-
-The X-ray probe spine reuses the catalog throughout: the silicon DCM binds `Monochromator` (the 2-BM precedent); the K-B and carbon mirrors bind `Mirror` with their curvature as `PseudoAxis`; the slits bind `Slit`; the clean-up pinhole binds `Aperture`; the attenuator binds `Filter`; the DAC positioning stage binds `Goniometer` (the i03 Smargon precedent); the Eiger2 / Pilatus area detectors and the LightField metrology spectrometer bind `Camera`; the ion chambers and photodiode bind `FluxMonitor`; the Dante MCA binds `EnergyDispersiveSpectrometer`; the incident energy binds `PseudoAxis`; the fibre illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the machine state binds the loose `StorageRing`.
-
-High-pressure diffraction is **not** a new technique: it reuses the pending `diffraction` (4-ID / 8-ID / CSX / i19) and `powder_diffraction` (i11) Methods, with high pressure a Plan-level sample-environment difference (the 4-ID high-pressure-diffraction precedent). The Practices render unlinked, pending (`TECH-1`).
-
-## Deliberately not here yet
-
-- **The PressureCell membrane / load control (`PRESSURE-1`).** The family has graduated to the catalog (earned across 13-ID and P02); the membrane / gas-loading control detail remains a staff confirmation.
-- **The heating-control binding (`HEAT-1`).** Whether any heating path closes a temperature-setpoint loop (a clean `TemperatureController`) versus the open-loop power actuation modelled here is a staff confirmation.
-- **The laser-safety PLC and the metrology excitation lasers (`LASER-1`).** The Koyo DL205 PLC is the laser-emission enclosure permit axis, an Enclosure concern, not a device; the Verdi / Raman excitation lasers live on a separate metrology host (`13RAMAN2`).
-- **The detector 2theta-arm transform (`DET-1`).** The swing transform binds `PseudoAxis`, but its live prefix was seen only in a Galil test template, so the binding is deferred rather than invented.
-- **The 13-BM stations and the large-volume press (`HP-1`).** A different multi-anvil probe spine, out of this station's scope; would bind the catalog `PressureCell` Family when exposed.
-- **The diffraction Methods.** Whether high-pressure powder and single-crystal diffraction enter CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_13_id_d_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/13-id/notes.md b/docs/deployments/13-id/notes.md
new file mode 100644
index 00000000000..d0783dc3757
--- /dev/null
+++ b/docs/deployments/13-id/notes.md
@@ -0,0 +1,176 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 13-ID is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 13-ID runs monochromatic X-ray diffraction on a sample held in a diamond anvil cell under extreme pressure and double-sided laser heating: high-pressure powder diffraction and high-pressure single-crystal diffraction. Both reuse Methods that the fleet already carries (or has pending), so the slugs below render unlinked and are carried pending until one enters scope (TECH-1). Nothing here coins a new technique. The novelty at 13-ID is the sample environment, not the measurement.
+
+### High pressure is a sample environment, not a technique
+
+The diamond anvil cell squeezes the sample between two anvils and heats it from both sides, so the diffraction is measured at extreme pressure and temperature rather than at ambient conditions. That is a difference in the conditions the sample sits in, not a difference in what the beam measures or how the pattern is read. A powder ring is a powder ring whether the powder is at ambient pressure or inside a cell; a single-crystal reflection is a single-crystal reflection either way.
+
+So high pressure binds the same Methods as ordinary diffraction, carried as a Plan-level sample-environment difference. This follows the [4-ID precedent](../4-id/notes.md#techniques), where high-pressure diffraction is the same `diffraction` Method run with a pressure cell, a Plan setting over the same measurement and not a new slug. The cell, its heating, and its in-situ pressure and temperature metrology are modelled as equipment (the catalog [PressureCell](sample.md) family and its capabilities), and the conditions they impose are expressed in the Plan, not in the technique name.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-pressure powder diffraction | `powder_diffraction` | monochromatic powder rings from the cell, recorded on the [area detector](detector.md); shares the i11 powder Capability; high pressure is a Plan-level sample-environment setting, pending (TECH-1) |
+| High-pressure single-crystal diffraction | `diffraction` | reciprocal-space reflections from a single crystal in the cell on the [area detector](detector.md), oriented on the [diffractometer stage](sample.md); shares the 4-ID / 8-ID / CSX / i19 diffraction Capability; high pressure is a Plan-level sample-environment setting, pending (TECH-1) |
+
+Both techniques need the [incident beam chain](source.md) (the shared 13-ID-A monochromator, the K-B focusing mirror, the beam-defining and clean-up apertures, and the attenuator filter bank), the [pressure cell and its diffractometer stage](sample.md), the [area detector on its 2theta arm](detector.md), and the ion-chamber and photodiode [flux monitors](detector.md) for normalization. The diffraction spine is entirely catalog reuse; see [Model](#model) for why nothing in the measurement path graduates.
+
+### What the cell lets the science do
+
+The diamond anvil cell is what makes 13-ID distinct. It lets the experiment probe matter at extreme pressure and temperature, conditions that reach toward planetary interiors and that no other deployment in the fleet has reached. The science is to watch how a material's structure responds as it is squeezed and heated: phase transitions, equations of state, and structural changes under pressure and temperature that do not appear at ambient conditions.
+
+Two cell capabilities do the work, and both are modelled as capabilities of the single [PressureCell](sample.md) Asset rather than as separate families:
+
+- **Pressure.** The cell presents the Regulator Role for its membrane gas pressure, driven through the PACE5000 membrane controller. Setting and reading the membrane pressure is the actuated handle on the squeeze (PRESSURE-1, HP-1).
+- **Double-sided laser heating.** Two IPG YLR fibre lasers heat the sample from both sides, balanced, so the heated volume is hot through its thickness rather than only on one face (HEAT-1). The live heating is open-loop on commanded laser power: there is no closed-loop temperature Regulator today, the lasers are a power actuator and the temperature is inferred from the sample's own thermal emission (HEAT-1).
+
+These two together open the pressure-temperature space that the diffraction then samples. The cell sets the conditions; the diffraction reads the structure.
+
+### The in-situ metrology is part of the cell
+
+Knowing the pressure and temperature at the sample is itself measured in situ, and that metrology belongs to the cell as a capability, not to a technique:
+
+- **Temperature** is read from thermal-emission spectroradiometry: the sample's own glow, dispersed and fit to a thermal spectrum, gives the temperature on each side (HEAT-1, HP-1). The spectrometer that records it binds the catalog [Camera](detector.md) family (LightField PIMAX / PIXIS), the cell's pressure-and-temperature metrology detector.
+- **Pressure** is read from ruby fluorescence, Raman, or Brillouin measurements on the cell (PRESSURE-1, HP-1). These calibrate the pressure that the membrane controller commands against an in-situ standard.
+
+This metrology is not a separate Method. It is how the cell knows the conditions it is imposing, the same way a temperature controller knows its setpoint. It is modelled as part of the PressureCell capability and its [metrology spectrometer](detector.md), and it does not appear in the technique table above.
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet: the powder and single-crystal scan sequences, the laser-power ramp and balancing during heating, the ruby / Raman / Brillouin pressure-calibration steps, and how a Plan threads the pressure and temperature setpoints through a diffraction run. They join as the deployment approaches the point where CORA conducts over the floor.
+
+Whether `powder_diffraction` and `diffraction` enter CORA's catalog, and who owns them across the facilities that share them, is an owner-scope decision and is deferred (TECH-1); minting a cross-facility Method is not done from a modelling exercise until a technique enters a real scope. The Practices are carried pending on the [APS Site](../aps/index.md#the-techniques-adapted-here): `13ID_powder_diffraction_practice` (`powder_diffraction`) and `13ID_diffraction_practice` (`diffraction`), both pending TECH-1.
+
+The 2theta swing transform that would bind a `PseudoAxis` on the [detector arm](detector.md) is deferred, not invented: the arm's prefix was seen only in a controller test template, so the binding is left open (DET-1). A closed-loop temperature Regulator for the heating is likewise not modelled, because today's heating is open-loop on commanded power (HEAT-1). See [Open questions](#open-questions) for the world-facts to confirm first, and [Model](#model) for how the PressureCell family, introduced here, graduated to the catalog across 13-ID and P02 (HP-1).
+
+## Governance
+
+*Who will act at 13-ID, and the trust shape that will gate it. First cut.*
+
+Governance at 13-ID follows the same model as the other APS beamlines: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+13-ID is not yet driven by CORA, so this shape is not yet instantiated. As a reverse-engineered scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The GSECARS EPICS support tree exposes device templates and startup scripts, not the human roster, so the APS / GSECARS operator pool and the safety-review structure are carried pending at the [APS Site](../aps/index.md#safety-and-governance), shared across the beamlines (`GOV-1`).
+
+### The safety envelope
+
+The safety tier is the other piece that is not yet settled, and at 13-ID it carries an extra leg the other APS beamlines do not. Clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and 13-ID links up to them rather than restating them. What is specific to this station is the stack of hazard classes that an experiment Clearance would have to carry together: a hard X-ray beamline, plus the class-4 double-sided heating lasers at the sample, plus the pressurized gas membrane system that loads the diamond anvil cell. Those three land with the instruments that bring them, and the high-pressure sample environment is the novelty here (`HP-1`).
+
+The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the EPICS-native config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`).
+
+### The laser-safety permit leaf
+
+13-ID adds a distinct enclosure permit axis the rest of the fleet has not needed: a dedicated laser-safety permit gating laser emission, separate from the X-ray PSS leaf. A Koyo safety PLC governs whether the heating lasers may emit into the enclosure. CORA models this as an Enclosure permit concern on the laser-emission axis, not as a device. It is carried pending and its logic is not invented here (`LASER-1`, `PSS-1`); the heating capability of the cell stays open-loop on commanded power and is not a closed-loop controller (`HEAT-1`).
+
+### Where this lands
+
+The concrete Zone, Conduit, and Policy instances, the operator pool, and both safety leaves (the PSS X-ray permit and the laser-emission permit) materialize when the deployment approaches the point where CORA drives 13-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 13-ID content lives, the first extreme-conditions deployment (high-pressure diamond anvil cell), and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 13-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes 13-ID new
+
+13-ID is CORA's first extreme-conditions deployment. The fleet has modelled thermal sample environments (the graduated `TemperatureController`), magnetic ones (the graduated `Magnet`), and pump-probe lasers (the graduated `Laser`), but never a high-pressure one. 13-ID holds the sample in a diamond anvil cell (DAC): the anvils are squeezed by a gas membrane (a PACE5000 pneumatic controller) to the megabar regime, the sample is heated from both sides by two fibre lasers to thousands of kelvin, and the pressure and temperature are read optically in situ (thermal-emission spectroradiometry for temperature; ruby fluorescence, Raman, and Brillouin for pressure). The X-ray probe is otherwise familiar powder and single-crystal diffraction; the novelty is entirely the sample environment.
+
+### The PressureCell family (graduated)
+
+13-ID introduced one device class no existing catalog Family then covered: the high-pressure sample cell. It has since graduated to the catalog, earned across 13-ID and PETRA III P02 (the fleet's second diamond-anvil-cell environment). The name was chosen via the naming-r3 gate.
+
+| Catalog family | Presents | What it is | Earned across |
+| --- | --- | --- | --- |
+| `PressureCell` | Regulator (membrane pressure) | a high-pressure sample environment (the diamond anvil cell): membrane gas pressure loading, double-sided laser heating, and in-situ pressure / temperature metrology, as one Asset | 13-ID and PETRA III P02 (`PRESSURE-1`) |
+
+The name is deliberately the bare, regime-generic role-noun `PressureCell`, not `HighPressureCell` (the qualifier names the regime, the `OpticalTable` to `Table` mistake), nor `DiamondAnvilCell` (the qualifier names the implementation mechanism, which would force a near-duplicate family for the large-volume press or a clamp cell). `PressureCell` spans the DAC, the large-volume press, and clamp cells, so it did not fragment when the next high-pressure environment landed. It graduated to the catalog across 13-ID and PETRA III P02; further high-pressure environments (APS HPCAT 16-ID, the sibling 13-BM-D large-volume press in the same GSECARS source tree, the 4-ID pressure cell) now bind the graduated Family (`PRESSURE-1`).
+
+The cell is modelled as **one Asset** presenting the `Regulator` Role for its membrane pressure (the PACE5000 setpoint and readback, settling to a target). Its double-sided laser heating and its in-situ pressure / temperature metrology are capabilities of the same cell, not separate families. It does not swallow the metrology spectrometer (which binds the catalog `Camera`) or the X-ray detectors; those are sibling Assets.
+
+### The heating lasers are not the Laser family
+
+The two fibre lasers that heat the DAC sample do **not** bind the catalog `Laser` Family. CORA binds by Role, not mechanism: a heating laser is a power-delivery / thermal-actuation role, distinct from the pump-probe `Laser` (4-ID, LCLS-MFX, whose model-versus-hazard question heating does not touch). Binding them to `Laser` would corrupt the signal that hold protects. They are the heating capability of the `PressureCell`. Whether that capability is ever a clean `TemperatureController` is `HEAT-1`: the live heating is open-loop on commanded power (`13IDD:US_LaserPower` / `DS_LaserPower`) with temperature inferred from emission, so today it is a power actuator, not a temperature `Regulator`. The upstream and downstream beams are one device with two sides (balanced double-sided heating), not two instances.
+
+### No new families on the XRD spine
+
+The X-ray probe spine reuses the catalog throughout: the silicon DCM binds `Monochromator` (the 2-BM precedent); the K-B and carbon mirrors bind `Mirror` with their curvature as `PseudoAxis`; the slits bind `Slit`; the clean-up pinhole binds `Aperture`; the attenuator binds `Filter`; the DAC positioning stage binds `Goniometer` (the i03 Smargon precedent); the Eiger2 / Pilatus area detectors and the LightField metrology spectrometer bind `Camera`; the ion chambers and photodiode bind `FluxMonitor`; the Dante MCA binds `EnergyDispersiveSpectrometer`; the incident energy binds `PseudoAxis`; the fibre illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the machine state binds the loose `StorageRing`.
+
+High-pressure diffraction is **not** a new technique: it reuses the pending `diffraction` (4-ID / 8-ID / CSX / i19) and `powder_diffraction` (i11) Methods, with high pressure a Plan-level sample-environment difference (the 4-ID high-pressure-diffraction precedent). The Practices render unlinked, pending (`TECH-1`).
+
+### Deliberately not here yet
+
+- **The PressureCell membrane / load control (`PRESSURE-1`).** The family has graduated to the catalog (earned across 13-ID and P02); the membrane / gas-loading control detail remains a staff confirmation.
+- **The heating-control binding (`HEAT-1`).** Whether any heating path closes a temperature-setpoint loop (a clean `TemperatureController`) versus the open-loop power actuation modelled here is a staff confirmation.
+- **The laser-safety PLC and the metrology excitation lasers (`LASER-1`).** The Koyo DL205 PLC is the laser-emission enclosure permit axis, an Enclosure concern, not a device; the Verdi / Raman excitation lasers live on a separate metrology host (`13RAMAN2`).
+- **The detector 2theta-arm transform (`DET-1`).** The swing transform binds `PseudoAxis`, but its live prefix was seen only in a Galil test template, so the binding is deferred rather than invented.
+- **The 13-BM stations and the large-volume press (`HP-1`).** A different multi-anvil probe spine, out of this station's scope; would bind the catalog `PressureCell` Family when exposed.
+- **The diffraction Methods.** Whether high-pressure powder and single-crystal diffraction enter CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_13_id_d_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the GSECARS 13-ID team to confirm before the model can be trusted.*
+
+13-ID was reverse-engineered from the GSECARS EPICS support tree ([CARS-UChicago/GSECARS-EPICS](https://github.com/CARS-UChicago/GSECARS-EPICS)), so the control handles on the [device pages](index.md) are the beamline's real PVs, reconstructed from the `iocBoot` startup scripts, the `CARSApp/Db` device templates, and the `CARSApp/op/adl` screens rather than confirmed by staff. This is an EPICS-native source (not a dodal or BITS Python roster), so the device-to-PV reconstruction is rougher and carried at medium confidence. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are 13-ID-A (first optics) and 13-ID-D (endstation) separate hutches, and how does the laser-safety enclosure relate? | Two enclosures: a shared `13-ID-optics` zone and the `13-ID-D` endstation; the laser-safety PLC adds a laser-emission permit axis. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The 13-ID undulator (shared across 13-ID-C/D/E), energy-tracked with the mono. | An undulator, not surfaced as a device in the support tree read. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state 13-ID reads. | Observe-only machine state, a loose `StorageRing`; PVs pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The 13-ID-A Si monochromator crystal cut, the energy range, and the energy partition rule. | A silicon double-crystal `Monochromator`; the energy is a `PseudoAxis` (`13IDE:En`). | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The K-B and carbon mirror coatings, the curvature / ellipticity axes. | Focusing mirrors bound to `Mirror`; curvature / ellipticity a `PseudoAxis`. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis roles of the beam-defining and DAC table-top slits (DACV / DACH). | Slits bound to `Slit`. | The slit Asset detail. |
+| APERTURE-1 | Nice-to-have | The clean-up pinhole and its X / Y / Z carriers. | The opening bound to `Aperture`, the carriers `LinearStage`. | The pinhole Asset. |
+| ATTN-1 | Nice-to-have | The attenuator foil set (`13IDD:filter:`) and whether it folds into `Filter` or earns a distinct `Attenuator` kind. | The attenuator bound to `Filter` (the 2-BM precedent). | The attenuator's catalog home. |
+
+### The high-pressure sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| HP-1 | Blocks-build | How is the diamond anvil cell configured: the membrane pressure range, the double-sided laser-heating geometry, and the in-situ pressure / temperature metrology, and are they one cell or separate units? | One `PressureCell` Asset presenting the `Regulator` Role for the membrane pressure (PACE5000), with laser heating and metrology as its capabilities. | The DAC modelling; the CORA structural choice is on [Model](#the-pressurecell-family-graduated). |
+| HEAT-1 | Blocks-go-live | Does any heating path close a loop on a temperature setpoint (a clean `TemperatureController`), or is the live laser heating open-loop on commanded power with temperature inferred from emission? | Open-loop on commanded power (`13IDD:US_LaserPower` / `DS_LaserPower`), temperature read by spectroradiometry; a power actuator, not a temperature `Regulator`. | The heating-control modelling. |
+| PRESSURE-1 | Nice-to-have | The `PressureCell` membrane / gas-loading / pressure-ramp control detail, beyond the PACE5000 setpoint / readback. | The `PressureCell` Family has graduated to the catalog (earned across 13-ID and P02); the membrane / load control detail is pending. | The PressureCell control modelling. |
+| LASER-1 | Blocks-go-live | The Koyo laser-safety PLC (`13IDD_laserPLC:`) enable / enclosure signals, and the metrology excitation lasers on the separate `13RAMAN2` host. | The PLC is a laser-emission enclosure permit axis (not a device); the excitation lasers are a cell metrology capability. | The laser-safety permit and the excitation lasers. |
+
+### Sample stage and detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The DAC positioning stage / micro-diffractometer axes (Galil X / Z / Y / Omega and the Newport XPS-16 trajectory stage) and the single-Omega geometry. | A `Goniometer` (the i03 Smargon precedent); Galil-vs-XPS controller and single Omega are settings. | The sample-stage modelling. |
+| DET-1 | Blocks-go-live | The XRD detector assignment (Eiger2 9M versus the Pilatus 1M CdTe / Si), the detector 2theta-arm transform (seen only in a Galil test template), and the flux / fluorescence channel map. | The Eiger2 / Pilatus bind `Camera`; the 2theta swing binds `PseudoAxis` (binding deferred); the ion chambers bind `FluxMonitor` and the Dante MCA `EnergyDispersiveSpectrometer`. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles reconstructed from the GSECARS support tree current and correct? | The handles in the descriptor are reconstructed from the support tree and carried confirm at medium confidence. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals, plus the laser-safety enclosure permit. | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the high-pressure gas supply the membrane controller uses. | Photon beam, cooling water, vacuum, and process gas. | The Supply observations. |
+| GOV-1 | Nice-to-have | The APS / GSECARS operator pool and safety-review structure. | Carried pending on the APS Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do high-pressure powder and single-crystal diffraction enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `powder_diffraction` (i11) and `diffraction` (4-ID) Methods, with high pressure a Plan-level sample-environment difference; none coined. | The diffraction Capabilities. |
diff --git a/docs/deployments/13-id/questions.md b/docs/deployments/13-id/questions.md
deleted file mode 100644
index 7b9c57eb1d6..00000000000
--- a/docs/deployments/13-id/questions.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Open questions
-
-*What CORA needs the GSECARS 13-ID team to confirm before the model can be trusted.*
-
-13-ID was reverse-engineered from the GSECARS EPICS support tree ([CARS-UChicago/GSECARS-EPICS](https://github.com/CARS-UChicago/GSECARS-EPICS)), so the control handles on the [device pages](index.md) are the beamline's real PVs, reconstructed from the `iocBoot` startup scripts, the `CARSApp/Db` device templates, and the `CARSApp/op/adl` screens rather than confirmed by staff. This is an EPICS-native source (not a dodal or BITS Python roster), so the device-to-PV reconstruction is rougher and carried at medium confidence. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are 13-ID-A (first optics) and 13-ID-D (endstation) separate hutches, and how does the laser-safety enclosure relate? | Two enclosures: a shared `13-ID-optics` zone and the `13-ID-D` endstation; the laser-safety PLC adds a laser-emission permit axis. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The 13-ID undulator (shared across 13-ID-C/D/E), energy-tracked with the mono. | An undulator, not surfaced as a device in the support tree read. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state 13-ID reads. | Observe-only machine state, a loose `StorageRing`; PVs pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The 13-ID-A Si monochromator crystal cut, the energy range, and the energy partition rule. | A silicon double-crystal `Monochromator`; the energy is a `PseudoAxis` (`13IDE:En`). | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The K-B and carbon mirror coatings, the curvature / ellipticity axes. | Focusing mirrors bound to `Mirror`; curvature / ellipticity a `PseudoAxis`. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis roles of the beam-defining and DAC table-top slits (DACV / DACH). | Slits bound to `Slit`. | The slit Asset detail. |
-| APERTURE-1 | Nice-to-have | The clean-up pinhole and its X / Y / Z carriers. | The opening bound to `Aperture`, the carriers `LinearStage`. | The pinhole Asset. |
-| ATTN-1 | Nice-to-have | The attenuator foil set (`13IDD:filter:`) and whether it folds into `Filter` or earns a distinct `Attenuator` kind. | The attenuator bound to `Filter` (the 2-BM precedent). | The attenuator's catalog home. |
-
-## The high-pressure sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| HP-1 | Blocks-build | How is the diamond anvil cell configured: the membrane pressure range, the double-sided laser-heating geometry, and the in-situ pressure / temperature metrology, and are they one cell or separate units? | One `PressureCell` Asset presenting the `Regulator` Role for the membrane pressure (PACE5000), with laser heating and metrology as its capabilities. | The DAC modelling; the CORA structural choice is on [Model](model.md#the-pressurecell-family-graduated). |
-| HEAT-1 | Blocks-go-live | Does any heating path close a loop on a temperature setpoint (a clean `TemperatureController`), or is the live laser heating open-loop on commanded power with temperature inferred from emission? | Open-loop on commanded power (`13IDD:US_LaserPower` / `DS_LaserPower`), temperature read by spectroradiometry; a power actuator, not a temperature `Regulator`. | The heating-control modelling. |
-| PRESSURE-1 | Nice-to-have | The `PressureCell` membrane / gas-loading / pressure-ramp control detail, beyond the PACE5000 setpoint / readback. | The `PressureCell` Family has graduated to the catalog (earned across 13-ID and P02); the membrane / load control detail is pending. | The PressureCell control modelling. |
-| LASER-1 | Blocks-go-live | The Koyo laser-safety PLC (`13IDD_laserPLC:`) enable / enclosure signals, and the metrology excitation lasers on the separate `13RAMAN2` host. | The PLC is a laser-emission enclosure permit axis (not a device); the excitation lasers are a cell metrology capability. | The laser-safety permit and the excitation lasers. |
-
-## Sample stage and detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The DAC positioning stage / micro-diffractometer axes (Galil X / Z / Y / Omega and the Newport XPS-16 trajectory stage) and the single-Omega geometry. | A `Goniometer` (the i03 Smargon precedent); Galil-vs-XPS controller and single Omega are settings. | The sample-stage modelling. |
-| DET-1 | Blocks-go-live | The XRD detector assignment (Eiger2 9M versus the Pilatus 1M CdTe / Si), the detector 2theta-arm transform (seen only in a Galil test template), and the flux / fluorescence channel map. | The Eiger2 / Pilatus bind `Camera`; the 2theta swing binds `PseudoAxis` (binding deferred); the ion chambers bind `FluxMonitor` and the Dante MCA `EnergyDispersiveSpectrometer`. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles reconstructed from the GSECARS support tree current and correct? | The handles in the descriptor are reconstructed from the support tree and carried confirm at medium confidence. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals, plus the laser-safety enclosure permit. | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the high-pressure gas supply the membrane controller uses. | Photon beam, cooling water, vacuum, and process gas. | The Supply observations. |
-| GOV-1 | Nice-to-have | The APS / GSECARS operator pool and safety-review structure. | Carried pending on the APS Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do high-pressure powder and single-crystal diffraction enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `powder_diffraction` (i11) and `diffraction` (4-ID) Methods, with high pressure a Plan-level sample-environment difference; none coined. | The diffraction Capabilities. |
diff --git a/docs/deployments/13-id/techniques.md b/docs/deployments/13-id/techniques.md
deleted file mode 100644
index d3df68cd189..00000000000
--- a/docs/deployments/13-id/techniques.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Techniques
-
-*What the modelled part of 13-ID is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 13-ID runs monochromatic X-ray diffraction on a sample held in a diamond anvil cell under extreme pressure and double-sided laser heating: high-pressure powder diffraction and high-pressure single-crystal diffraction. Both reuse Methods that the fleet already carries (or has pending), so the slugs below render unlinked and are carried pending until one enters scope (TECH-1). Nothing here coins a new technique. The novelty at 13-ID is the sample environment, not the measurement.
-
-## High pressure is a sample environment, not a technique
-
-The diamond anvil cell squeezes the sample between two anvils and heats it from both sides, so the diffraction is measured at extreme pressure and temperature rather than at ambient conditions. That is a difference in the conditions the sample sits in, not a difference in what the beam measures or how the pattern is read. A powder ring is a powder ring whether the powder is at ambient pressure or inside a cell; a single-crystal reflection is a single-crystal reflection either way.
-
-So high pressure binds the same Methods as ordinary diffraction, carried as a Plan-level sample-environment difference. This follows the [4-ID precedent](../4-id/techniques.md), where high-pressure diffraction is the same `diffraction` Method run with a pressure cell, a Plan setting over the same measurement and not a new slug. The cell, its heating, and its in-situ pressure and temperature metrology are modelled as equipment (the catalog [PressureCell](sample.md) family and its capabilities), and the conditions they impose are expressed in the Plan, not in the technique name.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-pressure powder diffraction | `powder_diffraction` | monochromatic powder rings from the cell, recorded on the [area detector](detector.md); shares the i11 powder Capability; high pressure is a Plan-level sample-environment setting, pending (TECH-1) |
-| High-pressure single-crystal diffraction | `diffraction` | reciprocal-space reflections from a single crystal in the cell on the [area detector](detector.md), oriented on the [diffractometer stage](sample.md); shares the 4-ID / 8-ID / CSX / i19 diffraction Capability; high pressure is a Plan-level sample-environment setting, pending (TECH-1) |
-
-Both techniques need the [incident beam chain](source.md) (the shared 13-ID-A monochromator, the K-B focusing mirror, the beam-defining and clean-up apertures, and the attenuator filter bank), the [pressure cell and its diffractometer stage](sample.md), the [area detector on its 2theta arm](detector.md), and the ion-chamber and photodiode [flux monitors](detector.md) for normalization. The diffraction spine is entirely catalog reuse; see [Model](model.md) for why nothing in the measurement path graduates.
-
-## What the cell lets the science do
-
-The diamond anvil cell is what makes 13-ID distinct. It lets the experiment probe matter at extreme pressure and temperature, conditions that reach toward planetary interiors and that no other deployment in the fleet has reached. The science is to watch how a material's structure responds as it is squeezed and heated: phase transitions, equations of state, and structural changes under pressure and temperature that do not appear at ambient conditions.
-
-Two cell capabilities do the work, and both are modelled as capabilities of the single [PressureCell](sample.md) Asset rather than as separate families:
-
-- **Pressure.** The cell presents the Regulator Role for its membrane gas pressure, driven through the PACE5000 membrane controller. Setting and reading the membrane pressure is the actuated handle on the squeeze (PRESSURE-1, HP-1).
-- **Double-sided laser heating.** Two IPG YLR fibre lasers heat the sample from both sides, balanced, so the heated volume is hot through its thickness rather than only on one face (HEAT-1). The live heating is open-loop on commanded laser power: there is no closed-loop temperature Regulator today, the lasers are a power actuator and the temperature is inferred from the sample's own thermal emission (HEAT-1).
-
-These two together open the pressure-temperature space that the diffraction then samples. The cell sets the conditions; the diffraction reads the structure.
-
-## The in-situ metrology is part of the cell
-
-Knowing the pressure and temperature at the sample is itself measured in situ, and that metrology belongs to the cell as a capability, not to a technique:
-
-- **Temperature** is read from thermal-emission spectroradiometry: the sample's own glow, dispersed and fit to a thermal spectrum, gives the temperature on each side (HEAT-1, HP-1). The spectrometer that records it binds the catalog [Camera](detector.md) family (LightField PIMAX / PIXIS), the cell's pressure-and-temperature metrology detector.
-- **Pressure** is read from ruby fluorescence, Raman, or Brillouin measurements on the cell (PRESSURE-1, HP-1). These calibrate the pressure that the membrane controller commands against an in-situ standard.
-
-This metrology is not a separate Method. It is how the cell knows the conditions it is imposing, the same way a temperature controller knows its setpoint. It is modelled as part of the PressureCell capability and its [metrology spectrometer](detector.md), and it does not appear in the technique table above.
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet: the powder and single-crystal scan sequences, the laser-power ramp and balancing during heating, the ruby / Raman / Brillouin pressure-calibration steps, and how a Plan threads the pressure and temperature setpoints through a diffraction run. They join as the deployment approaches the point where CORA conducts over the floor.
-
-Whether `powder_diffraction` and `diffraction` enter CORA's catalog, and who owns them across the facilities that share them, is an owner-scope decision and is deferred (TECH-1); minting a cross-facility Method is not done from a modelling exercise until a technique enters a real scope. The Practices are carried pending on the [APS Site](../aps/index.md#the-techniques-adapted-here): `13ID_powder_diffraction_practice` (`powder_diffraction`) and `13ID_diffraction_practice` (`diffraction`), both pending TECH-1.
-
-The 2theta swing transform that would bind a `PseudoAxis` on the [detector arm](detector.md) is deferred, not invented: the arm's prefix was seen only in a controller test template, so the binding is left open (DET-1). A closed-loop temperature Regulator for the heating is likewise not modelled, because today's heating is open-loop on commanded power (HEAT-1). See [Open questions](questions.md) for the world-facts to confirm first, and [Model](model.md) for how the PressureCell family, introduced here, graduated to the catalog across 13-ID and P02 (HP-1).
diff --git a/docs/deployments/19-bm/governance.md b/docs/deployments/19-bm/governance.md
deleted file mode 100644
index d0496f55406..00000000000
--- a/docs/deployments/19-bm/governance.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Governance
-
-*Who will act at 19-BM, and the trust shape that will gate it. Design-phase.*
-
-Governance at 19-BM follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-19-BM is pre-build, so this shape is not yet instantiated. The concrete Zone, Conduit, and Policy instances, and the 19-BM operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape. The APS clearances (the safety forms that must be active to start) are issued at the APS Site, not on the beamline, and the beamline links up to them.
-
-## Autonomy is first-class here
-
-19-BM is "Fast Autonomous Computed Tomography": running unattended at a high scan cadence with a robotic sample changer is the reason the beamline exists. That makes it the deployment where CORA's supervisory agents are intended to go from seeded-but-dormant to operational. The agents are already facility principals at APS, carried pending on the [APS site page](../aps/index.md#safety-and-governance):
-
-- The `RunSupervisor` watches a running scan and can hold it; 19-BM is where that supervision is expected to be enabled and to climb from observe-and-advise toward holding and truncating stalled runs.
-- The autonomous loop also needs a way to **start** runs without an operator (queue the next sample, start its scan), which the spine does not yet expose to an agent. 19-BM is the forcing case for that capability; it is a design question, not a copy from 2-BM.
-
-Like every agent in CORA, these act only by issuing a command the spine already exposes, through the same authorized path a person uses. None of this is built yet; 19-BM reserves the seam.
-
-## The robotic sample changer gate
-
-The robotic sample changer requires a separate safety review before implementation (recorded in the FDR). In CORA terms that review issues a Clearance that must be Active before the changer may operate, so autonomous loading cannot start until the review is on file. The changer Asset, its Clearance gate, and the autonomous loading flow are carried as an [open question](questions.md) (ROBOT-1) until the design and the review land.
diff --git a/docs/deployments/19-bm/model.md b/docs/deployments/19-bm/model.md
deleted file mode 100644
index f3447fff9f9..00000000000
--- a/docs/deployments/19-bm/model.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 19-BM content lives, a second BM beamline that reuses the families 2-BM established and coins none of its own, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 19-BM |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What is deliberately not here yet
-
-- **Integration scenarios.** No `test_19bm_*.py` registers 19-BM Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, moving-target beamline would commit speculative structure. It lands when the design firms and the team approves.
-- **Vendor Models.** No catalog Model is bound: the sample stages, the detector hardware, and the robotic changer are all procured after the FDR and are carried as [open questions](questions.md), not bindings.
-- **New catalog Families.** 19-BM coins none of its own. The two passive families it pushed past the rule-of-three threshold (`Window`, with two more Be windows; `Collimator`, with two more Pb collimators) have since been promoted to catalog Families under the passive beam-path tier; 19-BM's windows and collimators now bind them.
-- **The autonomy build.** The `RunSupervisor` enablement and the missing run-start capability that 19-BM's autonomous operation needs are real CORA work, not documentation; see [Governance](governance.md). They land as their own slices.
-- **The robotic sample changer.** Deferred behind its separate safety review (ROBOT-1).
-- **Operations and experiment views.** A runbook and live experiment view for an unbuilt beamline would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/19-bm/notes.md b/docs/deployments/19-bm/notes.md
new file mode 100644
index 00000000000..702cb45671d
--- /dev/null
+++ b/docs/deployments/19-bm/notes.md
@@ -0,0 +1,104 @@
+# Notes
+
+## Techniques
+
+*What 19-BM is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 19-BM is pre-build, so the techniques below are design intent: the APS Practices that will bind them are carried pending on the [APS site page](../aps/index.md#the-techniques-adapted-here). The function view survives the eventual equipment choices, which is why it can be written before the hardware is procured.
+
+19-BM is a single-mode beamline: filtered white-beam tomography. There is no monochromator and no mirror, so unlike 2-BM there is no beam-mode or energy-change technique. The beam spectrum is set by selecting filters in the F3-30 unit, and the science variety is in the acquisition cadence, not the optics.
+
+| Technique | Catalog Method | What it is for |
+| --- | --- | --- |
+| Filtered white-beam tomography | `tomography` | the standard micron-resolution CT scan |
+| Continuous-rotation tomography | `continuous_rotation_tomography` | high-throughput acquisition, the autonomous workhorse |
+| Streaming tomography | `streaming_tomography` | live reconstruction feedback |
+| Dark / flat fields | `dark_field`, `flat_field` | the reference frames every reconstruction needs |
+| First light | `first_light` | commissioning the beam onto the detector |
+
+A few points of intent shape the model:
+
+- **Autonomy and throughput are the point.** 19-BM is built to run unattended at a high scan cadence with a robotic sample changer feeding it. The technique layer is ordinary tomography; what is distinctive is the autonomous operation around it (see [Governance](#governance)) and the sample-exchange loop (see [Sample](sample.md)).
+- **Spectrum is set by filtering, not optics.** Selecting Si / Ge / Cu filters in the F3-30 unit hardens or softens the white-beam spectrum. This replaces the energy-selection techniques 2-BM has, which depend on its monochromator.
+- **Single beam mode.** There is one set of optics and one mode, so there is no beam-mode-change technique to model.
+
+The concrete acquisition recipes (scan sequences, exposure, filter choices) are not written yet; they join as the beamline approaches commissioning. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who will act at 19-BM, and the trust shape that will gate it. Design-phase.*
+
+Governance at 19-BM follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+19-BM is pre-build, so this shape is not yet instantiated. The concrete Zone, Conduit, and Policy instances, and the 19-BM operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape. The APS clearances (the safety forms that must be active to start) are issued at the APS Site, not on the beamline, and the beamline links up to them.
+
+### Autonomy is first-class here
+
+19-BM is "Fast Autonomous Computed Tomography": running unattended at a high scan cadence with a robotic sample changer is the reason the beamline exists. That makes it the deployment where CORA's supervisory agents are intended to go from seeded-but-dormant to operational. The agents are already facility principals at APS, carried pending on the [APS site page](../aps/index.md#safety-and-governance):
+
+- The `RunSupervisor` watches a running scan and can hold it; 19-BM is where that supervision is expected to be enabled and to climb from observe-and-advise toward holding and truncating stalled runs.
+- The autonomous loop also needs a way to **start** runs without an operator (queue the next sample, start its scan), which the spine does not yet expose to an agent. 19-BM is the forcing case for that capability; it is a design question, not a copy from 2-BM.
+
+Like every agent in CORA, these act only by issuing a command the spine already exposes, through the same authorized path a person uses. None of this is built yet; 19-BM reserves the seam.
+
+### The robotic sample changer gate
+
+The robotic sample changer requires a separate safety review before implementation (recorded in the FDR). In CORA terms that review issues a Clearance that must be Active before the changer may operate, so autonomous loading cannot start until the review is on file. The changer Asset, its Clearance gate, and the autonomous loading flow are carried as an [open question](#open-questions) (ROBOT-1) until the design and the review land.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 19-BM content lives, a second BM beamline that reuses the families 2-BM established and coins none of its own, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 19-BM |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What is deliberately not here yet
+
+- **Integration scenarios.** No `test_19bm_*.py` registers 19-BM Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, moving-target beamline would commit speculative structure. It lands when the design firms and the team approves.
+- **Vendor Models.** No catalog Model is bound: the sample stages, the detector hardware, and the robotic changer are all procured after the FDR and are carried as [open questions](#open-questions), not bindings.
+- **New catalog Families.** 19-BM coins none of its own. The two passive families it pushed past the rule-of-three threshold (`Window`, with two more Be windows; `Collimator`, with two more Pb collimators) have since been promoted to catalog Families under the passive beam-path tier; 19-BM's windows and collimators now bind them.
+- **The autonomy build.** The `RunSupervisor` enablement and the missing run-start capability that 19-BM's autonomous operation needs are real CORA work, not documentation; see [Governance](#governance). They land as their own slices.
+- **The robotic sample changer.** Deferred behind its separate safety review (ROBOT-1).
+- **Operations and experiment views.** A runbook and live experiment view for an unbuilt beamline would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 19-BM team to confirm before the model can be trusted.*
+
+19-BM is in the design phase, so almost every value on the [device pages](index.md) is a Final Design Report specification, not a commissioned measurement. Each row below is a fact the beamline team or the FDR owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | What are the EPICS PV names for each device, and does 19-BM follow the 2-BM TomoScan / MCTOptics IOC layout? | Control handles are unassigned; CORA leaves each device handle empty (no PV) until the control system is up. | Wiring each Asset to a real control handle. |
+| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for 19-BM-A, 19-BM-C, and 19-BM-D? | Each enclosure exists with a permit signal to be named (ICMS APS_1181415). | The Enclosure permit signals. |
+| ENC-1 | Blocks-build | 19-BM-C and 19-BM-D share a downstream-wall guillotine held open during operation, so they act as one shielded volume. Do they share a single PSS search-and-secure, and should CORA model them as one Enclosure or two coupled ones? | Modelled as two Enclosures today (19-BM-C carries no Assets); the coupling is noted, not yet a structural link. | The Enclosure shape for the C and D volumes. |
+| BLEPS-1 | Blocks-go-live | How should the BLEPS equipment-protection chain (beamline vacuum, and the cooling water plumbed in series across the Be window and the photon stop) map onto CORA Supplies and the beam-availability signal? | Vacuum and cooling water are beamline-scope Supplies, one each, whose faults the BLEPS also folds into beam availability, following 2-BM; no separate equipment-protection aggregate. | The BLEPS-to-Supply mapping. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| FILTER-1 | Nice-to-have | How should the F3-30 two-bank Si/Ge/Cu filter unit be modelled: one selector over the combinatorial effective thicknesses, or one selector per bank? And what fills bank 2 slot 5? | One `Filter` Asset whose selectable foils are a per-Asset setting plus a position-to-thickness calibration, as at 2-BM; the combinatorial map is a setting, not a family split. | The filter selector modelling and the bank 2 slot 5 value. |
+
+### Endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | What are the sample rotary and linear positioning stages (the manipulator design was out of FDR scope)? | A rotary stage plus a linear positioning stage, reusing the `RotaryStage` and `LinearStage` Families, models unbound. | The sample stage Model bindings. |
+| ROBOT-1 | Blocks-go-live | What is the robotic sample changer, and what is the separate safety review it requires before implementation? How should CORA gate autonomous loading on it? | The changer is one Positioner Asset that loads and unloads Subjects; its operation is gated by a Clearance that must be Active, issued after the separate safety review. Modelled when the design and review land. | The sample-changer Asset, its Clearance gate, and the autonomous loading flow. |
+| TRIG-1 | Blocks-go-live | What is the high-throughput trigger and sync scheme: is the sample rotary TTL encoder the master clock, and is PSO-style fly-scan triggering used? | A single `TimingController` carries the scheme; the rotary encoder is the candidate master clock; conditioner and PSO use to be confirmed. | The trigger / sync chain. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Which scintillator, microscope optics, and camera will be procured for the indirect-detection system? | A scintillator, a visible-light microscope (composed as the cross-facility `Microscope` Assembly presenting the Detector Role), and a camera; models unbound until procurement. | The detector hardware Model bindings. |
diff --git a/docs/deployments/19-bm/questions.md b/docs/deployments/19-bm/questions.md
deleted file mode 100644
index 5186b77791c..00000000000
--- a/docs/deployments/19-bm/questions.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Open questions
-
-*What CORA needs the 19-BM team to confirm before the model can be trusted.*
-
-19-BM is in the design phase, so almost every value on the [device pages](index.md) is a Final Design Report specification, not a commissioned measurement. Each row below is a fact the beamline team or the FDR owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | What are the EPICS PV names for each device, and does 19-BM follow the 2-BM TomoScan / MCTOptics IOC layout? | Control handles are unassigned; CORA leaves each device handle empty (no PV) until the control system is up. | Wiring each Asset to a real control handle. |
-| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for 19-BM-A, 19-BM-C, and 19-BM-D? | Each enclosure exists with a permit signal to be named (ICMS APS_1181415). | The Enclosure permit signals. |
-| ENC-1 | Blocks-build | 19-BM-C and 19-BM-D share a downstream-wall guillotine held open during operation, so they act as one shielded volume. Do they share a single PSS search-and-secure, and should CORA model them as one Enclosure or two coupled ones? | Modelled as two Enclosures today (19-BM-C carries no Assets); the coupling is noted, not yet a structural link. | The Enclosure shape for the C and D volumes. |
-| BLEPS-1 | Blocks-go-live | How should the BLEPS equipment-protection chain (beamline vacuum, and the cooling water plumbed in series across the Be window and the photon stop) map onto CORA Supplies and the beam-availability signal? | Vacuum and cooling water are beamline-scope Supplies, one each, whose faults the BLEPS also folds into beam availability, following 2-BM; no separate equipment-protection aggregate. | The BLEPS-to-Supply mapping. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| FILTER-1 | Nice-to-have | How should the F3-30 two-bank Si/Ge/Cu filter unit be modelled: one selector over the combinatorial effective thicknesses, or one selector per bank? And what fills bank 2 slot 5? | One `Filter` Asset whose selectable foils are a per-Asset setting plus a position-to-thickness calibration, as at 2-BM; the combinatorial map is a setting, not a family split. | The filter selector modelling and the bank 2 slot 5 value. |
-
-## Endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | What are the sample rotary and linear positioning stages (the manipulator design was out of FDR scope)? | A rotary stage plus a linear positioning stage, reusing the `RotaryStage` and `LinearStage` Families, models unbound. | The sample stage Model bindings. |
-| ROBOT-1 | Blocks-go-live | What is the robotic sample changer, and what is the separate safety review it requires before implementation? How should CORA gate autonomous loading on it? | The changer is one Positioner Asset that loads and unloads Subjects; its operation is gated by a Clearance that must be Active, issued after the separate safety review. Modelled when the design and review land. | The sample-changer Asset, its Clearance gate, and the autonomous loading flow. |
-| TRIG-1 | Blocks-go-live | What is the high-throughput trigger and sync scheme: is the sample rotary TTL encoder the master clock, and is PSO-style fly-scan triggering used? | A single `TimingController` carries the scheme; the rotary encoder is the candidate master clock; conditioner and PSO use to be confirmed. | The trigger / sync chain. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Which scintillator, microscope optics, and camera will be procured for the indirect-detection system? | A scintillator, a visible-light microscope (composed as the cross-facility `Microscope` Assembly presenting the Detector Role), and a camera; models unbound until procurement. | The detector hardware Model bindings. |
diff --git a/docs/deployments/19-bm/techniques.md b/docs/deployments/19-bm/techniques.md
deleted file mode 100644
index 11800eb9d34..00000000000
--- a/docs/deployments/19-bm/techniques.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Techniques
-
-*What 19-BM is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 19-BM is pre-build, so the techniques below are design intent: the APS Practices that will bind them are carried pending on the [APS site page](../aps/index.md#the-techniques-adapted-here). The function view survives the eventual equipment choices, which is why it can be written before the hardware is procured.
-
-19-BM is a single-mode beamline: filtered white-beam tomography. There is no monochromator and no mirror, so unlike 2-BM there is no beam-mode or energy-change technique. The beam spectrum is set by selecting filters in the F3-30 unit, and the science variety is in the acquisition cadence, not the optics.
-
-| Technique | Catalog Method | What it is for |
-| --- | --- | --- |
-| Filtered white-beam tomography | `tomography` | the standard micron-resolution CT scan |
-| Continuous-rotation tomography | `continuous_rotation_tomography` | high-throughput acquisition, the autonomous workhorse |
-| Streaming tomography | `streaming_tomography` | live reconstruction feedback |
-| Dark / flat fields | `dark_field`, `flat_field` | the reference frames every reconstruction needs |
-| First light | `first_light` | commissioning the beam onto the detector |
-
-A few points of intent shape the model:
-
-- **Autonomy and throughput are the point.** 19-BM is built to run unattended at a high scan cadence with a robotic sample changer feeding it. The technique layer is ordinary tomography; what is distinctive is the autonomous operation around it (see [Governance](governance.md)) and the sample-exchange loop (see [Sample](sample.md)).
-- **Spectrum is set by filtering, not optics.** Selecting Si / Ge / Cu filters in the F3-30 unit hardens or softens the white-beam spectrum. This replaces the energy-selection techniques 2-BM has, which depend on its monochromator.
-- **Single beam mode.** There is one set of optics and one mode, so there is no beam-mode-change technique to model.
-
-The concrete acquisition recipes (scan sequences, exposure, filter choices) are not written yet; they join as the beamline approaches commissioning. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/2-id/governance.md b/docs/deployments/2-id/governance.md
deleted file mode 100644
index 60184261226..00000000000
--- a/docs/deployments/2-id/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at 2-ID, and the trust shape that will gate it. Design-phase.*
-
-Governance at 2-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-2-ID is a design-phase scaffold in CORA, so this shape is not yet instantiated. The 2-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 2-ID operator roster.
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them.
-
-2-ID-D adds one governance shape the tomography pilots do not have: an **autonomous alignment agent in the loop**. The EAA microprobe agent drives the zone-plate autofocus and drift-correction loop, and its own examples gate every action behind an operator confirmation, with motion and beam disabled by default. In CORA's model that maps cleanly: EAA registers as an [Agent](model.md#how-eaa-fits) whose proposals become Decisions, and the permit and clearance adjudication is the interpose point where an agent's proposed move is allowed or denied. The default-deny posture EAA already carries is the shape CORA's Conduit and Policy would enforce, not a new invention.
-
-The concrete Zone, Conduit, and Policy instances, the operator pool, and the agent-authority policy land when the deployment approaches the point where CORA drives 2-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/2-id/model.md b/docs/deployments/2-id/model.md
deleted file mode 100644
index 4b9f2e31032..00000000000
--- a/docs/deployments/2-id/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 2-ID content lives, a scanning-fluorescence microprobe whose EAA autofocus loop dissolves into a CORA-conducted Run with an agent in the loop, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 2-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## How EAA fits
-
-This scaffold is mined from the [Experiment Automation Agents (EAA)](https://github.com/AdvancedPhotonSource/EAA) APS-microprobe integration (`packages/eaa-imaging/.../tool/imaging/aps_mic`) and its [2-ID-D launcher](https://github.com/AdvancedPhotonSource/eaa_driver_scripts_aps_2idd). EAA is read as data about the beamline, not copied as a design. CORA does not add a "confirm the EAA tool" row anywhere; it dissolves EAA into three things it already models:
-
-- **Conductor replaces the orchestration.** EAA's `scan_control` runs the autofocus loop (acquire a 2D map, take a line scan, register it, step the `zp_z` focus axis, minimise the spot width) and submits the `fly2d` / `step1d` rasters over the EPICS scanRecord. That set-then-measure-until-criterion sequencing is what CORA's Conductor takes over: CORA owns the [Run lifecycle](../../architecture/modules/run/index.md) (start, hold, abort, close), the durable scan state, and the stopping governance. EAA fuses policy and sequencing in one loop; CORA draws the seam through the middle.
-- **EPICS stays floor.** The EPICS scanRecord and sscan IOC, the motor PVs, the hardware-triggered raster, and the downstream `XRF-Maps` fitting are the floor and the compute edge. CORA observes and conducts over them; it never replaces them.
-- **EAA registers as an Agent.** EAA's tactical decide loops (the LLM agent loop and the deterministic Bayesian-optimization parameter tuner) register as an external [Agent](../../architecture/modules/agent/index.md). Each proposed move and objective value becomes a Decision, with the LLM route recorded through the inference-recorder provenance path. EAA's own per-tool default-deny gate (operator confirmation required, motion and beam disabled by default) is exactly the interpose point CORA's permit and clearance adjudication occupies.
-
-The net is regime-2 for CORA's runtime model: a CORA-conducted, multi-step compute-and-move Run, with an external agent proposing inside the loop. That is the shape the edge-runtime work anticipates, surfacing here as a concrete first consumer rather than a hypothetical.
-
-## Deliberately not here yet
-
-These are the parts of 2-ID this scaffold leaves out on purpose. Each is a CORA scope or naming decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](questions.md).
-
-- **The sister experiment hutch and the hutch roster.** The descriptor models one root Unit Asset `2-ID` with one experiment hutch (`2-ID-D`). Whether the sector adds a sister station (a 2-ID-E-class hutch) as a second hutch sub-tree, and where the shared optics sit, is held until `TOPO-1` resolves the roster. The root identity and `facility_code` binding do not migrate when it does: adding a hutch adds Component sub-trees, it does not re-home the root. This mirrors the 32-ID scaffold modelling only 32-ID-C and deferring 32-ID-B.
-
-- **Coining the scanning-fluorescence Method.** `scanning_fluorescence_microscopy` is a new modality (point-raster XRF, mechanistically unlike full-field projection). A design-phase scaffold coins no Method, so it is named and rendered unlinked, carried as a pending Practice (`METHOD-1`). It is earned into the catalog when a confirmed scenario uses it and a naming review accepts the name.
-
-- **Scanning fluorescence tomography as a Plan, not a Method.** A rotation over a sequence of XRF maps is a Plan setpoint over the scanning-XRF Method, the same way laminography is a tomography Plan at a tilt setpoint at 2-BM. It is not a separate Method, and it waits on a confirmed rotation axis (`ENV-1`).
-
-- **Micro-XANES and ptychography.** Named by world-facts but absent from EAA's `aps_mic` code path; ptychography also needs a coherent-diffraction detector this scaffold does not model. Modelling either now would be invention.
-
-- **Integration scenarios and vendor Models.** No `test_2id_*.py` registers 2-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real, and hard-registering a simulation-mined, pre-confirmation beamline would commit speculative structure. Both land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/2-id/notes.md b/docs/deployments/2-id/notes.md
new file mode 100644
index 00000000000..5a1b88cf22c
--- /dev/null
+++ b/docs/deployments/2-id/notes.md
@@ -0,0 +1,134 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 2-ID is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. This scaffold models 2-ID's 2-ID-D microprobe hutch, so the technique below is the scanning fluorescence one, carried as design intent. The function view survives the eventual hardware choices, which is why it can be written before the optics are confirmed.
+
+### Scanning fluorescence microscopy
+
+The microprobe focuses the monochromatic beam through a Fresnel zone plate to a small spot and rasters the sample through it, recording an X-ray fluorescence spectrum at each point with an energy-dispersive detector. Element maps are fit from the per-point spectra downstream (the EAA `XRF-Maps` lineage: scan data to fitted maps).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Scanning XRF mapping | `scanning_fluorescence_microscopy` (pending) | 2D fly raster or 1D step scan of the sample through the focused spot; a fluorescence spectrum per point |
+
+This is a **new modality** for CORA. Every other deployment images by full-field projection and a rotation; this one builds an image point by point from a focused probe. There is no catalog Method for point-raster scanning fluorescence, so `scanning_fluorescence_microscopy` is named here but **not coined**: it renders unlinked, and the [APS Practice](../aps/index.md#the-techniques-adapted-here) that adapts it is carried pending (`METHOD-1`). The Method is earned into the catalog when 2-ID enters the pilot scope and a naming review accepts it, not in a design-phase scaffold. The coining decision is recorded on [Model](#deliberately-not-here-yet).
+
+### Energy
+
+2-ID-D runs monochromatic, the energy set by the upstream monochromator (assumed double-crystal, range unconfirmed, `MONO-1`). Scanning XANES (stepping the energy across an absorption edge per pixel) is a world-fact capability of the beamline but is absent from EAA's `aps_mic` code path, so it is not modelled here (see [Not modelled yet](#not-modelled-yet)).
+
+### Not modelled yet
+
+These are techniques the beamline is known to do but that this scaffold defers, because EAA does not evidence them or because they need hardware not yet modelled:
+
+- **Scanning fluorescence tomography.** A rotation over a sequence of XRF maps. This is a Plan setpoint over the scanning-XRF Method, not a separate Method (mirroring the 2-BM decision that laminography is a tomography Plan at a tilt setpoint), and it needs a rotation axis the endstation is not yet modelled with (`ENV-1`). It joins when the rotation axis is confirmed.
+- **Micro-XANES and ptychography.** Named by world-facts about the beamline but absent from EAA's `aps_mic` code path. Ptychography in particular needs a coherent-diffraction (transmission) detector this scaffold does not model. Modelling either now would be invention.
+
+The concrete acquisition recipes (scan ranges, dwell times, target elements, energies) are not written yet; they join as the deployment approaches the point where CORA drives 2-ID. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who will act at 2-ID, and the trust shape that will gate it. Design-phase.*
+
+Governance at 2-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+2-ID is a design-phase scaffold in CORA, so this shape is not yet instantiated. The 2-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 2-ID operator roster.
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them.
+
+2-ID-D adds one governance shape the tomography pilots do not have: an **autonomous alignment agent in the loop**. The EAA microprobe agent drives the zone-plate autofocus and drift-correction loop, and its own examples gate every action behind an operator confirmation, with motion and beam disabled by default. In CORA's model that maps cleanly: EAA registers as an [Agent](#how-eaa-fits) whose proposals become Decisions, and the permit and clearance adjudication is the interpose point where an agent's proposed move is allowed or denied. The default-deny posture EAA already carries is the shape CORA's Conduit and Policy would enforce, not a new invention.
+
+The concrete Zone, Conduit, and Policy instances, the operator pool, and the agent-authority policy land when the deployment approaches the point where CORA drives 2-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 2-ID content lives, a scanning-fluorescence microprobe whose EAA autofocus loop dissolves into a CORA-conducted Run with an agent in the loop, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 2-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### How EAA fits
+
+This scaffold is mined from the [Experiment Automation Agents (EAA)](https://github.com/AdvancedPhotonSource/EAA) APS-microprobe integration (`packages/eaa-imaging/.../tool/imaging/aps_mic`) and its [2-ID-D launcher](https://github.com/AdvancedPhotonSource/eaa_driver_scripts_aps_2idd). EAA is read as data about the beamline, not copied as a design. CORA does not add a "confirm the EAA tool" row anywhere; it dissolves EAA into three things it already models:
+
+- **Conductor replaces the orchestration.** EAA's `scan_control` runs the autofocus loop (acquire a 2D map, take a line scan, register it, step the `zp_z` focus axis, minimise the spot width) and submits the `fly2d` / `step1d` rasters over the EPICS scanRecord. That set-then-measure-until-criterion sequencing is what CORA's Conductor takes over: CORA owns the [Run lifecycle](../../architecture/modules/run/index.md) (start, hold, abort, close), the durable scan state, and the stopping governance. EAA fuses policy and sequencing in one loop; CORA draws the seam through the middle.
+- **EPICS stays floor.** The EPICS scanRecord and sscan IOC, the motor PVs, the hardware-triggered raster, and the downstream `XRF-Maps` fitting are the floor and the compute edge. CORA observes and conducts over them; it never replaces them.
+- **EAA registers as an Agent.** EAA's tactical decide loops (the LLM agent loop and the deterministic Bayesian-optimization parameter tuner) register as an external [Agent](../../architecture/modules/agent/index.md). Each proposed move and objective value becomes a Decision, with the LLM route recorded through the inference-recorder provenance path. EAA's own per-tool default-deny gate (operator confirmation required, motion and beam disabled by default) is exactly the interpose point CORA's permit and clearance adjudication occupies.
+
+The net is regime-2 for CORA's runtime model: a CORA-conducted, multi-step compute-and-move Run, with an external agent proposing inside the loop. That is the shape the edge-runtime work anticipates, surfacing here as a concrete first consumer rather than a hypothetical.
+
+### Deliberately not here yet
+
+These are the parts of 2-ID this scaffold leaves out on purpose. Each is a CORA scope or naming decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](#open-questions).
+
+- **The sister experiment hutch and the hutch roster.** The descriptor models one root Unit Asset `2-ID` with one experiment hutch (`2-ID-D`). Whether the sector adds a sister station (a 2-ID-E-class hutch) as a second hutch sub-tree, and where the shared optics sit, is held until `TOPO-1` resolves the roster. The root identity and `facility_code` binding do not migrate when it does: adding a hutch adds Component sub-trees, it does not re-home the root. This mirrors the 32-ID scaffold modelling only 32-ID-C and deferring 32-ID-B.
+
+- **Coining the scanning-fluorescence Method.** `scanning_fluorescence_microscopy` is a new modality (point-raster XRF, mechanistically unlike full-field projection). A design-phase scaffold coins no Method, so it is named and rendered unlinked, carried as a pending Practice (`METHOD-1`). It is earned into the catalog when a confirmed scenario uses it and a naming review accepts the name.
+
+- **Scanning fluorescence tomography as a Plan, not a Method.** A rotation over a sequence of XRF maps is a Plan setpoint over the scanning-XRF Method, the same way laminography is a tomography Plan at a tilt setpoint at 2-BM. It is not a separate Method, and it waits on a confirmed rotation axis (`ENV-1`).
+
+- **Micro-XANES and ptychography.** Named by world-facts but absent from EAA's `aps_mic` code path; ptychography also needs a coherent-diffraction detector this scaffold does not model. Modelling either now would be invention.
+
+- **Integration scenarios and vendor Models.** No `test_2id_*.py` registers 2-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real, and hard-registering a simulation-mined, pre-confirmation beamline would commit speculative structure. Both land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 2-ID team to confirm before the model can be trusted.*
+
+2-ID is a design-phase scaffold mined from the [EAA](https://github.com/AdvancedPhotonSource/EAA) APS-microprobe integration and its [2-ID-D launcher](https://github.com/AdvancedPhotonSource/eaa_driver_scripts_aps_2idd). The launcher is a simulation and EAA does not describe the source optics, so almost every value on the [device pages](index.md) is carried as a fact still to confirm. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](#deliberately-not-here-yet) instead). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model, so CORA cannot finalize the shape without it), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
+
+### Topology and scope
+
+The one structural unknown: the Sector 2 hutch roster and where the shared optics sit. The answer decides how many experiment hutches hang off the `2-ID` root and whether the source optics are one shared train or per-hutch.
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | What is Sector 2's experiment-hutch roster (2-ID-D plus which sister stations), which hutch do the source optics serve, what is the upstream optics-hutch identity, and what is the post-APS-U layout of the sector? | One root Unit Asset `2-ID` with one modelled experiment hutch `2-ID-D`; the sister hutch(es) and the optics-hutch are unmodelled pending this answer. | The hutch roster, the optics-hutch Enclosure, and one-vs-many hutch sub-trees in the [descriptor](index.md). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | What are the EPICS PV handles (and drive crates / IOC hosts) for each modelled device, and the Bluesky / scanRecord configuration for the raster? | Control handles are unassigned; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
+| PSS-1 | Blocks-go-live | What is the PSS search-and-secure permit signal for the 2-ID-D hutch (and the other hutches once `TOPO-1` resolves the roster)? | The 2-ID-D hutch exists with a permit signal to be named. | The Enclosure permit signal. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The Sector 2 insertion-device source: device type, period, gap, and whether one source feeds more than one hutch. | One `InsertionDevice` Asset (undulator); type and period unconfirmed. | The insertion-device specs. |
+| SRC-2 | Nice-to-have | The front-end and beam-defining optics between the source and the zone plate (front-end mask, window, white-beam and beam-defining slits), which EAA does not describe. | None modelled; the source stretch from front end to zone plate is carried as undescribed. | The front-end and beam-defining optics. |
+| MONO-1 | Blocks-go-live | The monochromator: is it a double-crystal Si monochromator, what is its crystal and energy range, what are its axes, and which optics hutch is it in? | One `Monochromator` Asset, double-crystal, energy range unconfirmed; located upstream. | The monochromator presence, crystal, axes, and energy model. |
+| OPTICS-1 | Blocks-go-live | The probe-forming Fresnel zone plate parameters (outermost-zone width, diameter, material) that set the spot size, and the order-sorting aperture that pairs with it. | One `ZonePlate` Asset (catalog Family) with a `zp_z` focus axis; the order-sorting aperture is folded in, not separately modelled. | The zone-plate spec and the order-sorting aperture. |
+
+### Sample-scanning endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| AXIS-1 | Blocks-go-live | The sample-scanning axis complement: the horizontal scan axis (EAA evidences vertical `samy` and standoff `samz` but not the horizontal raster axis), and the coarse-stage vs fine-piezo split a microprobe carries. | One coarse `SamplePositioning` stack (`LinearStage`); the horizontal scan axis and coarse/fine split unconfirmed. | The sample-stage axes and the coarse/fine model. |
+| ENV-1 | Nice-to-have | The sample environment: any in-situ stage (cryo, heating), and whether the endstation carries a rotation axis (which scanning fluorescence tomography would need). | No sample environment and no rotation axis modelled. | The sample-environment Fixtures and any rotation axis. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The energy-dispersive fluorescence detector: model, number of elements / segmentation, and energy resolution. | One fluorescence-detector Asset bound to the catalog `EnergyDispersiveSpectrometer` Family; model and channels unconfirmed. | The detector Model binding. |
+| DET-2 | Nice-to-have | The detection readout chain: the preamplifier (EAA names a `Preamp1`), the EPICS scalers, and the I0 flux monitors (ion chambers) the scan normalizes against. | A preamplifier, scalers, and flux monitors exist as the readout chain; identities unconfirmed and not separately modelled. | The readout-chain Assets and the normalization model. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | What continuously-available supplies does the 2-ID-D endstation draw on (cooling water, and any sample-environment gases)? | A photon beam and cooling water; sample-environment supplies unconfirmed. | The Supply records. |
diff --git a/docs/deployments/2-id/questions.md b/docs/deployments/2-id/questions.md
deleted file mode 100644
index f23ff24522f..00000000000
--- a/docs/deployments/2-id/questions.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Open questions
-
-*What CORA needs the 2-ID team to confirm before the model can be trusted.*
-
-2-ID is a design-phase scaffold mined from the [EAA](https://github.com/AdvancedPhotonSource/EAA) APS-microprobe integration and its [2-ID-D launcher](https://github.com/AdvancedPhotonSource/eaa_driver_scripts_aps_2idd). The launcher is a simulation and EAA does not describe the source optics, so almost every value on the [device pages](index.md) is carried as a fact still to confirm. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](model.md#deliberately-not-here-yet) instead). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model, so CORA cannot finalize the shape without it), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
-
-## Topology and scope
-
-The one structural unknown: the Sector 2 hutch roster and where the shared optics sit. The answer decides how many experiment hutches hang off the `2-ID` root and whether the source optics are one shared train or per-hutch.
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | What is Sector 2's experiment-hutch roster (2-ID-D plus which sister stations), which hutch do the source optics serve, what is the upstream optics-hutch identity, and what is the post-APS-U layout of the sector? | One root Unit Asset `2-ID` with one modelled experiment hutch `2-ID-D`; the sister hutch(es) and the optics-hutch are unmodelled pending this answer. | The hutch roster, the optics-hutch Enclosure, and one-vs-many hutch sub-trees in the [descriptor](index.md). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | What are the EPICS PV handles (and drive crates / IOC hosts) for each modelled device, and the Bluesky / scanRecord configuration for the raster? | Control handles are unassigned; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
-| PSS-1 | Blocks-go-live | What is the PSS search-and-secure permit signal for the 2-ID-D hutch (and the other hutches once `TOPO-1` resolves the roster)? | The 2-ID-D hutch exists with a permit signal to be named. | The Enclosure permit signal. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The Sector 2 insertion-device source: device type, period, gap, and whether one source feeds more than one hutch. | One `InsertionDevice` Asset (undulator); type and period unconfirmed. | The insertion-device specs. |
-| SRC-2 | Nice-to-have | The front-end and beam-defining optics between the source and the zone plate (front-end mask, window, white-beam and beam-defining slits), which EAA does not describe. | None modelled; the source stretch from front end to zone plate is carried as undescribed. | The front-end and beam-defining optics. |
-| MONO-1 | Blocks-go-live | The monochromator: is it a double-crystal Si monochromator, what is its crystal and energy range, what are its axes, and which optics hutch is it in? | One `Monochromator` Asset, double-crystal, energy range unconfirmed; located upstream. | The monochromator presence, crystal, axes, and energy model. |
-| OPTICS-1 | Blocks-go-live | The probe-forming Fresnel zone plate parameters (outermost-zone width, diameter, material) that set the spot size, and the order-sorting aperture that pairs with it. | One `ZonePlate` Asset (catalog Family) with a `zp_z` focus axis; the order-sorting aperture is folded in, not separately modelled. | The zone-plate spec and the order-sorting aperture. |
-
-## Sample-scanning endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| AXIS-1 | Blocks-go-live | The sample-scanning axis complement: the horizontal scan axis (EAA evidences vertical `samy` and standoff `samz` but not the horizontal raster axis), and the coarse-stage vs fine-piezo split a microprobe carries. | One coarse `SamplePositioning` stack (`LinearStage`); the horizontal scan axis and coarse/fine split unconfirmed. | The sample-stage axes and the coarse/fine model. |
-| ENV-1 | Nice-to-have | The sample environment: any in-situ stage (cryo, heating), and whether the endstation carries a rotation axis (which scanning fluorescence tomography would need). | No sample environment and no rotation axis modelled. | The sample-environment Fixtures and any rotation axis. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The energy-dispersive fluorescence detector: model, number of elements / segmentation, and energy resolution. | One fluorescence-detector Asset bound to the catalog `EnergyDispersiveSpectrometer` Family; model and channels unconfirmed. | The detector Model binding. |
-| DET-2 | Nice-to-have | The detection readout chain: the preamplifier (EAA names a `Preamp1`), the EPICS scalers, and the I0 flux monitors (ion chambers) the scan normalizes against. | A preamplifier, scalers, and flux monitors exist as the readout chain; identities unconfirmed and not separately modelled. | The readout-chain Assets and the normalization model. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | What continuously-available supplies does the 2-ID-D endstation draw on (cooling water, and any sample-environment gases)? | A photon beam and cooling water; sample-environment supplies unconfirmed. | The Supply records. |
diff --git a/docs/deployments/2-id/techniques.md b/docs/deployments/2-id/techniques.md
deleted file mode 100644
index eb1a1510d68..00000000000
--- a/docs/deployments/2-id/techniques.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Techniques
-
-*What the modelled part of 2-ID is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. This scaffold models 2-ID's 2-ID-D microprobe hutch, so the technique below is the scanning fluorescence one, carried as design intent. The function view survives the eventual hardware choices, which is why it can be written before the optics are confirmed.
-
-## Scanning fluorescence microscopy
-
-The microprobe focuses the monochromatic beam through a Fresnel zone plate to a small spot and rasters the sample through it, recording an X-ray fluorescence spectrum at each point with an energy-dispersive detector. Element maps are fit from the per-point spectra downstream (the EAA `XRF-Maps` lineage: scan data to fitted maps).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Scanning XRF mapping | `scanning_fluorescence_microscopy` (pending) | 2D fly raster or 1D step scan of the sample through the focused spot; a fluorescence spectrum per point |
-
-This is a **new modality** for CORA. Every other deployment images by full-field projection and a rotation; this one builds an image point by point from a focused probe. There is no catalog Method for point-raster scanning fluorescence, so `scanning_fluorescence_microscopy` is named here but **not coined**: it renders unlinked, and the [APS Practice](../aps/index.md#the-techniques-adapted-here) that adapts it is carried pending (`METHOD-1`). The Method is earned into the catalog when 2-ID enters the pilot scope and a naming review accepts it, not in a design-phase scaffold. The coining decision is recorded on [Model](model.md#deliberately-not-here-yet).
-
-## Energy
-
-2-ID-D runs monochromatic, the energy set by the upstream monochromator (assumed double-crystal, range unconfirmed, `MONO-1`). Scanning XANES (stepping the energy across an absorption edge per pixel) is a world-fact capability of the beamline but is absent from EAA's `aps_mic` code path, so it is not modelled here (see [Not modelled yet](#not-modelled-yet)).
-
-## Not modelled yet
-
-These are techniques the beamline is known to do but that this scaffold defers, because EAA does not evidence them or because they need hardware not yet modelled:
-
-- **Scanning fluorescence tomography.** A rotation over a sequence of XRF maps. This is a Plan setpoint over the scanning-XRF Method, not a separate Method (mirroring the 2-BM decision that laminography is a tomography Plan at a tilt setpoint), and it needs a rotation axis the endstation is not yet modelled with (`ENV-1`). It joins when the rotation axis is confirmed.
-- **Micro-XANES and ptychography.** Named by world-facts about the beamline but absent from EAA's `aps_mic` code path. Ptychography in particular needs a coherent-diffraction (transmission) detector this scaffold does not model. Modelling either now would be invention.
-
-The concrete acquisition recipes (scan ranges, dwell times, target elements, energies) are not written yet; they join as the deployment approaches the point where CORA drives 2-ID. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/32-id/governance.md b/docs/deployments/32-id/governance.md
deleted file mode 100644
index 61f5372c48a..00000000000
--- a/docs/deployments/32-id/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 32-ID, and the trust shape that will gate it. Design-phase.*
-
-Governance at 32-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-32-ID is a design-phase scaffold in CORA, so this shape is not yet instantiated. The 32-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 32-ID operator roster.
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 32-ID adds hazard classes beyond the 2-BM tomography envelope, a class-4 laser on the additive-manufacturing rig, pressurized helium and cryogens, that an experiment Clearance would carry; those land with the instruments that bring them, which are deferred (see [Model](model.md#deliberately-not-here-yet)).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 32-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/32-id/model.md b/docs/deployments/32-id/model.md
deleted file mode 100644
index 55e537c1082..00000000000
--- a/docs/deployments/32-id/model.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 32-ID content lives, a TXM nano-tomography beamline whose optic classes graduated once FXI shared them, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 32-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-These are the parts of 32-ID this scaffold leaves out on purpose. Each is a CORA scope decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](questions.md).
-
-- **The canted branch structure.** The descriptor models one root Unit Asset and one optics train. Whether 32-ID becomes two root Assets (per branch) is held until `TOPO-1` resolves the canted geometry. The root identity and `facility_code` binding do not migrate when it does: a one-to-two split adds Component sub-trees, it does not re-home the root.
-
-- **The white-to-mono beam-mode vocabulary.** Whether the mode switch is a new Capability or an extension of the existing `energy_change` Capability is decided when the mode is modelled, not now. The world-fact half (the switch structure and sequence) is `MODE-1`; the vocabulary half is this decision.
-
-- **High-speed imaging and ultrafast diffraction (32-ID-B).** White-beam high-speed imaging reuses the imaging spine, but ultrafast white-beam diffraction (HSID) produces diffraction patterns, which have no precedent in CORA's all-imaging catalog. Whether diffraction is in CORA's scope is an owner decision; until it is made, neither instrument is modelled and no diffraction Capability is coined.
-
-- **The additive-manufacturing laser rig (32-ID-B).** The powder-bed-fusion rig is a user-brought, actuated, non-X-ray energy source with no Family or Role precedent. The default is to model the class-4 laser as a `Clearance` hazard on an experiment, not as an Asset CORA drives. Whether CORA ever orchestrates the laser is an owner decision.
-
-- **The projection microscope (PM).** The source docs for the PM are still "space holder", and its most distinctive parts (a helium-atmosphere KB system, a robotic sample-exchange arm) are the least documented. Modelling it now would be invention. The robotic sample changer in particular would force a sample-changer shape CORA does not have; it waits until the PM is documented and a real device list exists.
-
-- **Integration scenarios and vendor Models.** No `test_32id_*.py` registers 32-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real, and hard-registering a design-phase, pre-APS-U-mixed beamline would commit speculative structure. Both land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/32-id/notes.md b/docs/deployments/32-id/notes.md
new file mode 100644
index 00000000000..de1934780c4
--- /dev/null
+++ b/docs/deployments/32-id/notes.md
@@ -0,0 +1,126 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 32-ID is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. This scaffold models 32-ID's TXM endstation, so the techniques below are the TXM ones, carried as design intent. The function view survives the eventual hardware choices, which is why it can be written before the optics are confirmed.
+
+### TXM nano-tomography
+
+The transmission X-ray microscope images the internal structure of a sample at nanometre-class resolution by magnifying the transmitted beam through a Fresnel zone plate, then rotating the sample for a tomographic reconstruction.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Nano-tomography | `tomography` | step-scan projections over a rotation, magnified by the zone-plate optics |
+| Zernike phase-contrast nano-tomography | `tomography` | the phase ring is inserted for phase contrast; a Plan setting over the same Method, not a separate Method |
+
+Both realize `cora.capability.tomography` and need the [TXM sample stage](sample.md) and the [TXM detector](detector.md). Phase contrast is a configuration of the same tomography Method (the phase ring inserted), mirroring the 2-BM decision that laminography is a tomography Plan at a tilt setpoint rather than a new Method.
+
+### Energy and beam mode
+
+32-ID delivers white or monochromatic beam, selected by the P4-50 mode shutter. The monochromatic branch uses the Si(111) monochromator over a 7 to 40 keV range. Whether CORA models the white-to-mono switch as a new Capability or as an extension of the existing `energy_change` vocabulary is an open design decision recorded on [Model](#model); the world-fact half (the switch structure) is `MODE-1` on [Open questions](#open-questions).
+
+### Not modelled yet
+
+32-ID's other techniques run on instruments this scaffold defers (see [Model](#deliberately-not-here-yet)): white-beam high-speed imaging and ultrafast diffraction (32-ID-B), in-situ additive-manufacturing imaging (32-ID-B), and projection microscopy. Their Methods join when those instruments are modelled.
+
+The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the deployment approaches the point where CORA drives 32-ID. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who will act at 32-ID, and the trust shape that will gate it. Design-phase.*
+
+Governance at 32-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+32-ID is a design-phase scaffold in CORA, so this shape is not yet instantiated. The 32-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 32-ID operator roster.
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 32-ID adds hazard classes beyond the 2-BM tomography envelope, a class-4 laser on the additive-manufacturing rig, pressurized helium and cryogens, that an experiment Clearance would carry; those land with the instruments that bring them, which are deferred (see [Model](#deliberately-not-here-yet)).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 32-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 32-ID content lives, a TXM nano-tomography beamline whose optic classes graduated once FXI shared them, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 32-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+These are the parts of 32-ID this scaffold leaves out on purpose. Each is a CORA scope decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](#open-questions).
+
+- **The canted branch structure.** The descriptor models one root Unit Asset and one optics train. Whether 32-ID becomes two root Assets (per branch) is held until `TOPO-1` resolves the canted geometry. The root identity and `facility_code` binding do not migrate when it does: a one-to-two split adds Component sub-trees, it does not re-home the root.
+
+- **The white-to-mono beam-mode vocabulary.** Whether the mode switch is a new Capability or an extension of the existing `energy_change` Capability is decided when the mode is modelled, not now. The world-fact half (the switch structure and sequence) is `MODE-1`; the vocabulary half is this decision.
+
+- **High-speed imaging and ultrafast diffraction (32-ID-B).** White-beam high-speed imaging reuses the imaging spine, but ultrafast white-beam diffraction (HSID) produces diffraction patterns, which have no precedent in CORA's all-imaging catalog. Whether diffraction is in CORA's scope is an owner decision; until it is made, neither instrument is modelled and no diffraction Capability is coined.
+
+- **The additive-manufacturing laser rig (32-ID-B).** The powder-bed-fusion rig is a user-brought, actuated, non-X-ray energy source with no Family or Role precedent. The default is to model the class-4 laser as a `Clearance` hazard on an experiment, not as an Asset CORA drives. Whether CORA ever orchestrates the laser is an owner decision.
+
+- **The projection microscope (PM).** The source docs for the PM are still "space holder", and its most distinctive parts (a helium-atmosphere KB system, a robotic sample-exchange arm) are the least documented. Modelling it now would be invention. The robotic sample changer in particular would force a sample-changer shape CORA does not have; it waits until the PM is documented and a real device list exists.
+
+- **Integration scenarios and vendor Models.** No `test_32id_*.py` registers 32-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real, and hard-registering a design-phase, pre-APS-U-mixed beamline would commit speculative structure. Both land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 32-ID team to confirm before the model can be trusted.*
+
+32-ID is a design-phase scaffold built from the published [32-ID docs](https://github.com/decarlof/32id-docs), which mix pre-APS-U and current values, so almost every value on the [device pages](index.md) is carried as a fact still to confirm. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](#deliberately-not-here-yet) instead). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model, so CORA cannot finalize the shape without it), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
+
+### Topology and scope
+
+The one structural unknown: how the canted source and its branches map onto CORA's Asset model. The answer decides whether 32-ID is one root Asset or two.
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | 32-ID is canted: two undulators feeding two branches. Do `32-ID-B` and `32-ID-C` run off separate beams (two canted branches), and does the `32-ID-A` optics set (mask, slits, monochromator, mode shutter) serve both branches or is it duplicated per branch? Which undulator feeds which branch? | One root Unit Asset `32-ID` with one optics train; the branch multiplicity is unmodelled pending this answer. | One-vs-two root Assets and one-vs-two beam walks in the [descriptor](index.md). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | What are the EPICS PV handles (and drive crates / IOC hosts) for each modelled device? | Control handles are unassigned; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
+| PSS-1 | Blocks-go-live | What are the PSS search-and-secure permit signals for the three hutches (`32-ID-A`, `-B`, `-C`)? | Three hutches exist with permit signals to be named. | The Enclosure permit signals. |
+| BLEPS-1 | Nice-to-have | Are the BLEPS (equipment-protection) fault and status signals readable as PVs for an external observer, and which map to a utility versus a specific device? CORA observes outcomes only; it never models the interlock logic. | Utility faults map to Supply status, device faults to an Asset condition; the matrix is not modelled. | The Supply and Asset condition mapping. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The exact device types and parameters of the two canted undulators (the source table lists "Planar 1.35" downstream and "Planar 2.8" upstream; a "U33" tuning curve is published). How do these labels relate, and what are the periods and gaps? | Two `InsertionDevice` Assets, downstream and upstream, planar; periods and the U33 relationship unconfirmed. | The insertion-device specs. |
+| SRC-2 | Nice-to-have | The fixed front-end mask aperture and position, and the front-end window stack (count, material, thickness). | A beam-defining `Mask` near 24 m and a `Window` (Be assumed); sizes unconfirmed. | The front-end mask and window specs. |
+| MONO-1 | Blocks-go-live | The Si(111) monochromator detail: per-axis motors, energy range over the 7 to 40 keV span, and whether it drives from a saved per-energy table. | One `Monochromator` Asset, Si(111), 7 to 40 keV; axes and saved positions unconfirmed. | The monochromator axes and energy model. |
+| MODE-1 | Blocks-build | The white-beam to monochromatic switch (the P4-50 mode shutter with its white-beam stop and combined mono stops). Is this a per-branch hard split (one branch always white, one always mono) or a switchable mode on one optics set, and what is the switching sequence and interlock? | A `ModeShutter` plus beam stops; switching is a coordinated, interlocked move, structure tied to TOPO-1. | The beam-mode model (and whether it is a new Capability or an `energy_change` extension, decided on [Model](#model)). |
+| LAYOUT-1 | Nice-to-have | A single z-coordinate reference for the layout. The published docs give per-hutch positions but no common origin. | z values are carried as approximate from-source and flagged confirm. | Exact device z positions. |
+
+### TXM endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TXM-1 | Blocks-go-live | Is the published TXM component list current post-APS-U, or does it carry pre-APS-U hardware? Specifically the granite stages, the rotation stage (Aerotech assumed), and the sample-positioning stack (Kohzu assumed). | The published overview is taken as current; stage models and axes carried confirm. | The TXM stage Assets and models. |
+| OPTICS-1 | Blocks-go-live | What is the beam-condensing optic upstream of the sample: a capillary condenser, a condenser zone plate, or KB optics? | One `Condenser` Asset bound to the catalog Family; optical type unconfirmed. | The condenser optic identity. |
+| OPTICS-2 | Blocks-go-live | The objective Fresnel zone plate parameters (outermost-zone width, diameter, material) that set the TXM resolution. | One `ZonePlate` Asset bound to the catalog Family; parameters unconfirmed. | The zone-plate spec. |
+| OPTICS-3 | Nice-to-have | The Zernike phase ring used for phase contrast: its parameters and whether it is inserted or retracted per scan. | One `PhaseRing` Asset bound to the catalog Family; inserted/retracted state not modelled. | The phase-ring spec and state model. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The TXM detector camera model, sensor, and frame rate. | One `Camera` Asset; model and sensor unconfirmed. | The camera Model binding. |
+| DET-2 | Nice-to-have | The TXM indirect-detection objective magnification set and the scintillator material and thickness. | An `Objective` and a `Scintillator` Asset; details unconfirmed. | The detector optics specs. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | Is the TXM flight path helium-filled or evacuated, and what gas supplies does the endstation draw on? | A flight path exists; its gas is unconfirmed (the projection microscope uses helium, the TXM is unconfirmed). | The Supply records and flight-path model. |
diff --git a/docs/deployments/32-id/questions.md b/docs/deployments/32-id/questions.md
deleted file mode 100644
index 15cb11263de..00000000000
--- a/docs/deployments/32-id/questions.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Open questions
-
-*What CORA needs the 32-ID team to confirm before the model can be trusted.*
-
-32-ID is a design-phase scaffold built from the published [32-ID docs](https://github.com/decarlof/32id-docs), which mix pre-APS-U and current values, so almost every value on the [device pages](index.md) is carried as a fact still to confirm. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](model.md#deliberately-not-here-yet) instead). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model, so CORA cannot finalize the shape without it), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
-
-## Topology and scope
-
-The one structural unknown: how the canted source and its branches map onto CORA's Asset model. The answer decides whether 32-ID is one root Asset or two.
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | 32-ID is canted: two undulators feeding two branches. Do `32-ID-B` and `32-ID-C` run off separate beams (two canted branches), and does the `32-ID-A` optics set (mask, slits, monochromator, mode shutter) serve both branches or is it duplicated per branch? Which undulator feeds which branch? | One root Unit Asset `32-ID` with one optics train; the branch multiplicity is unmodelled pending this answer. | One-vs-two root Assets and one-vs-two beam walks in the [descriptor](index.md). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | What are the EPICS PV handles (and drive crates / IOC hosts) for each modelled device? | Control handles are unassigned; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
-| PSS-1 | Blocks-go-live | What are the PSS search-and-secure permit signals for the three hutches (`32-ID-A`, `-B`, `-C`)? | Three hutches exist with permit signals to be named. | The Enclosure permit signals. |
-| BLEPS-1 | Nice-to-have | Are the BLEPS (equipment-protection) fault and status signals readable as PVs for an external observer, and which map to a utility versus a specific device? CORA observes outcomes only; it never models the interlock logic. | Utility faults map to Supply status, device faults to an Asset condition; the matrix is not modelled. | The Supply and Asset condition mapping. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The exact device types and parameters of the two canted undulators (the source table lists "Planar 1.35" downstream and "Planar 2.8" upstream; a "U33" tuning curve is published). How do these labels relate, and what are the periods and gaps? | Two `InsertionDevice` Assets, downstream and upstream, planar; periods and the U33 relationship unconfirmed. | The insertion-device specs. |
-| SRC-2 | Nice-to-have | The fixed front-end mask aperture and position, and the front-end window stack (count, material, thickness). | A beam-defining `Mask` near 24 m and a `Window` (Be assumed); sizes unconfirmed. | The front-end mask and window specs. |
-| MONO-1 | Blocks-go-live | The Si(111) monochromator detail: per-axis motors, energy range over the 7 to 40 keV span, and whether it drives from a saved per-energy table. | One `Monochromator` Asset, Si(111), 7 to 40 keV; axes and saved positions unconfirmed. | The monochromator axes and energy model. |
-| MODE-1 | Blocks-build | The white-beam to monochromatic switch (the P4-50 mode shutter with its white-beam stop and combined mono stops). Is this a per-branch hard split (one branch always white, one always mono) or a switchable mode on one optics set, and what is the switching sequence and interlock? | A `ModeShutter` plus beam stops; switching is a coordinated, interlocked move, structure tied to TOPO-1. | The beam-mode model (and whether it is a new Capability or an `energy_change` extension, decided on [Model](model.md)). |
-| LAYOUT-1 | Nice-to-have | A single z-coordinate reference for the layout. The published docs give per-hutch positions but no common origin. | z values are carried as approximate from-source and flagged confirm. | Exact device z positions. |
-
-## TXM endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TXM-1 | Blocks-go-live | Is the published TXM component list current post-APS-U, or does it carry pre-APS-U hardware? Specifically the granite stages, the rotation stage (Aerotech assumed), and the sample-positioning stack (Kohzu assumed). | The published overview is taken as current; stage models and axes carried confirm. | The TXM stage Assets and models. |
-| OPTICS-1 | Blocks-go-live | What is the beam-condensing optic upstream of the sample: a capillary condenser, a condenser zone plate, or KB optics? | One `Condenser` Asset bound to the catalog Family; optical type unconfirmed. | The condenser optic identity. |
-| OPTICS-2 | Blocks-go-live | The objective Fresnel zone plate parameters (outermost-zone width, diameter, material) that set the TXM resolution. | One `ZonePlate` Asset bound to the catalog Family; parameters unconfirmed. | The zone-plate spec. |
-| OPTICS-3 | Nice-to-have | The Zernike phase ring used for phase contrast: its parameters and whether it is inserted or retracted per scan. | One `PhaseRing` Asset bound to the catalog Family; inserted/retracted state not modelled. | The phase-ring spec and state model. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The TXM detector camera model, sensor, and frame rate. | One `Camera` Asset; model and sensor unconfirmed. | The camera Model binding. |
-| DET-2 | Nice-to-have | The TXM indirect-detection objective magnification set and the scintillator material and thickness. | An `Objective` and a `Scintillator` Asset; details unconfirmed. | The detector optics specs. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | Is the TXM flight path helium-filled or evacuated, and what gas supplies does the endstation draw on? | A flight path exists; its gas is unconfirmed (the projection microscope uses helium, the TXM is unconfirmed). | The Supply records and flight-path model. |
diff --git a/docs/deployments/32-id/techniques.md b/docs/deployments/32-id/techniques.md
deleted file mode 100644
index 99b6e3d15a5..00000000000
--- a/docs/deployments/32-id/techniques.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Techniques
-
-*What the modelled part of 32-ID is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. This scaffold models 32-ID's TXM endstation, so the techniques below are the TXM ones, carried as design intent. The function view survives the eventual hardware choices, which is why it can be written before the optics are confirmed.
-
-## TXM nano-tomography
-
-The transmission X-ray microscope images the internal structure of a sample at nanometre-class resolution by magnifying the transmitted beam through a Fresnel zone plate, then rotating the sample for a tomographic reconstruction.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Nano-tomography | `tomography` | step-scan projections over a rotation, magnified by the zone-plate optics |
-| Zernike phase-contrast nano-tomography | `tomography` | the phase ring is inserted for phase contrast; a Plan setting over the same Method, not a separate Method |
-
-Both realize `cora.capability.tomography` and need the [TXM sample stage](sample.md) and the [TXM detector](detector.md). Phase contrast is a configuration of the same tomography Method (the phase ring inserted), mirroring the 2-BM decision that laminography is a tomography Plan at a tilt setpoint rather than a new Method.
-
-## Energy and beam mode
-
-32-ID delivers white or monochromatic beam, selected by the P4-50 mode shutter. The monochromatic branch uses the Si(111) monochromator over a 7 to 40 keV range. Whether CORA models the white-to-mono switch as a new Capability or as an extension of the existing `energy_change` vocabulary is an open design decision recorded on [Model](model.md); the world-fact half (the switch structure) is `MODE-1` on [Open questions](questions.md).
-
-## Not modelled yet
-
-32-ID's other techniques run on instruments this scaffold defers (see [Model](model.md#deliberately-not-here-yet)): white-beam high-speed imaging and ultrafast diffraction (32-ID-B), in-situ additive-manufacturing imaging (32-ID-B), and projection microscopy. Their Methods join when those instruments are modelled.
-
-The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the deployment approaches the point where CORA drives 32-ID. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/4-id/governance.md b/docs/deployments/4-id/governance.md
deleted file mode 100644
index a837f17147e..00000000000
--- a/docs/deployments/4-id/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 4-ID, and the trust shape that will gate it. First cut.*
-
-Governance at 4-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-4-ID is not yet driven by CORA, so this shape is not yet instantiated. The 4-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 4-ID operator roster (a placeholder `4-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 4-ID adds hazard classes beyond the imaging envelope, superconducting magnets with high stored energy and cryogens, a pump-probe laser, and pressurized high-pressure cells, that an experiment Clearance would carry; those land with the instruments that bring them as the sample environment firms (`MAG-1`, `SAMPLE-1`).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 4-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/4-id/model.md b/docs/deployments/4-id/model.md
deleted file mode 100644
index 9bf57b38cf3..00000000000
--- a/docs/deployments/4-id/model.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 4-ID content lives, the diffraction / magnetism / polarization deployment whose loose families graduated across the fleet, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 4-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Loose-Family graduation
-
-4-ID introduced eight device classes CORA had not earned into the catalog. Graduation needs two or more independent CORA deployments AND a settled abstraction. The 8-ID XPCS deployment adds the second independent beamline for `TemperatureController`, `Transfocator`, and `PositionMonitor`. `TemperatureController` has since graduated to a catalog Family: the parallel Diamond i22/i03/i11 rule-of-three settled the settable-actuator abstraction, and it presents the new `Regulator` Role. `Transfocator` has likewise graduated to a catalog Family: a CRL focusing optic earned across eight deployments, so 4-ID's CRL now reuses it like any catalog Family (its lens material and lenslet count stay a per-Asset spec, `OPT-2`). `PhaseRetarder` has likewise graduated to a catalog Family: a phase-retarder optic earned across 4-ID (three diamond phase-retarder stages), PETRA III P09 (shared phase-retarder circles), and PETRA III P22 (a third consumer via the shared P09 optics), and it presents the `Positioner` Role. `PolarizationAnalyzer` has likewise graduated to a catalog Family: a polarization-analysis positioner earned across 4-ID / i10 / ID32 / P09, so 4-ID's analyzer now reuses it like any catalog Family (its analyzer-crystal spec stays a per-Asset detail, `POL-2`). `PositionMonitor` has likewise graduated to a catalog Family: its own Sensor Family earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines), the cross-facility review resolving the fold-vs-promote question in favour of promote (distinct from the graduated `FluxMonitor` by measuring beam position and centroid, not flux; the per-Asset position-versus-intensity split stays open, `BPM-1`). The `Diffractometer` is the one that landed: as the `Assembly(Diffractometer)` blueprint (4-ID + 8-ID), which composes the catalog `Goniometer` Family, with an 8-ID Fixture scenario. `Magnet` has since graduated to a catalog Family: 4-ID was its first consumer, and the Diamond i10-1 and ESRF ID32 magnets brought it to a rule-of-three, settling the settable-field abstraction, so it presents the `Regulator` Role like `TemperatureController` (its per-Asset field range and control handles stay a per-Asset spec, `MAG-1`). `Laser` has since graduated to a catalog Family: an optical sample laser earned across 4-ID, LCLS-MFX, and the PSI SwissFEL endstations (Alvra, Bernina, Cristallina), one Family spanning pump-probe and alignment/reference lasers as a per-Asset purpose (SAMPLE-1). All names were cleared by the naming-r3 review during the catalog-graduation pass.
-
-| Loose Family | Presents (when graduated) | Status |
-| --- | --- | --- |
-| `TemperatureController` | Regulator | GRADUATED: catalog Family on the Diamond i22/i03/i11 rule-of-three; presents Regulator, requires Settable; 4-ID device details still to confirm (TEMP-1) |
-| `Transfocator` | Positioner | GRADUATED: catalog Family, a CRL focusing optic earned across eight deployments; 4-ID's CRL reuses it, lens spec still to confirm (OPT-2) |
-| `PositionMonitor` | Sensor | GRADUATED: catalog Family presenting Sensor, earned across the wide fleet that shares it; distinct from FluxMonitor by measuring beam position not flux; 4-ID position-vs-intensity split still to confirm (BPM-1) |
-| `PhaseRetarder` | Positioner | GRADUATED: catalog Family across 4-ID / P09 / P22; presents Positioner; 4-ID phase-retarder specs still to confirm (POL-1) |
-| `PolarizationAnalyzer` | Positioner | GRADUATED: catalog Family across 4-ID / i10 / ID32 / P09; presents Positioner, analyzer-crystal spec still to confirm (POL-2) |
-| `Magnet` | Regulator | GRADUATED: catalog Family on the 4-ID + i10-1 + ID32 rule-of-three; presents Regulator, the field a settable process variable; 4-ID device field ranges and control PVs still to confirm (MAG-1) |
-| `Laser` | (no Role) | GRADUATED: catalog Family, an optical sample laser earned across 4-ID / LCLS-MFX / Alvra / Bernina / Cristallina, one Family spanning pump-probe and alignment/reference lasers as a per-Asset purpose; the SAMPLE-1 model-versus-hazard question stays open |
-| `Diffractometer` | Positioner (Assembly) | LANDED as `Assembly(Diffractometer)` in the catalog, composing `Goniometer` (4-ID + 8-ID); 8-ID Fixture scenario landed, the 4-ID Fixture is the follow-on |
-
-## Deliberately not here yet
-
-These are the parts of 4-ID this cut leaves out on purpose. Each is a CORA scope decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](questions.md).
-
-- **The 4-ID Diffractometer Fixture.** The `Assembly(Diffractometer)` is now in the catalog (composing the `Goniometer` Family) and materialized by the 8-ID Fixture scenario (see the [8-ID model page](../8-id/model.md#the-diffractometer-assembly-landed)). 4-ID's two Huber diffractometers (the Eulerian cradle and the high-pressure diffractometer) are still modelled here as plain devices with their circle axis maps; decomposing them into a `Goniometer` Asset (the sample circles plus centring) plus any detector-arm `RotaryStage` circles and binding a 4-ID Fixture is the follow-on, gated on the circle-role confirmation (`DIFF-1`). The Assembly is the shared blueprint; the Fixture is per-beamline.
-
-- **The Raman station.** `4-ID-Raman` is out of this cut because its device config did not extract (a symlink that did not resolve in the source clone). Its devices and whether it is a fifth enclosure are `TOPO-2`; it is a world-fact gap, tracked on [Open questions](questions.md), not a scope decision.
-
-- **The 6-ID-B fork and the psic diffractometer.** A second instrument repo, `BCDA-APS/6idb-bits`, is a fork of `polar-bits`: its devices are almost entirely the same `4id*` PVs, with a grafted 6-ID-B endstation (a `psic` six-circle diffractometer at `6idb1:`, a CRL at `6idbSoft:TRANS:`). It is not an independent beamline, so it was used only as a second source to enrich this 4-ID descriptor (the `emag` magnet axes, the Euler diffractometer chi/phi circles), not to build a 6-ID-B deployment. The genuine 6-ID-B endstation (the `psic` diffractometer) is a future deployment, not modelled here. This fork also means the fleet recurrence report counts `polar-bits` and `6idb-bits` as two beamlines when they are one physical beamline, so 4-ID's own recurrence signal for `Magnet` / `TemperatureController` / `Diffractometer` rests on a single beamline (each of these has since graduated on a rule-of-three earned across other beamlines: `Magnet` at i10-1 and ID32).
-
-- **The diffraction / magnetism / polarization Methods.** Whether these techniques enter CORA's catalog (which has been all-imaging) is an owner decision. The Practices are registered pending and render unlinked; no Method is coined until the technique enters the pilot scope (`TECH-1`).
-
-- **Peripheral electronics.** The preamplifiers, lock-in amplifier, LabJacks, and high-pressure-cell controllers are present in the beamline config but not modelled as Assets in this cut (`SAMPLE-2`). They join if they prove to be beamline equipment CORA should track.
-
-- **Integration scenarios and vendor Models.** No `test_4id_*.py` registers 4-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real; hard-registering a first-cut, confirm-pending beamline would commit speculative structure. Both land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/4-id/notes.md b/docs/deployments/4-id/notes.md
new file mode 100644
index 00000000000..aecfb386bb9
--- /dev/null
+++ b/docs/deployments/4-id/notes.md
@@ -0,0 +1,172 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 4-ID is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 4-ID's techniques are diffraction, magnetism, and polarization, none of which exist in CORA's imaging-heritage catalog yet, so the Methods below render unlinked and are carried pending until one enters the pilot scope (`TECH-1`). The function view survives the eventual hardware and catalog choices, which is why it can be written before the Methods are coined.
+
+### Single-crystal diffraction
+
+The Huber diffractometers at 4-ID-G orient a single crystal and scan reciprocal space, measuring scattered intensity as a function of momentum transfer.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray diffraction | `diffraction` | reciprocal-space scans on the Eulerian or high-pressure diffractometer; Method not yet in catalog |
+| High-pressure diffraction | `diffraction` | the high-pressure diffractometer with a pressure cell; a Plan setting over the same Method |
+
+Both need the [diffractometers](sample.md) and the [detectors](detector.md). Whether the reciprocal-space coordination (hklpy2) is modelled as a `PseudoAxis` inside an `Assembly(Diffractometer)` is the design recorded on [Model](#deliberately-not-here-yet); the world-fact half (the circle geometry) is `DIFF-1`.
+
+### Magnetic and resonant scattering
+
+4-ID's signature: resonant scattering across an absorption edge, in an applied magnetic field and at low temperature, to probe magnetic and electronic order.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant magnetic scattering | `magnetic_scattering` | scattering in field (2 T or high-field magnet) at low temperature; Method not yet in catalog |
+| Resonant elastic scattering | `resonant_scattering` | energy-resonant scattering across an edge; Method not yet in catalog |
+
+These need the [sample environment](sample.md) (magnet plus temperature controller) and the monochromator's energy control.
+
+### Polarization analysis
+
+The phase retarders set the incident X-ray polarization, and the polarization analyzer resolves the scattered-beam polarization; together they enable dichroism and polarization-dependent scattering.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray magnetic circular dichroism | `xmcd` | circular polarization set by the phase retarders; Method not yet in catalog |
+| Polarization-analyzed scattering | `magnetic_scattering` | the analyzer crystal resolves the scattered polarization; a Plan setting over the scattering Method |
+
+These need the [phase retarders and polarization analyzer](sample.md).
+
+### Not modelled yet
+
+The Raman station's techniques are out of this cut (`TOPO-2`). The concrete acquisition recipes (scan sequences, energies, fields, exposures) are not written yet; they join as the deployment approaches the point where CORA drives 4-ID. Whether diffraction and the polarization / magnetism Methods enter CORA's catalog at all is an owner-scope decision recorded on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at 4-ID, and the trust shape that will gate it. First cut.*
+
+Governance at 4-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+4-ID is not yet driven by CORA, so this shape is not yet instantiated. The 4-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation; CORA does not invent a 4-ID operator roster (a placeholder `4-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them rather than restating them. 4-ID adds hazard classes beyond the imaging envelope, superconducting magnets with high stored energy and cryogens, a pump-probe laser, and pressurized high-pressure cells, that an experiment Clearance would carry; those land with the instruments that bring them as the sample environment firms (`MAG-1`, `SAMPLE-1`).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 4-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 4-ID content lives, the diffraction / magnetism / polarization deployment whose loose families graduated across the fleet, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 4-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Loose-Family graduation
+
+4-ID introduced eight device classes CORA had not earned into the catalog. Graduation needs two or more independent CORA deployments AND a settled abstraction. The 8-ID XPCS deployment adds the second independent beamline for `TemperatureController`, `Transfocator`, and `PositionMonitor`. `TemperatureController` has since graduated to a catalog Family: the parallel Diamond i22/i03/i11 rule-of-three settled the settable-actuator abstraction, and it presents the new `Regulator` Role. `Transfocator` has likewise graduated to a catalog Family: a CRL focusing optic earned across eight deployments, so 4-ID's CRL now reuses it like any catalog Family (its lens material and lenslet count stay a per-Asset spec, `OPT-2`). `PhaseRetarder` has likewise graduated to a catalog Family: a phase-retarder optic earned across 4-ID (three diamond phase-retarder stages), PETRA III P09 (shared phase-retarder circles), and PETRA III P22 (a third consumer via the shared P09 optics), and it presents the `Positioner` Role. `PolarizationAnalyzer` has likewise graduated to a catalog Family: a polarization-analysis positioner earned across 4-ID / i10 / ID32 / P09, so 4-ID's analyzer now reuses it like any catalog Family (its analyzer-crystal spec stays a per-Asset detail, `POL-2`). `PositionMonitor` has likewise graduated to a catalog Family: its own Sensor Family earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines), the cross-facility review resolving the fold-vs-promote question in favour of promote (distinct from the graduated `FluxMonitor` by measuring beam position and centroid, not flux; the per-Asset position-versus-intensity split stays open, `BPM-1`). The `Diffractometer` is the one that landed: as the `Assembly(Diffractometer)` blueprint (4-ID + 8-ID), which composes the catalog `Goniometer` Family, with an 8-ID Fixture scenario. `Magnet` has since graduated to a catalog Family: 4-ID was its first consumer, and the Diamond i10-1 and ESRF ID32 magnets brought it to a rule-of-three, settling the settable-field abstraction, so it presents the `Regulator` Role like `TemperatureController` (its per-Asset field range and control handles stay a per-Asset spec, `MAG-1`). `Laser` has since graduated to a catalog Family: an optical sample laser earned across 4-ID, LCLS-MFX, and the PSI SwissFEL endstations (Alvra, Bernina, Cristallina), one Family spanning pump-probe and alignment/reference lasers as a per-Asset purpose (SAMPLE-1). All names were cleared by the naming-r3 review during the catalog-graduation pass.
+
+| Loose Family | Presents (when graduated) | Status |
+| --- | --- | --- |
+| `TemperatureController` | Regulator | GRADUATED: catalog Family on the Diamond i22/i03/i11 rule-of-three; presents Regulator, requires Settable; 4-ID device details still to confirm (TEMP-1) |
+| `Transfocator` | Positioner | GRADUATED: catalog Family, a CRL focusing optic earned across eight deployments; 4-ID's CRL reuses it, lens spec still to confirm (OPT-2) |
+| `PositionMonitor` | Sensor | GRADUATED: catalog Family presenting Sensor, earned across the wide fleet that shares it; distinct from FluxMonitor by measuring beam position not flux; 4-ID position-vs-intensity split still to confirm (BPM-1) |
+| `PhaseRetarder` | Positioner | GRADUATED: catalog Family across 4-ID / P09 / P22; presents Positioner; 4-ID phase-retarder specs still to confirm (POL-1) |
+| `PolarizationAnalyzer` | Positioner | GRADUATED: catalog Family across 4-ID / i10 / ID32 / P09; presents Positioner, analyzer-crystal spec still to confirm (POL-2) |
+| `Magnet` | Regulator | GRADUATED: catalog Family on the 4-ID + i10-1 + ID32 rule-of-three; presents Regulator, the field a settable process variable; 4-ID device field ranges and control PVs still to confirm (MAG-1) |
+| `Laser` | (no Role) | GRADUATED: catalog Family, an optical sample laser earned across 4-ID / LCLS-MFX / Alvra / Bernina / Cristallina, one Family spanning pump-probe and alignment/reference lasers as a per-Asset purpose; the SAMPLE-1 model-versus-hazard question stays open |
+| `Diffractometer` | Positioner (Assembly) | LANDED as `Assembly(Diffractometer)` in the catalog, composing `Goniometer` (4-ID + 8-ID); 8-ID Fixture scenario landed, the 4-ID Fixture is the follow-on |
+
+### Deliberately not here yet
+
+These are the parts of 4-ID this cut leaves out on purpose. Each is a CORA scope decision, not a fact the beamline team needs to supply, so it lives here rather than on [Open questions](#open-questions).
+
+- **The 4-ID Diffractometer Fixture.** The `Assembly(Diffractometer)` is now in the catalog (composing the `Goniometer` Family) and materialized by the 8-ID Fixture scenario (see the [8-ID model page](../8-id/notes.md#the-diffractometer-assembly-landed)). 4-ID's two Huber diffractometers (the Eulerian cradle and the high-pressure diffractometer) are still modelled here as plain devices with their circle axis maps; decomposing them into a `Goniometer` Asset (the sample circles plus centring) plus any detector-arm `RotaryStage` circles and binding a 4-ID Fixture is the follow-on, gated on the circle-role confirmation (`DIFF-1`). The Assembly is the shared blueprint; the Fixture is per-beamline.
+
+- **The Raman station.** `4-ID-Raman` is out of this cut because its device config did not extract (a symlink that did not resolve in the source clone). Its devices and whether it is a fifth enclosure are `TOPO-2`; it is a world-fact gap, tracked on [Open questions](#open-questions), not a scope decision.
+
+- **The 6-ID-B fork and the psic diffractometer.** A second instrument repo, `BCDA-APS/6idb-bits`, is a fork of `polar-bits`: its devices are almost entirely the same `4id*` PVs, with a grafted 6-ID-B endstation (a `psic` six-circle diffractometer at `6idb1:`, a CRL at `6idbSoft:TRANS:`). It is not an independent beamline, so it was used only as a second source to enrich this 4-ID descriptor (the `emag` magnet axes, the Euler diffractometer chi/phi circles), not to build a 6-ID-B deployment. The genuine 6-ID-B endstation (the `psic` diffractometer) is a future deployment, not modelled here. This fork also means the fleet recurrence report counts `polar-bits` and `6idb-bits` as two beamlines when they are one physical beamline, so 4-ID's own recurrence signal for `Magnet` / `TemperatureController` / `Diffractometer` rests on a single beamline (each of these has since graduated on a rule-of-three earned across other beamlines: `Magnet` at i10-1 and ID32).
+
+- **The diffraction / magnetism / polarization Methods.** Whether these techniques enter CORA's catalog (which has been all-imaging) is an owner decision. The Practices are registered pending and render unlinked; no Method is coined until the technique enters the pilot scope (`TECH-1`).
+
+- **Peripheral electronics.** The preamplifiers, lock-in amplifier, LabJacks, and high-pressure-cell controllers are present in the beamline config but not modelled as Assets in this cut (`SAMPLE-2`). They join if they prove to be beamline equipment CORA should track.
+
+- **Integration scenarios and vendor Models.** No `test_4id_*.py` registers 4-ID Assets, and no vendor Models are bound. Scenario code is where Assets become real; hard-registering a first-cut, confirm-pending beamline would commit speculative structure. Both land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 4-ID team to confirm before the model can be trusted.*
+
+4-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/polar-bits](https://github.com/BCDA-APS/polar-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, but read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](#deliberately-not-here-yet) instead, including which loose Families graduate and the diffractometer Assembly). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | Do the three experiment stations (`4-ID-B`, `4-ID-G`, `4-ID-H`) run off one beam in series, or are any canted / branched off separate beams? Which optics are shared versus per-station? | One root Unit Asset `4-ID` with one optics spine feeding the three stations; KB mirrors and filters are per-station. | One-vs-many beam walks and the shared-vs-per-station optics split in the [descriptor](index.md). |
+| TOPO-2 | Blocks-go-live | The `4-ID-Raman` station: what instruments and devices does it carry? (Its `devices.yml` is a symlink that did not resolve in the source clone, so it did not extract.) | The Raman station exists but is out of this cut. | The Raman station devices and a fifth enclosure if warranted. |
+| TOPO-3 | Nice-to-have | Two PVs gave ambiguous station hints: `4iddMZ0:` (the SGZ Vortex detector) and `4idkepco:` (a Kepco magnet supply). What station does each sit in? | The Vortex is placed at `4-ID-G` and the Kepco magnet at `4-ID-G`, both confirm. No `4-ID-D` / `4-ID-K` enclosures are declared. | The station assignment for those two devices. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the polar-bits config current and correct for each device? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | What are the PSS search-and-secure permit signals for the four hutches (`4-ID-A/B/G/H`)? | Four hutches exist with permit signals to be named. | The Enclosure permit signals. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The undulator pair on S04ID: device types, periods, and gaps. | One `InsertionDevice` Asset for the pair (`PolarUndulatorPair`); periods unconfirmed. | The insertion-device specs. |
+| SRC-2 | Nice-to-have | Should the pair be one Asset or two (one per undulator)? | Modelled as one Asset. | One-vs-two source Assets. |
+| MONO-1 | Blocks-go-live | The VDCM monochromator: energy range, crystal set behind `crystal_select`, and per-axis roles. | One `Monochromator` Asset (4idVDCM) with a crystal-select axis; range unconfirmed. | The monochromator energy model. |
+| OPT-1 | Nice-to-have | The toroidal pre-focusing mirror and the HHL bendable mirror: coatings, stripes, and the bender / piezo axis roles. | Two `Mirror` Assets; the HHL axis map is taken from the config, coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Blocks-go-live | The transfocator (`4idPyCRL:CRL4ID:`): lens material, count, and which stations it focuses. | One `Transfocator` Asset (catalog Family); serves 4-ID-G and 4-ID-H. | The transfocator spec. |
+| OPT-3 | Nice-to-have | The per-station KB mirror (`bkb`/`gkb`/`hkb`) internal axis maps. | Three `Mirror` Assets; only the 4-ID-B KB carries a partial axis map. | The KB axis maps. |
+
+### Polarization
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| POL-1 | Blocks-go-live | The three phase retarders (`pr1`/`pr2`/`pr3`): diamond crystal type, thickness, and how they coordinate to set a polarization state. | Three `PhaseRetarder` Assets (catalog Family), each th/x/y, energy-tracking. | The phase-retarder specs and the polarization-state model. |
+| POL-2 | Blocks-go-live | The polarization analyzer (`pol`, th/y): analyzer crystal and the scattered-beam polarization it resolves. | One `PolarizationAnalyzer` Asset (catalog Family) at 4-ID-B. | The analyzer spec. |
+
+### Diffractometer
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The Huber Eulerian and high-pressure diffractometers: the real circle set (4-circle Eulerian? 6-circle?) and which motor is which circle (omega, chi, phi, two-theta). | Two diffractometers modelled as plain devices with the config's axis maps; the circle roles are partial. | The circle geometry, which decides the `Assembly(Diffractometer)` slot shape (see [Model](#deliberately-not-here-yet)). |
+| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: is hklpy2 driving an (h, k, l, energy) pseudo-axis, and over what geometry? | A reciprocal-space PseudoAxis is assumed for the Assembly design; not yet a device. | The pseudo-axis model. |
+
+### Sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MAG-1 | Blocks-go-live | The sample magnets: the two 2 T magnets (`bmag`/`emag`) and the high-field magnet (`magnet911`) field ranges and control PVs (the 2 T magnets had no control PV in the config), and the Kepco-driven `gmag`. | Four `Magnet` Assets (catalog Family, graduated); fields and several PVs unconfirmed. | The magnet specs and handles. |
+| TEMP-1 | Nice-to-have | The LakeShore 336 and 340 controllers: sensor channels and the sample stages they regulate. | Two `TemperatureController` Assets (catalog Family, presents `Regulator`) at 4-ID-G. | The temperature-controller model. |
+| SAMPLE-1 | Nice-to-have | The Ventus laser at 4-ID-H: is it a pump-probe source CORA should model as a device, or only carry as a Clearance hazard? | One `Laser` Asset (catalog Family); modelling-versus-hazard is open. | The laser model or hazard treatment. |
+| SAMPLE-2 | Nice-to-have | The preamplifiers, lock-in (`srs810`), and high-pressure-cell controllers (Pace `PC1`/`PC2`) are in the config but not modelled here. Which are beamline equipment versus user-brought? | Deferred as peripheral. | Whether these become Assets. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The Eiger area detector model, sensor, and frame rate. | One `Camera` Asset (`4idEiger:`); model unconfirmed. | The detector Model binding. |
+| DET-2 | Nice-to-have | The SGZ Vortex (`4iddMZ0:`): is it a fluorescence / energy-dispersive point detector, and what Family fits? | Bound to the catalog `PositionMonitor` Family as a placeholder; classification unconfirmed (see `TOPO-3`). | The Vortex classification and Family. |
+
+### Beam-position monitors and supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| BPM-1 | Nice-to-have | The XBPMs, Sydor electrometers, and TetrAMM: which are true beam-position monitors versus intensity (I0) normalizers? | All bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
+| SUP-1 | Nice-to-have | The cryogen and process-gas supplies the magnet and low-temperature environments draw on. | Liquid helium and liquid nitrogen carried pending in the descriptor. | The Supply records. |
diff --git a/docs/deployments/4-id/questions.md b/docs/deployments/4-id/questions.md
deleted file mode 100644
index 71f5a8dd35d..00000000000
--- a/docs/deployments/4-id/questions.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Open questions
-
-*What CORA needs the 4-ID team to confirm before the model can be trusted.*
-
-4-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/polar-bits](https://github.com/BCDA-APS/polar-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, but read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are recorded on [Model](model.md#deliberately-not-here-yet) instead, including which loose Families graduate and the diffractometer Assembly). It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed, with the reason in the commit. Priorities are `Blocks-build` (the answer changes the structure of the model), `Blocks-go-live` (a placeholder is fine for the description, but the real value is needed before CORA observes or drives the hardware), and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | Do the three experiment stations (`4-ID-B`, `4-ID-G`, `4-ID-H`) run off one beam in series, or are any canted / branched off separate beams? Which optics are shared versus per-station? | One root Unit Asset `4-ID` with one optics spine feeding the three stations; KB mirrors and filters are per-station. | One-vs-many beam walks and the shared-vs-per-station optics split in the [descriptor](index.md). |
-| TOPO-2 | Blocks-go-live | The `4-ID-Raman` station: what instruments and devices does it carry? (Its `devices.yml` is a symlink that did not resolve in the source clone, so it did not extract.) | The Raman station exists but is out of this cut. | The Raman station devices and a fifth enclosure if warranted. |
-| TOPO-3 | Nice-to-have | Two PVs gave ambiguous station hints: `4iddMZ0:` (the SGZ Vortex detector) and `4idkepco:` (a Kepco magnet supply). What station does each sit in? | The Vortex is placed at `4-ID-G` and the Kepco magnet at `4-ID-G`, both confirm. No `4-ID-D` / `4-ID-K` enclosures are declared. | The station assignment for those two devices. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the polar-bits config current and correct for each device? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | What are the PSS search-and-secure permit signals for the four hutches (`4-ID-A/B/G/H`)? | Four hutches exist with permit signals to be named. | The Enclosure permit signals. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The undulator pair on S04ID: device types, periods, and gaps. | One `InsertionDevice` Asset for the pair (`PolarUndulatorPair`); periods unconfirmed. | The insertion-device specs. |
-| SRC-2 | Nice-to-have | Should the pair be one Asset or two (one per undulator)? | Modelled as one Asset. | One-vs-two source Assets. |
-| MONO-1 | Blocks-go-live | The VDCM monochromator: energy range, crystal set behind `crystal_select`, and per-axis roles. | One `Monochromator` Asset (4idVDCM) with a crystal-select axis; range unconfirmed. | The monochromator energy model. |
-| OPT-1 | Nice-to-have | The toroidal pre-focusing mirror and the HHL bendable mirror: coatings, stripes, and the bender / piezo axis roles. | Two `Mirror` Assets; the HHL axis map is taken from the config, coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Blocks-go-live | The transfocator (`4idPyCRL:CRL4ID:`): lens material, count, and which stations it focuses. | One `Transfocator` Asset (catalog Family); serves 4-ID-G and 4-ID-H. | The transfocator spec. |
-| OPT-3 | Nice-to-have | The per-station KB mirror (`bkb`/`gkb`/`hkb`) internal axis maps. | Three `Mirror` Assets; only the 4-ID-B KB carries a partial axis map. | The KB axis maps. |
-
-## Polarization
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| POL-1 | Blocks-go-live | The three phase retarders (`pr1`/`pr2`/`pr3`): diamond crystal type, thickness, and how they coordinate to set a polarization state. | Three `PhaseRetarder` Assets (catalog Family), each th/x/y, energy-tracking. | The phase-retarder specs and the polarization-state model. |
-| POL-2 | Blocks-go-live | The polarization analyzer (`pol`, th/y): analyzer crystal and the scattered-beam polarization it resolves. | One `PolarizationAnalyzer` Asset (catalog Family) at 4-ID-B. | The analyzer spec. |
-
-## Diffractometer
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The Huber Eulerian and high-pressure diffractometers: the real circle set (4-circle Eulerian? 6-circle?) and which motor is which circle (omega, chi, phi, two-theta). | Two diffractometers modelled as plain devices with the config's axis maps; the circle roles are partial. | The circle geometry, which decides the `Assembly(Diffractometer)` slot shape (see [Model](model.md#deliberately-not-here-yet)). |
-| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: is hklpy2 driving an (h, k, l, energy) pseudo-axis, and over what geometry? | A reciprocal-space PseudoAxis is assumed for the Assembly design; not yet a device. | The pseudo-axis model. |
-
-## Sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MAG-1 | Blocks-go-live | The sample magnets: the two 2 T magnets (`bmag`/`emag`) and the high-field magnet (`magnet911`) field ranges and control PVs (the 2 T magnets had no control PV in the config), and the Kepco-driven `gmag`. | Four `Magnet` Assets (catalog Family, graduated); fields and several PVs unconfirmed. | The magnet specs and handles. |
-| TEMP-1 | Nice-to-have | The LakeShore 336 and 340 controllers: sensor channels and the sample stages they regulate. | Two `TemperatureController` Assets (catalog Family, presents `Regulator`) at 4-ID-G. | The temperature-controller model. |
-| SAMPLE-1 | Nice-to-have | The Ventus laser at 4-ID-H: is it a pump-probe source CORA should model as a device, or only carry as a Clearance hazard? | One `Laser` Asset (catalog Family); modelling-versus-hazard is open. | The laser model or hazard treatment. |
-| SAMPLE-2 | Nice-to-have | The preamplifiers, lock-in (`srs810`), and high-pressure-cell controllers (Pace `PC1`/`PC2`) are in the config but not modelled here. Which are beamline equipment versus user-brought? | Deferred as peripheral. | Whether these become Assets. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The Eiger area detector model, sensor, and frame rate. | One `Camera` Asset (`4idEiger:`); model unconfirmed. | The detector Model binding. |
-| DET-2 | Nice-to-have | The SGZ Vortex (`4iddMZ0:`): is it a fluorescence / energy-dispersive point detector, and what Family fits? | Bound to the catalog `PositionMonitor` Family as a placeholder; classification unconfirmed (see `TOPO-3`). | The Vortex classification and Family. |
-
-## Beam-position monitors and supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| BPM-1 | Nice-to-have | The XBPMs, Sydor electrometers, and TetrAMM: which are true beam-position monitors versus intensity (I0) normalizers? | All bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
-| SUP-1 | Nice-to-have | The cryogen and process-gas supplies the magnet and low-temperature environments draw on. | Liquid helium and liquid nitrogen carried pending in the descriptor. | The Supply records. |
diff --git a/docs/deployments/4-id/techniques.md b/docs/deployments/4-id/techniques.md
deleted file mode 100644
index 8535d0f5597..00000000000
--- a/docs/deployments/4-id/techniques.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Techniques
-
-*What the modelled part of 4-ID is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 4-ID's techniques are diffraction, magnetism, and polarization, none of which exist in CORA's imaging-heritage catalog yet, so the Methods below render unlinked and are carried pending until one enters the pilot scope (`TECH-1`). The function view survives the eventual hardware and catalog choices, which is why it can be written before the Methods are coined.
-
-## Single-crystal diffraction
-
-The Huber diffractometers at 4-ID-G orient a single crystal and scan reciprocal space, measuring scattered intensity as a function of momentum transfer.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray diffraction | `diffraction` | reciprocal-space scans on the Eulerian or high-pressure diffractometer; Method not yet in catalog |
-| High-pressure diffraction | `diffraction` | the high-pressure diffractometer with a pressure cell; a Plan setting over the same Method |
-
-Both need the [diffractometers](sample.md) and the [detectors](detector.md). Whether the reciprocal-space coordination (hklpy2) is modelled as a `PseudoAxis` inside an `Assembly(Diffractometer)` is the design recorded on [Model](model.md#deliberately-not-here-yet); the world-fact half (the circle geometry) is `DIFF-1`.
-
-## Magnetic and resonant scattering
-
-4-ID's signature: resonant scattering across an absorption edge, in an applied magnetic field and at low temperature, to probe magnetic and electronic order.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant magnetic scattering | `magnetic_scattering` | scattering in field (2 T or high-field magnet) at low temperature; Method not yet in catalog |
-| Resonant elastic scattering | `resonant_scattering` | energy-resonant scattering across an edge; Method not yet in catalog |
-
-These need the [sample environment](sample.md) (magnet plus temperature controller) and the monochromator's energy control.
-
-## Polarization analysis
-
-The phase retarders set the incident X-ray polarization, and the polarization analyzer resolves the scattered-beam polarization; together they enable dichroism and polarization-dependent scattering.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray magnetic circular dichroism | `xmcd` | circular polarization set by the phase retarders; Method not yet in catalog |
-| Polarization-analyzed scattering | `magnetic_scattering` | the analyzer crystal resolves the scattered polarization; a Plan setting over the scattering Method |
-
-These need the [phase retarders and polarization analyzer](sample.md).
-
-## Not modelled yet
-
-The Raman station's techniques are out of this cut (`TOPO-2`). The concrete acquisition recipes (scan sequences, energies, fields, exposures) are not written yet; they join as the deployment approaches the point where CORA drives 4-ID. Whether diffraction and the polarization / magnetism Methods enter CORA's catalog at all is an owner-scope decision recorded on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/7-bm/governance.md b/docs/deployments/7-bm/governance.md
deleted file mode 100644
index 952331577b9..00000000000
--- a/docs/deployments/7-bm/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at 7-BM, and the trust shape that will gate it. Design-phase.*
-
-Governance at 7-BM follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-Because 7-BM runs at the same APS Site as 2-BM, it reuses the APS facility envelope rather than creating a new one: the APS operator pool, the experiment-safety review structure, and the seeded agents are facility-wide and are inherited unchanged. This is the opposite of the TomoWISE deployment, which had to create a new MAX IV Site. 7-BM adds only its own beamline-bound principals (the 7-BM beamline scientists and operators), carried pending on the [APS site page](../aps/index.md#safety-and-governance).
-
-7-BM is pre-build for CORA, so the concrete trust shape is not yet instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the APS Site, not on the beamline, and the beamline links up to them rather than restating them.
-
-One governance question is sharper at 7-BM than at 2-BM: the flow and combustion hazard surface (flammable gas, fuel vapor, oxygen deficiency, a radioactive check source for detector calibration) is broader than the radiation-only hazard profile of micro-CT. CORA's current position is that this is handled by ESAF clearances plus operator Cautions plus the hutch alarms, not by a separate hazard aggregate. Whether combustion or flammable-gas work needs a review, approve, and expire workflow distinct from the standard ESAF clearance is the single question that would change that (HAZ-1).
-
-The concrete Zone, Conduit, and Policy instances, and the beamline operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/7-bm/model.md b/docs/deployments/7-bm/model.md
deleted file mode 100644
index c345bb7f906..00000000000
--- a/docs/deployments/7-bm/model.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 7-BM content lives, a flow / combustion deployment whose FlowController grounds the continuous-regulation gap, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 7-BM |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What is deliberately not here yet
-
-- **New catalog Families and Methods.** 7-BM does not earn new catalog kinds in this scaffold. The genuinely-new device anatomies are carried as loose families with a tracking question; the new techniques are carried as pending Methods. They are added to the catalog only when a confirmed device or technique and the naming review settle them. This follows the "pilots earn the abstractions" rule: a beamline that is not yet onboarded does not get to mint cross-facility vocabulary.
-- **Integration scenarios.** No `test_7bm_*.py` registers 7-BM Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, partly-documented beamline would commit speculative structure. It lands when the techniques enter the pilot scope and the team approves.
-- **Vendor Models.** No catalog Model is bound. The vendors named in the docs (Photron, Sierra, Kaeser, IDT, Rigaku) are recorded in the descriptor notes, not bound, because no part is procured into the catalog.
-- **Operations and experiment views.** A runbook and live experiment view for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
-- **Detector assemblies.** The tomography detector is left as plain devices (scintillator plus camera). It could later compose the cross-facility `Microscope` Assembly that 2-BM and TomoWISE use, once a scenario registers it.
-
-- **The continuous-regulation runtime (the FlowController setpoint program).** The `FlowController` presents the earned `Regulator` Role and CORA commands its setpoint (a one-shot `SetpointStep`), but a continuous setpoint PROGRAM, a hold or ramp held during a Run while the scan acquires, has no runtime today: the Conductor walks a finite step list, and `SetpointStep` / `ControlPort.write` are one-shot. The regulation loop itself stays device/IOC-owned (the Sierra controller runs it); CORA's gap is expressing and observing the program, not hosting the loop. This is the deepest cross-facility architectural gap the audit named; 7-BM (flow/combustion) is its grounding case alongside i11 / XPD thermal. It is the continuous-regulation axis, deferred to a Stage-0 research note and a later gate-reviewed build, exactly as the event-stream axis was for XFEL/XPCS acquisition (FLOW-1).
diff --git a/docs/deployments/7-bm/notes.md b/docs/deployments/7-bm/notes.md
new file mode 100644
index 00000000000..b18a71722cf
--- /dev/null
+++ b/docs/deployments/7-bm/notes.md
@@ -0,0 +1,117 @@
+# Notes
+
+## Techniques
+
+*What 7-BM is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 7-BM is multi-technique, and which techniques enter the CORA pilot scope is itself an open question (TECH-1). The function view below survives the eventual equipment choices, which is why it can be written before the hardware is confirmed.
+
+The beam mode is selected per technique over one set of optics, not a fixed source property (BEAM-1):
+
+| Technique | Beam mode | Detector modality | Status in CORA |
+| --- | --- | --- | --- |
+| Tomography | monochromatic | 2D area camera (scintillator-coupled) | reuses the 2-BM Methods unchanged |
+| High-speed imaging | white | high-speed movie camera, chopper-gated | new acquisition Method, pending |
+| Radiography | focused (~8 keV) | point photodiode, digitizer-read | new acquisition Method, pending |
+| Energy-dispersive diffraction | white | germanium energy-dispersive detector | new Method, pending |
+| Confocal fluorescence | (docs stub) | spectroscopic detector | deferred until confirmed (the docs page is empty) |
+
+A few points of intent shape the model:
+
+- **Tomography is pure reuse.** 7-BM runs the same tomoScan engine as 2-BM (single, vertical, horizontal, mosaic scans), so its tomography binds the existing `tomography` and `mosaic_tomography` Methods and the 2-BM detector shape. No new tomography vocabulary is earned.
+- **The new techniques are new acquisition Methods, not new Capabilities.** High-speed movie bursts, point-detector radiography traces, and the energy-to-q EDD measurement are new `Method` rows under the existing `acquisition` and `characterization` Capabilities. They are deployment vocabulary; the device Roles (Detector, Sensor) already exist. They are carried pending until the technique enters scope and its data unit is confirmed (HSI-1, RAD-1, DET-1).
+- **Beam mode is an operation mode over one beamline.** Inserting or bypassing the monochromator, filtering the white beam, or focusing with the KB pair picks the spectrum for a technique; it is a mode over one set of optics, not separate beamlines (BEAM-1).
+- **Techniques can combine.** The docs note energy-dispersive diffraction running simultaneously with tomography through shared optics; CORA models that as coordinated Runs under one Campaign, not a new combined technique (TECH-1).
+
+The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the techniques enter the pilot scope. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who will act at 7-BM, and the trust shape that will gate it. Design-phase.*
+
+Governance at 7-BM follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+Because 7-BM runs at the same APS Site as 2-BM, it reuses the APS facility envelope rather than creating a new one: the APS operator pool, the experiment-safety review structure, and the seeded agents are facility-wide and are inherited unchanged. This is the opposite of the TomoWISE deployment, which had to create a new MAX IV Site. 7-BM adds only its own beamline-bound principals (the 7-BM beamline scientists and operators), carried pending on the [APS site page](../aps/index.md#safety-and-governance).
+
+7-BM is pre-build for CORA, so the concrete trust shape is not yet instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the APS Site, not on the beamline, and the beamline links up to them rather than restating them.
+
+One governance question is sharper at 7-BM than at 2-BM: the flow and combustion hazard surface (flammable gas, fuel vapor, oxygen deficiency, a radioactive check source for detector calibration) is broader than the radiation-only hazard profile of micro-CT. CORA's current position is that this is handled by ESAF clearances plus operator Cautions plus the hutch alarms, not by a separate hazard aggregate. Whether combustion or flammable-gas work needs a review, approve, and expire workflow distinct from the standard ESAF clearance is the single question that would change that (HAZ-1).
+
+The concrete Zone, Conduit, and Policy instances, and the beamline operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 7-BM content lives, a flow / combustion deployment whose FlowController grounds the continuous-regulation gap, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 7-BM |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What is deliberately not here yet
+
+- **New catalog Families and Methods.** 7-BM does not earn new catalog kinds in this scaffold. The genuinely-new device anatomies are carried as loose families with a tracking question; the new techniques are carried as pending Methods. They are added to the catalog only when a confirmed device or technique and the naming review settle them. This follows the "pilots earn the abstractions" rule: a beamline that is not yet onboarded does not get to mint cross-facility vocabulary.
+- **Integration scenarios.** No `test_7bm_*.py` registers 7-BM Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, partly-documented beamline would commit speculative structure. It lands when the techniques enter the pilot scope and the team approves.
+- **Vendor Models.** No catalog Model is bound. The vendors named in the docs (Photron, Sierra, Kaeser, IDT, Rigaku) are recorded in the descriptor notes, not bound, because no part is procured into the catalog.
+- **Operations and experiment views.** A runbook and live experiment view for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
+- **Detector assemblies.** The tomography detector is left as plain devices (scintillator plus camera). It could later compose the cross-facility `Microscope` Assembly that 2-BM and TomoWISE use, once a scenario registers it.
+
+- **The continuous-regulation runtime (the FlowController setpoint program).** The `FlowController` presents the earned `Regulator` Role and CORA commands its setpoint (a one-shot `SetpointStep`), but a continuous setpoint PROGRAM, a hold or ramp held during a Run while the scan acquires, has no runtime today: the Conductor walks a finite step list, and `SetpointStep` / `ControlPort.write` are one-shot. The regulation loop itself stays device/IOC-owned (the Sierra controller runs it); CORA's gap is expressing and observing the program, not hosting the loop. This is the deepest cross-facility architectural gap the audit named; 7-BM (flow/combustion) is its grounding case alongside i11 / XPD thermal. It is the continuous-regulation axis, deferred to a Stage-0 research note and a later gate-reviewed build, exactly as the event-stream axis was for XFEL/XPCS acquisition (FLOW-1).
+
+## Open questions
+
+*What CORA needs the 7-BM team to confirm before the model can be trusted.*
+
+7-BM is in the design phase and its operations documentation is partial, so this page is long by design: almost every value on the [device pages](index.md) is taken from the 7-BM docs or inferred, not confirmed with staff. Each row below is a fact the beamline team owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
+
+A note on what 7-BM tests that 2-BM did not: 7-BM is multi-technique (high-speed imaging, radiography, tomography, energy-dispersive diffraction, fluorescence), runs white, monochromatic, and focused beam, and carries a flow and combustion sample environment. The questions below concentrate on the new shapes; the tomography path itself reuses the 2-BM model unchanged.
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | What are the EPICS PV handles for each device? | Control handles are unassigned; CORA leaves the device handle empty. | Wiring each Asset to a real control handle. |
+| PSS-1 | Blocks-build | What are the PSS search-and-secure permit signals for the 7-BM-A and 7-BM-B hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
+| HAZ-1 | Blocks-go-live | Do combustion, flammable-gas, or radioactive-check-source experiments need a review / approve / expire workflow distinct from the standard APS ESAF clearance? | The flow and combustion hazard surface is handled by ESAF clearances plus operator Cautions plus alarms, not a separate hazard aggregate. | Whether a Hazard lifecycle is earned beyond Clearance and Caution. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What is the 7-BM source after APS-U? The docs do not state it. | A bending-magnet source, carried `confirm`, mirroring the 2-BM source representation. | The `Source` device and beamline `source` field. |
+| BEAM-1 | Blocks-build | Which beam mode (white, monochromatic via the DMM, or focused via the KB mirrors) is canonical for each technique, and is the DMM split-stripe dual-energy mode used routinely? | Beam mode is a per-technique choice over one set of optics, not a fixed source property. | Binding each technique and Practice to a beam mode. |
+| OPT-1 | Nice-to-have | Which optics sit in the routine pilot path: the DMM, the multilayer mirror, the KB focusing pair, the polycapillary optics, and the channel-cut calibration crystals? | The DMM, multilayer mirror, and KB pair are modelled; the polycapillary and channel-cut crystals are deferred until a confirmed technique needs them. | Which optics are Assets and which stay deferred. |
+| CHOP-1 | Blocks-go-live | Is the rotary chopper permanently installed or fitted per time-resolved run, is its duty cycle a commanded setting or a manual mechanical re-index, and is the photoeye a tracked Sensor or inseparable floor wiring? | A loose `Chopper` family, pending whether it is a new catalog Family or an existing `Shutter` / `RotaryStage` plus settings. | The chopper modelling boundary. |
+
+### Techniques
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Which techniques are in scope for the CORA pilot: tomography, high-speed imaging, radiography, energy-dispersive diffraction, confocal fluorescence, and which combine (the docs note EDD running simultaneously with tomography)? | Tomography reuses the 2-BM Methods; the other techniques are design intent, carried pending on the [APS site Practices](../aps/index.md#the-techniques-adapted-here). | Which Methods and Practices the pilot binds. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Is the germanium energy-dispersive detector the same physical device as the fluorescence MCA, and is XRF a routine standalone technique or only an EDD energy-scale calibration step? | One `EnergyDispersiveSpectrometer` device presenting the Sensor Role, with fluorescence as a calibration step, not a separate detector. | One versus two Sensor-backed detector Assets, and whether a spectroscopy Method is earned. |
+| RAD-1 | Blocks-go-live | For time-resolved radiography, what is the point-detector chain (PIN diode plus ADQ14 digitizer or oscilloscope plus DataGrabber), and is one acquisition trace one Dataset? | A `Photodiode` device presenting the Sensor Role; the digitizer / scope / DataGrabber stay on the floor; the data unit is unconfirmed. | The radiography detector Family and the Run / Dataset shape. |
+| HSI-1 | Blocks-go-live | For high-speed imaging, is one chopper-gated movie burst one Run / Dataset (and the N-sequence set one Campaign), and how are top-up-blanked frames represented (invalid-marked, dropped, gap)? | One high-speed `Camera`; the acquisition unit and blanking semantics are unconfirmed. | The Run / Dataset / Acquisition shape for time-resolved capture. |
+
+### Sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| FLOW-1 | Nice-to-have | The command-vs-read half is settled: CORA COMMANDS the regulated flow / air setpoints (the graduated catalog `FlowController` Family presents the earned `Regulator` Role; a one-shot `SetpointStep`), not read-back-only. What remains open is the continuous-regulation runtime, a setpoint PROGRAM (a hold or ramp held during a Run, orthogonal to the scan step-list; the loop device/IOC-owned, CORA programs and observes), which no runtime expresses yet. | command-vs-read settled (commands); `FlowController` graduated (earned across i22 / 7-BM / LIX / XFP); the setpoint-program runtime is the continuous-regulation axis (see model.md + its Stage-0 research). | The continuous-regulation setpoint-program runtime primitive. |
+| ENV-1 | Blocks-go-live | Is there an installed combustion, spray, or fuel-injection device at 7-BM, or is combustion an intended use served by the air, gas, and vacuum infrastructure? | No combustion rig Asset is modelled; combustion is served by the facility Supplies and bound to the specimen Subject. | Whether a combustion-rig Asset and a fuel-vapor Caution are modelled. |
+
+### Controls and site
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TIMING-1 | Nice-to-have | Should the DG645 delay generators, softGlue FPGA, Machine Status Link P0 reference, and top-up inhibit be one `TimingController` device, or do any of them deserve separate modelling? | One `TimingController` carries the whole scheme, mirroring the 2-BM Timing device. | The timing-subsystem Asset shape. |
+| SECTOR-1 | Nice-to-have | Confirm 7-BM is in Sector 7, and whether it shares any governed resource (optics, safety system, compute) with another APS beamline. | 7-BM is a separate beamline in Sector 7 under the APS Site, sharing no governed resource with 2-BM. | The sector label and any cross-beamline shared-resource governance. |
diff --git a/docs/deployments/7-bm/questions.md b/docs/deployments/7-bm/questions.md
deleted file mode 100644
index 495dbc2bc89..00000000000
--- a/docs/deployments/7-bm/questions.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Open questions
-
-*What CORA needs the 7-BM team to confirm before the model can be trusted.*
-
-7-BM is in the design phase and its operations documentation is partial, so this page is long by design: almost every value on the [device pages](index.md) is taken from the 7-BM docs or inferred, not confirmed with staff. Each row below is a fact the beamline team owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
-
-A note on what 7-BM tests that 2-BM did not: 7-BM is multi-technique (high-speed imaging, radiography, tomography, energy-dispersive diffraction, fluorescence), runs white, monochromatic, and focused beam, and carries a flow and combustion sample environment. The questions below concentrate on the new shapes; the tomography path itself reuses the 2-BM model unchanged.
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | What are the EPICS PV handles for each device? | Control handles are unassigned; CORA leaves the device handle empty. | Wiring each Asset to a real control handle. |
-| PSS-1 | Blocks-build | What are the PSS search-and-secure permit signals for the 7-BM-A and 7-BM-B hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
-| HAZ-1 | Blocks-go-live | Do combustion, flammable-gas, or radioactive-check-source experiments need a review / approve / expire workflow distinct from the standard APS ESAF clearance? | The flow and combustion hazard surface is handled by ESAF clearances plus operator Cautions plus alarms, not a separate hazard aggregate. | Whether a Hazard lifecycle is earned beyond Clearance and Caution. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What is the 7-BM source after APS-U? The docs do not state it. | A bending-magnet source, carried `confirm`, mirroring the 2-BM source representation. | The `Source` device and beamline `source` field. |
-| BEAM-1 | Blocks-build | Which beam mode (white, monochromatic via the DMM, or focused via the KB mirrors) is canonical for each technique, and is the DMM split-stripe dual-energy mode used routinely? | Beam mode is a per-technique choice over one set of optics, not a fixed source property. | Binding each technique and Practice to a beam mode. |
-| OPT-1 | Nice-to-have | Which optics sit in the routine pilot path: the DMM, the multilayer mirror, the KB focusing pair, the polycapillary optics, and the channel-cut calibration crystals? | The DMM, multilayer mirror, and KB pair are modelled; the polycapillary and channel-cut crystals are deferred until a confirmed technique needs them. | Which optics are Assets and which stay deferred. |
-| CHOP-1 | Blocks-go-live | Is the rotary chopper permanently installed or fitted per time-resolved run, is its duty cycle a commanded setting or a manual mechanical re-index, and is the photoeye a tracked Sensor or inseparable floor wiring? | A loose `Chopper` family, pending whether it is a new catalog Family or an existing `Shutter` / `RotaryStage` plus settings. | The chopper modelling boundary. |
-
-## Techniques
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Which techniques are in scope for the CORA pilot: tomography, high-speed imaging, radiography, energy-dispersive diffraction, confocal fluorescence, and which combine (the docs note EDD running simultaneously with tomography)? | Tomography reuses the 2-BM Methods; the other techniques are design intent, carried pending on the [APS site Practices](../aps/index.md#the-techniques-adapted-here). | Which Methods and Practices the pilot binds. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Is the germanium energy-dispersive detector the same physical device as the fluorescence MCA, and is XRF a routine standalone technique or only an EDD energy-scale calibration step? | One `EnergyDispersiveSpectrometer` device presenting the Sensor Role, with fluorescence as a calibration step, not a separate detector. | One versus two Sensor-backed detector Assets, and whether a spectroscopy Method is earned. |
-| RAD-1 | Blocks-go-live | For time-resolved radiography, what is the point-detector chain (PIN diode plus ADQ14 digitizer or oscilloscope plus DataGrabber), and is one acquisition trace one Dataset? | A `Photodiode` device presenting the Sensor Role; the digitizer / scope / DataGrabber stay on the floor; the data unit is unconfirmed. | The radiography detector Family and the Run / Dataset shape. |
-| HSI-1 | Blocks-go-live | For high-speed imaging, is one chopper-gated movie burst one Run / Dataset (and the N-sequence set one Campaign), and how are top-up-blanked frames represented (invalid-marked, dropped, gap)? | One high-speed `Camera`; the acquisition unit and blanking semantics are unconfirmed. | The Run / Dataset / Acquisition shape for time-resolved capture. |
-
-## Sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| FLOW-1 | Nice-to-have | The command-vs-read half is settled: CORA COMMANDS the regulated flow / air setpoints (the graduated catalog `FlowController` Family presents the earned `Regulator` Role; a one-shot `SetpointStep`), not read-back-only. What remains open is the continuous-regulation runtime, a setpoint PROGRAM (a hold or ramp held during a Run, orthogonal to the scan step-list; the loop device/IOC-owned, CORA programs and observes), which no runtime expresses yet. | command-vs-read settled (commands); `FlowController` graduated (earned across i22 / 7-BM / LIX / XFP); the setpoint-program runtime is the continuous-regulation axis (see model.md + its Stage-0 research). | The continuous-regulation setpoint-program runtime primitive. |
-| ENV-1 | Blocks-go-live | Is there an installed combustion, spray, or fuel-injection device at 7-BM, or is combustion an intended use served by the air, gas, and vacuum infrastructure? | No combustion rig Asset is modelled; combustion is served by the facility Supplies and bound to the specimen Subject. | Whether a combustion-rig Asset and a fuel-vapor Caution are modelled. |
-
-## Controls and site
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TIMING-1 | Nice-to-have | Should the DG645 delay generators, softGlue FPGA, Machine Status Link P0 reference, and top-up inhibit be one `TimingController` device, or do any of them deserve separate modelling? | One `TimingController` carries the whole scheme, mirroring the 2-BM Timing device. | The timing-subsystem Asset shape. |
-| SECTOR-1 | Nice-to-have | Confirm 7-BM is in Sector 7, and whether it shares any governed resource (optics, safety system, compute) with another APS beamline. | 7-BM is a separate beamline in Sector 7 under the APS Site, sharing no governed resource with 2-BM. | The sector label and any cross-beamline shared-resource governance. |
diff --git a/docs/deployments/7-bm/techniques.md b/docs/deployments/7-bm/techniques.md
deleted file mode 100644
index 70a6497fbbb..00000000000
--- a/docs/deployments/7-bm/techniques.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Techniques
-
-*What 7-BM is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 7-BM is multi-technique, and which techniques enter the CORA pilot scope is itself an open question (TECH-1). The function view below survives the eventual equipment choices, which is why it can be written before the hardware is confirmed.
-
-The beam mode is selected per technique over one set of optics, not a fixed source property (BEAM-1):
-
-| Technique | Beam mode | Detector modality | Status in CORA |
-| --- | --- | --- | --- |
-| Tomography | monochromatic | 2D area camera (scintillator-coupled) | reuses the 2-BM Methods unchanged |
-| High-speed imaging | white | high-speed movie camera, chopper-gated | new acquisition Method, pending |
-| Radiography | focused (~8 keV) | point photodiode, digitizer-read | new acquisition Method, pending |
-| Energy-dispersive diffraction | white | germanium energy-dispersive detector | new Method, pending |
-| Confocal fluorescence | (docs stub) | spectroscopic detector | deferred until confirmed (the docs page is empty) |
-
-A few points of intent shape the model:
-
-- **Tomography is pure reuse.** 7-BM runs the same tomoScan engine as 2-BM (single, vertical, horizontal, mosaic scans), so its tomography binds the existing `tomography` and `mosaic_tomography` Methods and the 2-BM detector shape. No new tomography vocabulary is earned.
-- **The new techniques are new acquisition Methods, not new Capabilities.** High-speed movie bursts, point-detector radiography traces, and the energy-to-q EDD measurement are new `Method` rows under the existing `acquisition` and `characterization` Capabilities. They are deployment vocabulary; the device Roles (Detector, Sensor) already exist. They are carried pending until the technique enters scope and its data unit is confirmed (HSI-1, RAD-1, DET-1).
-- **Beam mode is an operation mode over one beamline.** Inserting or bypassing the monochromator, filtering the white beam, or focusing with the KB pair picks the spectrum for a technique; it is a mode over one set of optics, not separate beamlines (BEAM-1).
-- **Techniques can combine.** The docs note energy-dispersive diffraction running simultaneously with tomography through shared optics; CORA models that as coordinated Runs under one Campaign, not a new combined technique (TECH-1).
-
-The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the techniques enter the pilot scope. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/8-3-2/governance.md b/docs/deployments/8-3-2/governance.md
deleted file mode 100644
index 2c681eca9cf..00000000000
--- a/docs/deployments/8-3-2/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 8.3.2, and the trust shape that will gate it. First cut.*
-
-Governance at 8.3.2 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ALS Site](../als/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-8.3.2 is CORA's first ALS deployment, so ALS is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ALS Site](../als/index.md#safety-and-governance), shared across the facility's beamlines, until ALS staff confirm them (`GOV-1`). 8.3.2 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives 8.3.2, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. ALS publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ALS Site](../als/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 8.3.2, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/8-3-2/model.md b/docs/deployments/8-3-2/model.md
deleted file mode 100644
index 7be176b4165..00000000000
--- a/docs/deployments/8-3-2/model.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 8.3.2 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 8.3.2 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes 8.3.2 new
-
-8.3.2 is two things at the Site level and nothing new at the vocabulary level. It is CORA's **first ALS Site** (the Advanced Light Source at LBNL), a re-test of the Site and Federation kernel, and the **first BCS / LabVIEW** control plane CORA models. The ALS originated BCS (the Beamline Control System), so this is the controls house-style's home facility; every prior Site is EPICS (the APS and NSLS-II beamlines), Tango / Sardana (MAX IV, ALBA), or BLISS (the ESRF). Its science is hard X-ray micro-tomography on a Superbend source.
-
-It also introduces the **data-record descriptor mode**: the device structure is read from the DXchange / DXfile HDF5 metadata schema (verified against the `als-computing/scicat_beamline` ingester and the `als-computing/microct` reconstruction backend), while the live BCS control handles, which are not public, are carried pending. This sits between the FXI mode (real EPICS PVs read from a public profile collection) and the FAXTOR mode (no device manifest at all).
-
-## No new families (the imaging spine reuses the 2-BM / FXI / FAXTOR precedent)
-
-8.3.2 coins no new Family. The Superbend binds the catalog `InsertionDevice` (recorded as a Supply, the 2-BM bending-magnet precedent); the energy optic binds `Monochromator`; the slits bind `Slit` and the attenuator binds `Filter`; the sample stack binds `RotaryStage` and `LinearStage`; the detector binds `Scintillator`, `Objective`, and `Camera`, with the detector motion binding `LinearStage`; the machine state binds the loose `StorageRing`. Nothing in the catalog changes.
-
-## The BCS control plane and the data orchestration
-
-8.3.2 is the fleet's first BCS / LabVIEW controls house-style. Device IO is BCS, the ALS Beamline Control System, surfaced as scan files (Time Scan, Single Motor Scan, Trajectory Scan) whose headers carry the device-state data record ([`als-computing/als.bcs`](https://github.com/als-computing/als.bcs)). An emerging acquisition layer wraps BCS scans as bluesky ophyd `fly` devices through the LabVIEW BCS API ([`als-computing/bcs-api`](https://github.com/als-computing/bcs-api)). ALS publishes no per-beamline BCS channel manifest, so CORA does not bind the BCS handles here; when bound they would be modelled as opaque edge handles over the `ControlPort`, the way the MX3 and ID32 heterogeneous-control precedents do (`CTRL-1`). The continuous-rotation tomography acquisition runs as a BCS Trajectory Scan; that orchestration is the seam CORA's edge replaces, conducting over BCS rather than replacing it.
-
-The downstream data movement and reconstruction is a separate, well-developed layer that CORA observes and subsumes at the debrief layer, not data it owns: [`als-computing/splash_flows`](https://github.com/als-computing/splash_flows) moves data with Prefect + Globus to NERSC and ALCF, catalogues it in SciCat, and runs tomography reconstruction (TomoPy / ASTRA / SVMBIR) via [`als-computing/microct`](https://github.com/als-computing/microct). CORA keeps its own data-of-record (the PG event store); the SciCat catalogue is a source-of-truth contest named only at the seam, not a dependency.
-
-## Deliberately not here yet
-
-- **The BCS control handles (`CTRL-1`).** No public per-beamline BCS / LabVIEW channel manifest exists; the handles are carried pending, not invented.
-- **The detector model (`DET-1`).** The camera, scintillator, and objective are bound to `Camera`, `Scintillator`, and `Objective` but their models are unpublished (detector specs are per-dataset values in the data record), carried fully pending.
-- **The rotation-axis identity (`ROT-1`).** The data record's `sample_motor_stack` exposes `axis1pos` / `axis2pos` / `axis5pos`; which is the tomographic rotation is pending.
-- **The monochromator detail (`MONO-1`).** The mechanism (multilayer vs crystal), d-spacing, and the energy-axis wiring are carried confirm-pending.
-- **The slit and filter detail (`OPT-2`, `FILT-1`).** The full slit blade-axis map and the filter materials / thicknesses are carried confirm-pending.
-- **The detector-stack detail (`DET-2`).** The camera-distance / elevation / tilt axis models are named; their travels and the propagation-distance wiring are pending.
-- **The hutch grouping (`ENC-1`).** Modelled as a single experiment hutch pending the optics / experiment grouping.
-- **The simulated devices and full asset-tree scenarios.** No `test_8_3_2_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
-- **The ALS-U upgrade fate (`ALSU-1`).** Whether 8.3.2 goes dark, is rebuilt, or relocates in the ALS-U dark time (no sooner than October 2027) is a staff question, not modelled here.
diff --git a/docs/deployments/8-3-2/notes.md b/docs/deployments/8-3-2/notes.md
new file mode 100644
index 00000000000..8be104b6bd2
--- /dev/null
+++ b/docs/deployments/8-3-2/notes.md
@@ -0,0 +1,128 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 8.3.2 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../als/index.md#the-techniques-adapted-here) is how a facility adapts it. 8.3.2 is a hard X-ray micro-tomography beamline: its techniques reuse Methods CORA's catalog already carries.
+
+### Hard X-ray micro-tomography
+
+8.3.2 sets the X-ray energy with the monochromator (6,000-43,000 eV from the Superbend source), then rotates the sample on the tomographic rotary stage while the scintillator, objective, and camera record projections. It images non-destructively in 3D at ~1 micron resolution, with absorption and propagation-phase contrast (the detector stack's `camera_distance` sets the propagation distance).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Tomography | [`tomography`](../../catalog/methods.md) | absorption and propagation-phase micro-CT, the [rotary stage](sample.md) stepped against the [scintillator + camera](detector.md); reuses the catalog tomography Method (the 2-BM pilot) |
+| Continuous-rotation tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | fast fly-scan tomography, the [rotary stage](sample.md) in continuous rotation as the trigger master (`TRIG-1`); reuses the catalog continuous-rotation Method |
+
+Tomography needs the [incident energy](source.md) set by the [monochromator](source.md), the [rotary stage and sample positioning](sample.md), and the [scintillator + objective + camera](detector.md), with the [detector stack](detector.md) setting the sample-to-detector propagation distance.
+
+### A new Site on familiar vocabulary
+
+8.3.2 is the ALS's hard X-ray micro-CT beamline, and it ties into the tomography lineage CORA already models: the same imaging device anatomy as the 2-BM pilot, the NSLS-II FXI design, and the ALBA FAXTOR design (a bending-magnet or insertion-device source, an energy-setting optic, a rotary-stage endstation, and an indirect scintillator + camera detector). It reuses the `tomography` and `continuous_rotation_tomography` Methods directly; none forces a new device family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the fly-scan tomography sequences and their counting times, the flat / dark sequencing, the propagation-phase setups) are not written yet; they join as the deployment approaches the point where CORA drives 8.3.2. See [Open questions](#open-questions) for the world-facts to confirm first, in particular which sample-stack axis is the tomographic rotation (`ROT-1`) and the triggering scheme (`TRIG-1`).
+
+## Governance
+
+*Who will act at 8.3.2, and the trust shape that will gate it. First cut.*
+
+Governance at 8.3.2 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ALS Site](../als/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+8.3.2 is CORA's first ALS deployment, so ALS is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ALS Site](../als/index.md#safety-and-governance), shared across the facility's beamlines, until ALS staff confirm them (`GOV-1`). 8.3.2 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives 8.3.2, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. ALS publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ALS Site](../als/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 8.3.2, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 8.3.2 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 8.3.2 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes 8.3.2 new
+
+8.3.2 is two things at the Site level and nothing new at the vocabulary level. It is CORA's **first ALS Site** (the Advanced Light Source at LBNL), a re-test of the Site and Federation kernel, and the **first BCS / LabVIEW** control plane CORA models. The ALS originated BCS (the Beamline Control System), so this is the controls house-style's home facility; every prior Site is EPICS (the APS and NSLS-II beamlines), Tango / Sardana (MAX IV, ALBA), or BLISS (the ESRF). Its science is hard X-ray micro-tomography on a Superbend source.
+
+It also introduces the **data-record descriptor mode**: the device structure is read from the DXchange / DXfile HDF5 metadata schema (verified against the `als-computing/scicat_beamline` ingester and the `als-computing/microct` reconstruction backend), while the live BCS control handles, which are not public, are carried pending. This sits between the FXI mode (real EPICS PVs read from a public profile collection) and the FAXTOR mode (no device manifest at all).
+
+### No new families (the imaging spine reuses the 2-BM / FXI / FAXTOR precedent)
+
+8.3.2 coins no new Family. The Superbend binds the catalog `InsertionDevice` (recorded as a Supply, the 2-BM bending-magnet precedent); the energy optic binds `Monochromator`; the slits bind `Slit` and the attenuator binds `Filter`; the sample stack binds `RotaryStage` and `LinearStage`; the detector binds `Scintillator`, `Objective`, and `Camera`, with the detector motion binding `LinearStage`; the machine state binds the loose `StorageRing`. Nothing in the catalog changes.
+
+### The BCS control plane and the data orchestration
+
+8.3.2 is the fleet's first BCS / LabVIEW controls house-style. Device IO is BCS, the ALS Beamline Control System, surfaced as scan files (Time Scan, Single Motor Scan, Trajectory Scan) whose headers carry the device-state data record ([`als-computing/als.bcs`](https://github.com/als-computing/als.bcs)). An emerging acquisition layer wraps BCS scans as bluesky ophyd `fly` devices through the LabVIEW BCS API ([`als-computing/bcs-api`](https://github.com/als-computing/bcs-api)). ALS publishes no per-beamline BCS channel manifest, so CORA does not bind the BCS handles here; when bound they would be modelled as opaque edge handles over the `ControlPort`, the way the MX3 and ID32 heterogeneous-control precedents do (`CTRL-1`). The continuous-rotation tomography acquisition runs as a BCS Trajectory Scan; that orchestration is the seam CORA's edge replaces, conducting over BCS rather than replacing it.
+
+The downstream data movement and reconstruction is a separate, well-developed layer that CORA observes and subsumes at the debrief layer, not data it owns: [`als-computing/splash_flows`](https://github.com/als-computing/splash_flows) moves data with Prefect + Globus to NERSC and ALCF, catalogues it in SciCat, and runs tomography reconstruction (TomoPy / ASTRA / SVMBIR) via [`als-computing/microct`](https://github.com/als-computing/microct). CORA keeps its own data-of-record (the PG event store); the SciCat catalogue is a source-of-truth contest named only at the seam, not a dependency.
+
+### Deliberately not here yet
+
+- **The BCS control handles (`CTRL-1`).** No public per-beamline BCS / LabVIEW channel manifest exists; the handles are carried pending, not invented.
+- **The detector model (`DET-1`).** The camera, scintillator, and objective are bound to `Camera`, `Scintillator`, and `Objective` but their models are unpublished (detector specs are per-dataset values in the data record), carried fully pending.
+- **The rotation-axis identity (`ROT-1`).** The data record's `sample_motor_stack` exposes `axis1pos` / `axis2pos` / `axis5pos`; which is the tomographic rotation is pending.
+- **The monochromator detail (`MONO-1`).** The mechanism (multilayer vs crystal), d-spacing, and the energy-axis wiring are carried confirm-pending.
+- **The slit and filter detail (`OPT-2`, `FILT-1`).** The full slit blade-axis map and the filter materials / thicknesses are carried confirm-pending.
+- **The detector-stack detail (`DET-2`).** The camera-distance / elevation / tilt axis models are named; their travels and the propagation-distance wiring are pending.
+- **The hutch grouping (`ENC-1`).** Modelled as a single experiment hutch pending the optics / experiment grouping.
+- **The simulated devices and full asset-tree scenarios.** No `test_8_3_2_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+- **The ALS-U upgrade fate (`ALSU-1`).** Whether 8.3.2 goes dark, is rebuilt, or relocates in the ALS-U dark time (no sooner than October 2027) is a staff question, not modelled here.
+
+## Open questions
+
+*What CORA needs the 8.3.2 team to confirm before the model can be trusted.*
+
+8.3.2 was reverse-engineered from ALS's public facility pages ([als.lbl.gov/beamlines/8-3-2](https://als.lbl.gov/beamlines/8-3-2/), [microct.lbl.gov](https://microct.lbl.gov/)) and the public [als-computing](https://github.com/als-computing) GitHub org, not from a live connection. The device structure is read from the DXchange / DXfile HDF5 data record that the ALS tooling reads, but ALS runs BCS (a LabVIEW Beamline Control System, not EPICS) and publishes no per-beamline channel manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. This is CORA's first ALS Site and its first BCS / LabVIEW controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch, or a separate optics hutch feeding it? | A single `8-3-2-hutch`. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The Superbend field and critical energy. | A superconducting bending-magnet source, 6-43 keV; field pending. | The source Asset detail. |
+| ALSU-1 | Nice-to-have | The ALS-U upgrade fate of 8.3.2: does it go dark, get rebuilt, or relocate, and on what schedule? | Dark time no sooner than October 2027; 8.3.2's fate carried pending. | The deployment roadmap. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The ALS storage-ring state 8.3.2 reads (the `source_name` / `current` handles). | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The energy optic: the mechanism (multilayer vs crystal), d-spacing, and how the `energy`, `Z2`, `turret1` / `turret2`, and `TC2` / `TC3` channels relate. | An energy-setting `Monochromator`, 6-43 keV; `energy` the master axis. | The monochromator and energy modelling. |
+| OPT-2 | Nice-to-have | The slit blade-axis map (the `hslits_*` and `vslits_*` channels) and handles. | Horizontal + vertical slits bound to `Slit`. | The slit Asset detail. |
+| FILT-1 | Nice-to-have | The attenuating-filter materials and thicknesses on the `filter_y` axis. | A filter bound to `Filter`. | The filter Asset detail. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The sample-motor stack: the rotary, the sample-centring axes (`sample_x` / `sample_y`), and the role of `axis1pos` / `axis2pos` / `axis5pos`. | A `RotaryStage` plus a `LinearStage`; axis sets and models pending. | The sample-stage modelling. |
+| ROT-1 | Blocks-go-live | Which sample-stack axis is the tomographic rotation. | One of the `axisNpos` channels is the rotation; identity pending. | The rotation Asset binding. |
+| TRIG-1 | Nice-to-have | The triggering / synchronization scheme for continuous-rotation tomography. | The rotary stage is the master clock feeding the camera trigger. | The trigger wiring. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector chain: the camera sensor / frame rate / model, the `scintillator_type`, and the `camera_objective` set. | A `Scintillator` + `Objective` + `Camera`; specs are per-dataset values, model carried pending. | The detector modelling. |
+| DET-2 | Nice-to-have | The detector-stack axes (`camera_distance`, `camera_elevation`, `tilt_motor`): models, travels, and which is the propagation distance. | A `LinearStage` detector stack; `camera_distance` the propagation distance. | The detector-stack modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | The BCS / LabVIEW control handles per 8.3.2 device (absent from any public manifest). | The handles are unbound, carried pending; the control plane is ALS BCS. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The ALS personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling-water / beam / power supplies. | Photon beam, cooling water, vacuum, and power. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ALS operator pool and safety-review structure (site-level). | Carried pending on the ALS Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/8-3-2/questions.md b/docs/deployments/8-3-2/questions.md
deleted file mode 100644
index 5d6b34afad9..00000000000
--- a/docs/deployments/8-3-2/questions.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Open questions
-
-*What CORA needs the 8.3.2 team to confirm before the model can be trusted.*
-
-8.3.2 was reverse-engineered from ALS's public facility pages ([als.lbl.gov/beamlines/8-3-2](https://als.lbl.gov/beamlines/8-3-2/), [microct.lbl.gov](https://microct.lbl.gov/)) and the public [als-computing](https://github.com/als-computing) GitHub org, not from a live connection. The device structure is read from the DXchange / DXfile HDF5 data record that the ALS tooling reads, but ALS runs BCS (a LabVIEW Beamline Control System, not EPICS) and publishes no per-beamline channel manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. This is CORA's first ALS Site and its first BCS / LabVIEW controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch, or a separate optics hutch feeding it? | A single `8-3-2-hutch`. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The Superbend field and critical energy. | A superconducting bending-magnet source, 6-43 keV; field pending. | The source Asset detail. |
-| ALSU-1 | Nice-to-have | The ALS-U upgrade fate of 8.3.2: does it go dark, get rebuilt, or relocate, and on what schedule? | Dark time no sooner than October 2027; 8.3.2's fate carried pending. | The deployment roadmap. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The ALS storage-ring state 8.3.2 reads (the `source_name` / `current` handles). | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The energy optic: the mechanism (multilayer vs crystal), d-spacing, and how the `energy`, `Z2`, `turret1` / `turret2`, and `TC2` / `TC3` channels relate. | An energy-setting `Monochromator`, 6-43 keV; `energy` the master axis. | The monochromator and energy modelling. |
-| OPT-2 | Nice-to-have | The slit blade-axis map (the `hslits_*` and `vslits_*` channels) and handles. | Horizontal + vertical slits bound to `Slit`. | The slit Asset detail. |
-| FILT-1 | Nice-to-have | The attenuating-filter materials and thicknesses on the `filter_y` axis. | A filter bound to `Filter`. | The filter Asset detail. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The sample-motor stack: the rotary, the sample-centring axes (`sample_x` / `sample_y`), and the role of `axis1pos` / `axis2pos` / `axis5pos`. | A `RotaryStage` plus a `LinearStage`; axis sets and models pending. | The sample-stage modelling. |
-| ROT-1 | Blocks-go-live | Which sample-stack axis is the tomographic rotation. | One of the `axisNpos` channels is the rotation; identity pending. | The rotation Asset binding. |
-| TRIG-1 | Nice-to-have | The triggering / synchronization scheme for continuous-rotation tomography. | The rotary stage is the master clock feeding the camera trigger. | The trigger wiring. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector chain: the camera sensor / frame rate / model, the `scintillator_type`, and the `camera_objective` set. | A `Scintillator` + `Objective` + `Camera`; specs are per-dataset values, model carried pending. | The detector modelling. |
-| DET-2 | Nice-to-have | The detector-stack axes (`camera_distance`, `camera_elevation`, `tilt_motor`): models, travels, and which is the propagation distance. | A `LinearStage` detector stack; `camera_distance` the propagation distance. | The detector-stack modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | The BCS / LabVIEW control handles per 8.3.2 device (absent from any public manifest). | The handles are unbound, carried pending; the control plane is ALS BCS. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The ALS personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling-water / beam / power supplies. | Photon beam, cooling water, vacuum, and power. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ALS operator pool and safety-review structure (site-level). | Carried pending on the ALS Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/8-3-2/techniques.md b/docs/deployments/8-3-2/techniques.md
deleted file mode 100644
index a516c7a25a8..00000000000
--- a/docs/deployments/8-3-2/techniques.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Techniques
-
-*What the modelled part of 8.3.2 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../als/index.md#the-techniques-adapted-here) is how a facility adapts it. 8.3.2 is a hard X-ray micro-tomography beamline: its techniques reuse Methods CORA's catalog already carries.
-
-## Hard X-ray micro-tomography
-
-8.3.2 sets the X-ray energy with the monochromator (6,000-43,000 eV from the Superbend source), then rotates the sample on the tomographic rotary stage while the scintillator, objective, and camera record projections. It images non-destructively in 3D at ~1 micron resolution, with absorption and propagation-phase contrast (the detector stack's `camera_distance` sets the propagation distance).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Tomography | [`tomography`](../../catalog/methods.md) | absorption and propagation-phase micro-CT, the [rotary stage](sample.md) stepped against the [scintillator + camera](detector.md); reuses the catalog tomography Method (the 2-BM pilot) |
-| Continuous-rotation tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | fast fly-scan tomography, the [rotary stage](sample.md) in continuous rotation as the trigger master (`TRIG-1`); reuses the catalog continuous-rotation Method |
-
-Tomography needs the [incident energy](source.md) set by the [monochromator](source.md), the [rotary stage and sample positioning](sample.md), and the [scintillator + objective + camera](detector.md), with the [detector stack](detector.md) setting the sample-to-detector propagation distance.
-
-## A new Site on familiar vocabulary
-
-8.3.2 is the ALS's hard X-ray micro-CT beamline, and it ties into the tomography lineage CORA already models: the same imaging device anatomy as the 2-BM pilot, the NSLS-II FXI design, and the ALBA FAXTOR design (a bending-magnet or insertion-device source, an energy-setting optic, a rotary-stage endstation, and an indirect scintillator + camera detector). It reuses the `tomography` and `continuous_rotation_tomography` Methods directly; none forces a new device family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the fly-scan tomography sequences and their counting times, the flat / dark sequencing, the propagation-phase setups) are not written yet; they join as the deployment approaches the point where CORA drives 8.3.2. See [Open questions](questions.md) for the world-facts to confirm first, in particular which sample-stack axis is the tomographic rotation (`ROT-1`) and the triggering scheme (`TRIG-1`).
diff --git a/docs/deployments/8-id/governance.md b/docs/deployments/8-id/governance.md
deleted file mode 100644
index 1ad4688e676..00000000000
--- a/docs/deployments/8-id/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 8-ID, and the trust shape that will gate it. First cut.*
-
-Governance at 8-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-8-ID is not yet driven by CORA, so this shape is not yet instantiated. The 8-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation (a placeholder `8-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them. 8-ID adds hazard classes beyond the imaging envelope, cryogens at the temperature-controlled sample environments and the user-brought rheometer and robotic sample changer, that an experiment Clearance would carry; those land with the instruments that bring them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 8-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/8-id/model.md b/docs/deployments/8-id/model.md
deleted file mode 100644
index a934d8c0fd1..00000000000
--- a/docs/deployments/8-id/model.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 8-ID content lives, the XPCS deployment that added the `xpcs` Method and landed the Diffractometer Assembly, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 8-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Loose families held for gate-review
-
-8-ID adds a second independent APS beamline (after 4-ID POLAR) to three device classes that recur widely: `TemperatureController`, `Transfocator`, and `PositionMonitor`. All three have since graduated to catalog Families. `TemperatureController` graduated when the parallel Diamond i22/i03/i11 rule-of-three settled the settable-actuator abstraction (`ENV-1`), and it presents the new `Regulator` Role. `Transfocator` graduated as a CRL focusing optic Family, distinct from `Mirror` / `ZonePlate` / `Condenser`: it is bound across several beamlines (APS 4-ID/8-ID/9-id, Diamond i22, NSLS-II chx/smi/ixs, SLAC lcls-mfx), and the cross-facility review settled it as the CRL-specific home rather than a general focusing optic. `PositionMonitor` graduated as its own catalog Family presenting the `Sensor` Role, earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines), distinct from the graduated `FluxMonitor` by what it measures: beam position and centroid, not flux or intensity. The still-loose `Diagnostic` family (arrival-time and photon-spectrum monitors) stays loose, a separate abstraction that measures timing and spectrum rather than position; only the per-Asset beam-center calibration and the position-versus-intensity channel split stay open (`DIAG-1`).
-
-| Loose family | Presents (when graduated) | At 4-ID | At 8-ID |
-| --- | --- | --- | --- |
-| `PositionMonitor` | Sensor | XBPM / Sydor / TetrAMM | Sydor (8-ID-E) + TetrAMM (8-ID-I) |
-
-`Transfocator` and `TemperatureController` were tracked here too and have since graduated to catalog Families. `Transfocator` is the CRL focusing optic Family the two 8-ID-D lens stacks bind (the lens material and lenslet count stay open, `OPT-3`). `TemperatureController` (#350) presents the `Regulator` Role (the LakeShore 336 at 8-ID-E and the Quantum Northwest holders at 8-ID-I bind it). Neither is held for gate-review any longer.
-
-`Magnet` was tracked here too on a single physical beamline (4-ID; `6idb-bits` is a 4-ID fork, see the [4-ID model page](../4-id/model.md#deliberately-not-here-yet)); it has since graduated to a catalog Family on the 4-ID + i10-1 + ID32 rule-of-three (it presents the `Regulator` Role). `Preamplifier` stays loose on that single physical beamline.
-
-## The Diffractometer Assembly (landed)
-
-The `Assembly(Diffractometer)` designed during the catalog-graduation pass is now real, and it **composes the `Goniometer` Family** that landed for I03 MX (#340) rather than re-modelling the sample circles. It is in [`catalog/catalog.yaml`](https://github.com/xmap/cora/blob/main/catalog/catalog.yaml) as a flat assembly presenting the Positioner Role, with slots `goniometer` (Goniometer, `Exactly1`, the sample-orientation circles plus centring), `detector_arm` (RotaryStage, `ZeroOrMore`, spanning 8-ID's nu / delta and 4-ID's detector-arm-less geometries), and `reciprocal_space` (PseudoAxis, whose partition rule resolves the hklpy2 inverse kinematics). The distinction from the Goniometer Family is deliberate: the Goniometer is the integrated single-device sample orienter (the I03 Smargon); the Diffractometer is the larger composed scattering instrument that USES one. The integration scenario [`test_8id_diffractometer_setup.py`](https://github.com/xmap/cora/blob/main/apps/api/tests/integration/scenarios/test_8id_diffractometer_setup.py) materializes it end-to-end against Postgres: it installs the four 8-ID-E constituent Assets (a Goniometer for mu / eta / chi / phi, the nu / delta detector-arm circles, and the reciprocal-space axis), defines the Assembly, and registers a Fixture binding the two detector circles to the `detector_arm` slot. The circle-role confirmation remains `DIFF-1` and the reciprocal-space solver rule is `DIFF-2`; the 4-ID Fixture is the follow-on (the Assembly is shared, the Fixture is per-beamline).
-
-## Deliberately not here yet
-
-- **The UR5 robotic sample changer.** `RobocartUR5` is a user-brought robotic arm; CORA has no sample-changer shape (the same gap the 32-ID projection-microscope changer raised). It is not modelled (`SAMPLE-2`).
-
-- **The softGlue timing graph.** The XPCS exposure timing runs on a softGlueZynq FPGA fabric (`8idMZ1:`); it is modelled coarsely as one `TimingController`, not as its full signal graph (`XPCS-3`).
-
-- **The event-stream acquisition axis (the XPCS execution).** The `xpcs` Method is now in the catalog, but the acquisition primitive that runs it is not: an XPCS Run is a DAQ-owned high-rate frame stream (begin/end a per-frame burst correlated downstream into g2), which CORA's poll-to-Done acquisition bodies (`collect` / `discrete` / `continuous`) cannot execute. 8-ID is the second beamline after LCLS-MFX to hit this, which promoted the event-stream axis to Stage 1 (design-locked, gate-review next; recorded in CORA's design memory). No spine code lands in this pass.
-
-- **The remaining scattering Methods.** Whether small-angle scattering and six-circle diffraction enter CORA's catalog is an owner decision; their Practices render unlinked, pending (`TECH-1`).
-
-- **Full asset-tree scenarios and vendor Models.** Beyond the diffractometer Assembly / Fixture scenario above, no `test_8id_*.py` registers the full 8-ID asset tree (the optics spine, the XPCS endstation), and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/8-id/notes.md b/docs/deployments/8-id/notes.md
new file mode 100644
index 00000000000..c57dbcf1019
--- /dev/null
+++ b/docs/deployments/8-id/notes.md
@@ -0,0 +1,149 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 8-ID is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 8-ID's signature technique, **XPCS, is now a catalog Method** (`cora.capability.xpcs`): it is the second beamline after LCLS-MFX to need a DAQ-owned high-rate frame stream, which graduated XPCS out of the imaging-heritage catalog. Small-angle scattering and six-circle diffraction stay pending until they enter scope (`TECH-1`).
+
+### X-ray photon correlation spectroscopy
+
+XPCS measures the time correlations of a coherent speckle pattern to probe sample dynamics, so it records long, fast time series on an area detector under a precisely gated exposure.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| XPCS | [`xpcs`](../../catalog/methods.md) | coherent-scattering intensity time series on the Eiger / Lambda / Rigaku detectors, gated by the softGlue timing; now a catalog Method. Its acquisition is a DAQ-owned high-rate frame stream with no executing body yet, the [event-stream acquisition axis](#deliberately-not-here-yet) (Stage 1) |
+| Small-angle scattering | `small_angle_scattering` | static SAXS on the same detectors; a Plan setting over the same chain |
+
+Both need the [XPCS sample stage](sample.md), the [coherent detectors](detector.md), and the flight path. The fast shutter and softGlue timing (`XPCS-1`, `XPCS-3`) gate the exposure.
+
+### Six-circle diffraction
+
+The 8-ID-E Huber diffractometer orients a single crystal through six circles and scans reciprocal space, sharing the diffraction Method with 4-ID.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Six-circle diffraction | `diffraction` | reciprocal-space scans on the six-circle Huber; shares the 4-ID `diffraction` Method (`TECH-1`) |
+
+It needs the [diffractometer](sample.md). The reciprocal-space coordination is `DIFF-2`; the reusable `Assembly(Diffractometer)` is on [Model](#deliberately-not-here-yet).
+
+### Not modelled yet
+
+The XPCS Method now exists, but the concrete acquisition primitive that executes it (a DAQ-owned high-rate frame stream, not a poll-to-Done capture) does not: that is the [event-stream acquisition axis](#deliberately-not-here-yet), now at Stage 1 (8-ID XPCS is its second beamline after LCLS-MFX). Small-angle scattering and diffraction Methods remain an owner-scope decision (`TECH-1`); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at 8-ID, and the trust shape that will gate it. First cut.*
+
+Governance at 8-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+8-ID is not yet driven by CORA, so this shape is not yet instantiated. The 8-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation (a placeholder `8-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them. 8-ID adds hazard classes beyond the imaging envelope, cryogens at the temperature-controlled sample environments and the user-brought rheometer and robotic sample changer, that an experiment Clearance would carry; those land with the instruments that bring them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 8-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 8-ID content lives, the XPCS deployment that added the `xpcs` Method and landed the Diffractometer Assembly, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 8-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Loose families held for gate-review
+
+8-ID adds a second independent APS beamline (after 4-ID POLAR) to three device classes that recur widely: `TemperatureController`, `Transfocator`, and `PositionMonitor`. All three have since graduated to catalog Families. `TemperatureController` graduated when the parallel Diamond i22/i03/i11 rule-of-three settled the settable-actuator abstraction (`ENV-1`), and it presents the new `Regulator` Role. `Transfocator` graduated as a CRL focusing optic Family, distinct from `Mirror` / `ZonePlate` / `Condenser`: it is bound across several beamlines (APS 4-ID/8-ID/9-id, Diamond i22, NSLS-II chx/smi/ixs, SLAC lcls-mfx), and the cross-facility review settled it as the CRL-specific home rather than a general focusing optic. `PositionMonitor` graduated as its own catalog Family presenting the `Sensor` Role, earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines), distinct from the graduated `FluxMonitor` by what it measures: beam position and centroid, not flux or intensity. The still-loose `Diagnostic` family (arrival-time and photon-spectrum monitors) stays loose, a separate abstraction that measures timing and spectrum rather than position; only the per-Asset beam-center calibration and the position-versus-intensity channel split stay open (`DIAG-1`).
+
+| Loose family | Presents (when graduated) | At 4-ID | At 8-ID |
+| --- | --- | --- | --- |
+| `PositionMonitor` | Sensor | XBPM / Sydor / TetrAMM | Sydor (8-ID-E) + TetrAMM (8-ID-I) |
+
+`Transfocator` and `TemperatureController` were tracked here too and have since graduated to catalog Families. `Transfocator` is the CRL focusing optic Family the two 8-ID-D lens stacks bind (the lens material and lenslet count stay open, `OPT-3`). `TemperatureController` (#350) presents the `Regulator` Role (the LakeShore 336 at 8-ID-E and the Quantum Northwest holders at 8-ID-I bind it). Neither is held for gate-review any longer.
+
+`Magnet` was tracked here too on a single physical beamline (4-ID; `6idb-bits` is a 4-ID fork, see the [4-ID model page](../4-id/notes.md#deliberately-not-here-yet)); it has since graduated to a catalog Family on the 4-ID + i10-1 + ID32 rule-of-three (it presents the `Regulator` Role). `Preamplifier` stays loose on that single physical beamline.
+
+### The Diffractometer Assembly (landed)
+
+The `Assembly(Diffractometer)` designed during the catalog-graduation pass is now real, and it **composes the `Goniometer` Family** that landed for I03 MX (#340) rather than re-modelling the sample circles. It is in [`catalog/catalog.yaml`](https://github.com/xmap/cora/blob/main/catalog/catalog.yaml) as a flat assembly presenting the Positioner Role, with slots `goniometer` (Goniometer, `Exactly1`, the sample-orientation circles plus centring), `detector_arm` (RotaryStage, `ZeroOrMore`, spanning 8-ID's nu / delta and 4-ID's detector-arm-less geometries), and `reciprocal_space` (PseudoAxis, whose partition rule resolves the hklpy2 inverse kinematics). The distinction from the Goniometer Family is deliberate: the Goniometer is the integrated single-device sample orienter (the I03 Smargon); the Diffractometer is the larger composed scattering instrument that USES one. The integration scenario [`test_8id_diffractometer_setup.py`](https://github.com/xmap/cora/blob/main/apps/api/tests/integration/scenarios/test_8id_diffractometer_setup.py) materializes it end-to-end against Postgres: it installs the four 8-ID-E constituent Assets (a Goniometer for mu / eta / chi / phi, the nu / delta detector-arm circles, and the reciprocal-space axis), defines the Assembly, and registers a Fixture binding the two detector circles to the `detector_arm` slot. The circle-role confirmation remains `DIFF-1` and the reciprocal-space solver rule is `DIFF-2`; the 4-ID Fixture is the follow-on (the Assembly is shared, the Fixture is per-beamline).
+
+### Deliberately not here yet
+
+- **The UR5 robotic sample changer.** `RobocartUR5` is a user-brought robotic arm; CORA has no sample-changer shape (the same gap the 32-ID projection-microscope changer raised). It is not modelled (`SAMPLE-2`).
+
+- **The softGlue timing graph.** The XPCS exposure timing runs on a softGlueZynq FPGA fabric (`8idMZ1:`); it is modelled coarsely as one `TimingController`, not as its full signal graph (`XPCS-3`).
+
+- **The event-stream acquisition axis (the XPCS execution).** The `xpcs` Method is now in the catalog, but the acquisition primitive that runs it is not: an XPCS Run is a DAQ-owned high-rate frame stream (begin/end a per-frame burst correlated downstream into g2), which CORA's poll-to-Done acquisition bodies (`collect` / `discrete` / `continuous`) cannot execute. 8-ID is the second beamline after LCLS-MFX to hit this, which promoted the event-stream axis to Stage 1 (design-locked, gate-review next; recorded in CORA's design memory). No spine code lands in this pass.
+
+- **The remaining scattering Methods.** Whether small-angle scattering and six-circle diffraction enter CORA's catalog is an owner decision; their Practices render unlinked, pending (`TECH-1`).
+
+- **Full asset-tree scenarios and vendor Models.** Beyond the diffractometer Assembly / Fixture scenario above, no `test_8id_*.py` registers the full 8-ID asset tree (the optics spine, the XPCS endstation), and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 8-ID team to confirm before the model can be trusted.*
+
+8-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/8id-bits](https://github.com/BCDA-APS/8id-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the catalog graduation and the diffractometer Assembly). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | Are the two undulators canted feeding separate branches, and do the four stations (`8-ID-A/D/E/I`) run off one beam in series or split? | One root Unit Asset `8-ID` with one optics spine feeding the stations in series. | One-vs-many beam walks in the [descriptor](index.md). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the 8id-bits config current and correct? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the four hutches. | Four hutches exist with permit signals to be named. | The Enclosure permit signals. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The two undulators (downstream DSID, upstream USID): types, periods, and whether canted. | Two `InsertionDevice` Assets; periods unconfirmed. | The insertion-device specs. |
+| MONO-1 | Blocks-go-live | The MN1 monochromator energy range and crystal. | One `Monochromator` Asset (8idaSoft:MN1); range unconfirmed. | The monochromator energy model. |
+| MONO-2 | Nice-to-have | The in-line `idt_mono` (8idaSoft:MONO): is it a second monochromator or a different optic? | Not modelled in this cut. | Whether it becomes a second Asset. |
+| OPT-1 | Nice-to-have | The two FMBO mirrors: coatings and the bender / piezo-pitch axis roles. | Two `Mirror` Assets with the config's axis maps; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The slit internal axis maps (most slits carried only a base PV in the config). | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
+| OPT-3 | Blocks-go-live | The two CRL transfocators (rl1, rl2): lens material and the per-lens actuator roles (ten lenses each). | Two `Transfocator` Assets; x/y/pitch/yaw mapped, the ten lens actuators summarized. | The transfocator spec. |
+
+### Diffractometer
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The six-circle Huber geometry: confirm the circle roles (mu, eta, chi, phi, nu, delta) and which is sample versus detector arm. | A six-circle diffractometer modelled as a plain device with the config's axis map; this confirms the `Assembly(Diffractometer)` slot shape. | The circle geometry and the Assembly slots (see [Model](#deliberately-not-here-yet)). |
+| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: is hklpy2 driving an (h, k, l, energy) pseudo-axis over this geometry? | A `PseudoAxis` Asset (psic) is modelled for the reciprocal-space layer. | The pseudo-axis model. |
+
+### Sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TEMP-1 | Nice-to-have | The LakeShore 336 controllers and the Quantum Northwest holders: sensor channels and the sample stages they regulate. | `TemperatureController` Assets at 8-ID-E and 8-ID-I. | The temperature-controller model. |
+| SAMPLE-1 | Nice-to-have | The rheometer shear-cell: the six axes and the shear modes it supports. | One `Rheometer` Asset (loose Family) with a six-axis map. | The rheometer model. |
+| SAMPLE-2 | Nice-to-have | The UR5 robotic sample changer (RobocartUR5): is it CORA-driven, and what is its sample-exchange model? | Deferred; not modelled (CORA has no sample-changer shape). | The sample-changer model. |
+
+### Detector and XPCS
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The three area detectors (Eiger 4M, Lambda 2M, Rigaku 3M): models, sensors, and frame rates. | Three `Camera` Assets; models unconfirmed. | The detector Model bindings. |
+| BPM-1 | Nice-to-have | The Sydor beam-position monitor and the four TetrAMM channels: which are position monitors versus intensity (I0) normalizers? | Bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
+| XPCS-1 | Nice-to-have | The fast shutter timing and its role in the XPCS exposure sequence. | One `Shutter` Asset (8ideSoft:fastshutter). | The fast-shutter model. |
+| XPCS-2 | Nice-to-have | The flight-path geometry (length, swing) and the beam-stop relationship. | One `FlightPath` Asset (loose Family) plus a `BeamStop`. | The flight-path model. |
+| XPCS-3 | Nice-to-have | The softGlue FPGA timing graph (8idMZ1): the signal routing for detector gating. | One `TimingController` Asset; the signal graph is not modelled. | The timing model. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | The vacuum and process-gas supplies the flight path and sample environments draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/8-id/questions.md b/docs/deployments/8-id/questions.md
deleted file mode 100644
index 0d5521a13cd..00000000000
--- a/docs/deployments/8-id/questions.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Open questions
-
-*What CORA needs the 8-ID team to confirm before the model can be trusted.*
-
-8-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/8id-bits](https://github.com/BCDA-APS/8id-bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the catalog graduation and the diffractometer Assembly). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | Are the two undulators canted feeding separate branches, and do the four stations (`8-ID-A/D/E/I`) run off one beam in series or split? | One root Unit Asset `8-ID` with one optics spine feeding the stations in series. | One-vs-many beam walks in the [descriptor](index.md). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the 8id-bits config current and correct? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the four hutches. | Four hutches exist with permit signals to be named. | The Enclosure permit signals. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The two undulators (downstream DSID, upstream USID): types, periods, and whether canted. | Two `InsertionDevice` Assets; periods unconfirmed. | The insertion-device specs. |
-| MONO-1 | Blocks-go-live | The MN1 monochromator energy range and crystal. | One `Monochromator` Asset (8idaSoft:MN1); range unconfirmed. | The monochromator energy model. |
-| MONO-2 | Nice-to-have | The in-line `idt_mono` (8idaSoft:MONO): is it a second monochromator or a different optic? | Not modelled in this cut. | Whether it becomes a second Asset. |
-| OPT-1 | Nice-to-have | The two FMBO mirrors: coatings and the bender / piezo-pitch axis roles. | Two `Mirror` Assets with the config's axis maps; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The slit internal axis maps (most slits carried only a base PV in the config). | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
-| OPT-3 | Blocks-go-live | The two CRL transfocators (rl1, rl2): lens material and the per-lens actuator roles (ten lenses each). | Two `Transfocator` Assets; x/y/pitch/yaw mapped, the ten lens actuators summarized. | The transfocator spec. |
-
-## Diffractometer
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The six-circle Huber geometry: confirm the circle roles (mu, eta, chi, phi, nu, delta) and which is sample versus detector arm. | A six-circle diffractometer modelled as a plain device with the config's axis map; this confirms the `Assembly(Diffractometer)` slot shape. | The circle geometry and the Assembly slots (see [Model](model.md#deliberately-not-here-yet)). |
-| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: is hklpy2 driving an (h, k, l, energy) pseudo-axis over this geometry? | A `PseudoAxis` Asset (psic) is modelled for the reciprocal-space layer. | The pseudo-axis model. |
-
-## Sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TEMP-1 | Nice-to-have | The LakeShore 336 controllers and the Quantum Northwest holders: sensor channels and the sample stages they regulate. | `TemperatureController` Assets at 8-ID-E and 8-ID-I. | The temperature-controller model. |
-| SAMPLE-1 | Nice-to-have | The rheometer shear-cell: the six axes and the shear modes it supports. | One `Rheometer` Asset (loose Family) with a six-axis map. | The rheometer model. |
-| SAMPLE-2 | Nice-to-have | The UR5 robotic sample changer (RobocartUR5): is it CORA-driven, and what is its sample-exchange model? | Deferred; not modelled (CORA has no sample-changer shape). | The sample-changer model. |
-
-## Detector and XPCS
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The three area detectors (Eiger 4M, Lambda 2M, Rigaku 3M): models, sensors, and frame rates. | Three `Camera` Assets; models unconfirmed. | The detector Model bindings. |
-| BPM-1 | Nice-to-have | The Sydor beam-position monitor and the four TetrAMM channels: which are position monitors versus intensity (I0) normalizers? | Bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
-| XPCS-1 | Nice-to-have | The fast shutter timing and its role in the XPCS exposure sequence. | One `Shutter` Asset (8ideSoft:fastshutter). | The fast-shutter model. |
-| XPCS-2 | Nice-to-have | The flight-path geometry (length, swing) and the beam-stop relationship. | One `FlightPath` Asset (loose Family) plus a `BeamStop`. | The flight-path model. |
-| XPCS-3 | Nice-to-have | The softGlue FPGA timing graph (8idMZ1): the signal routing for detector gating. | One `TimingController` Asset; the signal graph is not modelled. | The timing model. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | The vacuum and process-gas supplies the flight path and sample environments draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/8-id/techniques.md b/docs/deployments/8-id/techniques.md
deleted file mode 100644
index 99af6329903..00000000000
--- a/docs/deployments/8-id/techniques.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Techniques
-
-*What the modelled part of 8-ID is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 8-ID's signature technique, **XPCS, is now a catalog Method** (`cora.capability.xpcs`): it is the second beamline after LCLS-MFX to need a DAQ-owned high-rate frame stream, which graduated XPCS out of the imaging-heritage catalog. Small-angle scattering and six-circle diffraction stay pending until they enter scope (`TECH-1`).
-
-## X-ray photon correlation spectroscopy
-
-XPCS measures the time correlations of a coherent speckle pattern to probe sample dynamics, so it records long, fast time series on an area detector under a precisely gated exposure.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| XPCS | [`xpcs`](../../catalog/methods.md) | coherent-scattering intensity time series on the Eiger / Lambda / Rigaku detectors, gated by the softGlue timing; now a catalog Method. Its acquisition is a DAQ-owned high-rate frame stream with no executing body yet, the [event-stream acquisition axis](model.md#deliberately-not-here-yet) (Stage 1) |
-| Small-angle scattering | `small_angle_scattering` | static SAXS on the same detectors; a Plan setting over the same chain |
-
-Both need the [XPCS sample stage](sample.md), the [coherent detectors](detector.md), and the flight path. The fast shutter and softGlue timing (`XPCS-1`, `XPCS-3`) gate the exposure.
-
-## Six-circle diffraction
-
-The 8-ID-E Huber diffractometer orients a single crystal through six circles and scans reciprocal space, sharing the diffraction Method with 4-ID.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Six-circle diffraction | `diffraction` | reciprocal-space scans on the six-circle Huber; shares the 4-ID `diffraction` Method (`TECH-1`) |
-
-It needs the [diffractometer](sample.md). The reciprocal-space coordination is `DIFF-2`; the reusable `Assembly(Diffractometer)` is on [Model](model.md#deliberately-not-here-yet).
-
-## Not modelled yet
-
-The XPCS Method now exists, but the concrete acquisition primitive that executes it (a DAQ-owned high-rate frame stream, not a poll-to-Done capture) does not: that is the [event-stream acquisition axis](model.md#deliberately-not-here-yet), now at Stage 1 (8-ID XPCS is its second beamline after LCLS-MFX). Small-angle scattering and diffraction Methods remain an owner-scope decision (`TECH-1`); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/9-id/governance.md b/docs/deployments/9-id/governance.md
deleted file mode 100644
index 729583115bc..00000000000
--- a/docs/deployments/9-id/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at 9-ID, and the trust shape that will gate it. First cut.*
-
-Governance at 9-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-9-ID is not yet driven by CORA, so this shape is not yet instantiated. The 9-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation (a placeholder `9-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them. 9-ID's hazard classes are within the X-ray and vacuum envelope of the optics-and-detector beamlines; user-brought sample environments on the CSSI stack would carry their own hazards on an experiment Clearance, landing with the instruments that bring them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 9-ID, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/9-id/model.md b/docs/deployments/9-id/model.md
deleted file mode 100644
index 8725090a3ed..00000000000
--- a/docs/deployments/9-id/model.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's 9-ID content lives, the cleanest pure-reuse case in the APS fleet whose metadata and Data Management PVs are a CORA seam not Assets, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at 9-ID |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Catalog reuse (what this deployment proves)
-
-9-ID is the cleanest reuse case in the APS fleet: a coherent-scattering beamline outside the imaging and diffraction cores, and yet every optic and detector binds a Family the catalog already had. `InsertionDevice`, `Monochromator`, `Mirror` (twice: the FMBO pair and the KB pair), `Aperture`, `Filter`, `Slit`, `Hexapod`, `Camera`, `BeamStop`, `LinearStage`, `RotaryStage`, `GenericProbe`, and the graduated `Transfocator` (the CRL focusing optic) all carry it with no new abstraction. That 9-ID needs no new Family is the evidence: the families earned on 2-BM, the diffraction beamlines, and the Diamond deployments cover a beamline none of them were derived from. So this cut adds nothing to `catalog.yaml`.
-
-## A loose family still held for gate-review
-
-9-ID's CRL `Transfocator` binds the graduated catalog Family (a CRL focusing optic) that 4-ID, 8-ID, and i22 also use. The cross-facility abstraction review settled the question of its catalog home: it is a CRL-specific Family, not a fold into a general focusing optic, so 9-ID's transfocator is plain catalog reuse now, like its mirrors. What graduation does not resolve is the per-Asset lens spec, the material and lenslet count of this transfocator, which stays open as `OPT-3`.
-
-The `PositionMonitor`, which appears at 4-ID, 8-ID, and 9-ID, has since graduated into the catalog as its own Family presenting the `Sensor` Role, earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines). The fold-vs-promote question that once held it is resolved in favour of promote: it is distinct from the graduated `FluxMonitor` by what it measures, beam position and centroid rather than flux or intensity (`FLUX-1` graduated `FluxMonitor`). Its naming-r3 review was done during that pass. The still-loose `Diagnostic` family (arrival-time and photon-spectrum monitors) is a separate abstraction that measures timing and spectrum, not position, and stays loose; only the per-Asset beam-center calibration and the position-versus-intensity channel split stay open here (`DIAG-1`).
-
-| Loose family | Presents (when graduated) | At 9-ID | Also at |
-| --- | --- | --- | --- |
-| `PositionMonitor` | Sensor | TetrAMM + two XBPMs (9-ID-D) | 4-ID, 8-ID |
-
-## The metadata and Data Management seam
-
-The 9-ID instrument config carries a large set of metadata PVs (`experiment_name`, `sample_name`, `file_path`, `qmap_file`, `workflow_name`, `measurement_num`, and more) and a `DM_WorkflowConnector` that triggers APS Data Management workflows. These are not beamline hardware: they are where the beamline records what an experiment is and hands its data to downstream processing. That is exactly the job CORA's event-sourced system of record does. So they are modelled as a **seam, not as Assets**: CORA's Run and experiment record subsume the metadata bookkeeping, and the Data Management workflow trigger is the compute seam CORA's conduct path drives over (the same shape as the `DM_WorkflowConnector` that recurs in the APS fleet). Modelling these PVs as devices would mistake the bookkeeping CORA replaces for hardware it observes.
-
-## Deliberately not here yet
-
-- **The grazing-incidence sample Assembly.** The CSSI stack (translation, incidence rotation, hexapods, viewing microscope) is modelled as plain devices. Whether it composes into a sample Assembly, the way the 2-BM sample tower and the Diffractometer do, is deferred until a second grazing-incidence beamline gives the abstraction a rule-of-three (`CSSI-1`).
-
-- **The diagnostic flags and the DAMM mask.** `flag1-3` and the DAMM mask carried only their insertion-motor PVs in the config; they are folded into a descriptor note pending identification, not modelled as Assets (`DIAG-1`).
-
-- **The remaining scattering Methods.** 9-ID's surface-XPCS Practice now links to the catalog `xpcs` Method (shared with 8-ID; its DAQ-owned high-rate-stream execution is the event-stream axis, Stage 1). Whether coherent surface scattering and grazing-incidence scattering enter the catalog stays an owner decision; those Practices render unlinked, pending (`TECH-1`), and the WAXS Practice shares the i22 one.
-
-- **The simulated devices.** The instrument config carries simulated motors and detectors (`sim_motor_cssi`, `sim_det_saxs`, and so on) for offline testing; they are excluded from the model.
-
-- **Full asset-tree scenarios and vendor Models.** No `test_9id_*.py` registers the 9-ID asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/9-id/notes.md b/docs/deployments/9-id/notes.md
new file mode 100644
index 00000000000..3d62e1b2d23
--- /dev/null
+++ b/docs/deployments/9-id/notes.md
@@ -0,0 +1,145 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of 9-ID is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 9-ID's techniques are coherent surface scattering and grazing-incidence scattering, new to CORA's imaging-heritage catalog, so the Methods below render unlinked and are carried pending until one enters scope (`TECH-1`).
+
+### Coherent surface scattering
+
+The CSSI signature: a coherent beam strikes the sample surface at a shallow grazing angle, so the scattered intensity is sensitive to surface structure and, over time, surface dynamics.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Coherent surface scattering | `coherent_surface_scattering` | the grazing-incidence coherent measurement on the area detectors; Method not yet in catalog |
+| Surface XPCS | [`xpcs`](../../catalog/methods.md) | time-correlation of the surface speckle pattern; shares the 8-ID `xpcs` catalog Method (its DAQ-owned high-rate-stream execution is the event-stream axis, Stage 1) |
+
+Both need the [grazing-incidence sample stack](sample.md) (the incidence rotation sets the angle) and the [coherent detectors](detector.md).
+
+### Grazing-incidence scattering
+
+GISAXS and GIWAXS read the small- and wide-angle scattering from the grazing-incidence geometry.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Grazing-incidence scattering | `grazing_incidence_scattering` | GISAXS on the Pilatus / Eiger and GIWAXS on the pedestal detector (`TECH-1`) |
+| Wide-angle scattering | `wide_angle_scattering` | the GIWAXS leg; shares the i22 WAXS Method |
+
+It needs the same sample stack and the [WAXS detector](detector.md) on its pedestal.
+
+### Not modelled yet
+
+The concrete acquisition recipes (incidence-angle scans, correlation time series, frame rates, exposures) are not written yet; they join as the deployment approaches the point where CORA drives 9-ID. Whether these Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at 9-ID, and the trust shape that will gate it. First cut.*
+
+Governance at 9-ID follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [APS Site](../aps/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+9-ID is not yet driven by CORA, so this shape is not yet instantiated. The 9-ID operator pool and beamline-scientist assignments are not modelled ahead of confirmation (a placeholder `9-ID Beamline Scientist` is carried pending on the [APS Site](../aps/index.md#safety-and-governance)).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [APS Site](../aps/index.md#safety-and-governance), not on the beamline, and the beamline links up to them. 9-ID's hazard classes are within the X-ray and vacuum envelope of the optics-and-detector beamlines; user-brought sample environments on the CSSI stack would carry their own hazards on an experiment Clearance, landing with the instruments that bring them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives 9-ID, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's 9-ID content lives, the cleanest pure-reuse case in the APS fleet whose metadata and Data Management PVs are a CORA seam not Assets, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at 9-ID |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Catalog reuse (what this deployment proves)
+
+9-ID is the cleanest reuse case in the APS fleet: a coherent-scattering beamline outside the imaging and diffraction cores, and yet every optic and detector binds a Family the catalog already had. `InsertionDevice`, `Monochromator`, `Mirror` (twice: the FMBO pair and the KB pair), `Aperture`, `Filter`, `Slit`, `Hexapod`, `Camera`, `BeamStop`, `LinearStage`, `RotaryStage`, `GenericProbe`, and the graduated `Transfocator` (the CRL focusing optic) all carry it with no new abstraction. That 9-ID needs no new Family is the evidence: the families earned on 2-BM, the diffraction beamlines, and the Diamond deployments cover a beamline none of them were derived from. So this cut adds nothing to `catalog.yaml`.
+
+### A loose family still held for gate-review
+
+9-ID's CRL `Transfocator` binds the graduated catalog Family (a CRL focusing optic) that 4-ID, 8-ID, and i22 also use. The cross-facility abstraction review settled the question of its catalog home: it is a CRL-specific Family, not a fold into a general focusing optic, so 9-ID's transfocator is plain catalog reuse now, like its mirrors. What graduation does not resolve is the per-Asset lens spec, the material and lenslet count of this transfocator, which stays open as `OPT-3`.
+
+The `PositionMonitor`, which appears at 4-ID, 8-ID, and 9-ID, has since graduated into the catalog as its own Family presenting the `Sensor` Role, earned across the wide fleet that shares it (APS 4-ID/8-ID/9-ID, the NSLS-II beamlines, and the imaging and MX beamlines). The fold-vs-promote question that once held it is resolved in favour of promote: it is distinct from the graduated `FluxMonitor` by what it measures, beam position and centroid rather than flux or intensity (`FLUX-1` graduated `FluxMonitor`). Its naming-r3 review was done during that pass. The still-loose `Diagnostic` family (arrival-time and photon-spectrum monitors) is a separate abstraction that measures timing and spectrum, not position, and stays loose; only the per-Asset beam-center calibration and the position-versus-intensity channel split stay open here (`DIAG-1`).
+
+| Loose family | Presents (when graduated) | At 9-ID | Also at |
+| --- | --- | --- | --- |
+| `PositionMonitor` | Sensor | TetrAMM + two XBPMs (9-ID-D) | 4-ID, 8-ID |
+
+### The metadata and Data Management seam
+
+The 9-ID instrument config carries a large set of metadata PVs (`experiment_name`, `sample_name`, `file_path`, `qmap_file`, `workflow_name`, `measurement_num`, and more) and a `DM_WorkflowConnector` that triggers APS Data Management workflows. These are not beamline hardware: they are where the beamline records what an experiment is and hands its data to downstream processing. That is exactly the job CORA's event-sourced system of record does. So they are modelled as a **seam, not as Assets**: CORA's Run and experiment record subsume the metadata bookkeeping, and the Data Management workflow trigger is the compute seam CORA's conduct path drives over (the same shape as the `DM_WorkflowConnector` that recurs in the APS fleet). Modelling these PVs as devices would mistake the bookkeeping CORA replaces for hardware it observes.
+
+### Deliberately not here yet
+
+- **The grazing-incidence sample Assembly.** The CSSI stack (translation, incidence rotation, hexapods, viewing microscope) is modelled as plain devices. Whether it composes into a sample Assembly, the way the 2-BM sample tower and the Diffractometer do, is deferred until a second grazing-incidence beamline gives the abstraction a rule-of-three (`CSSI-1`).
+
+- **The diagnostic flags and the DAMM mask.** `flag1-3` and the DAMM mask carried only their insertion-motor PVs in the config; they are folded into a descriptor note pending identification, not modelled as Assets (`DIAG-1`).
+
+- **The remaining scattering Methods.** 9-ID's surface-XPCS Practice now links to the catalog `xpcs` Method (shared with 8-ID; its DAQ-owned high-rate-stream execution is the event-stream axis, Stage 1). Whether coherent surface scattering and grazing-incidence scattering enter the catalog stays an owner decision; those Practices render unlinked, pending (`TECH-1`), and the WAXS Practice shares the i22 one.
+
+- **The simulated devices.** The instrument config carries simulated motors and detectors (`sim_motor_cssi`, `sim_det_saxs`, and so on) for offline testing; they are excluded from the model.
+
+- **Full asset-tree scenarios and vendor Models.** No `test_9id_*.py` registers the 9-ID asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the 9-ID team to confirm before the model can be trusted.*
+
+9-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/9id_bits](https://github.com/BCDA-APS/9id_bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the metadata seam and the graduated `PositionMonitor` catalog Family). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | Do the two stations (`9-ID-A`, `9-ID-D`) run off one beam in series, and is there a single undulator or a canted pair? The config showed one undulator (`S09ID:DSID:`) and `9-ID-A` / `9-ID-D` prefixes. | One root Unit Asset `9-ID` with one optics spine feeding 9-ID-D in series; one undulator. | The beam walk and station count in the [descriptor](index.md). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the 9id_bits config current and correct? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
+| CTRL-2 | Nice-to-have | The fly-scan timing: the multi-channel scaler (`9idCSSI:mcs2-01`) and any pulse routing that gates the grazing-incidence scans. | One `GenericProbe` scaler is modelled; the timing graph is not. | The fly-scan timing model. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the two hutches (`9-ID-A`, `9-ID-D`). | Two hutches exist with permit signals to be named. | The Enclosure permit signals. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The undulator on S09ID: type, period, and whether a second device or a canted pair exists. | One `InsertionDevice` Asset; period unconfirmed. | The insertion-device spec. |
+| MONO-1 | Blocks-go-live | The Kohzu monochromator (`idt_mono`, `9ida:`): energy range, crystal set, and per-axis roles. | One `Monochromator` Asset; range unconfirmed. | The monochromator energy model. |
+| OPT-1 | Nice-to-have | The two FMBO mirrors: coatings and the bender / piezo-pitch axis roles. | Two `Mirror` Assets with the config's axis maps; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The white-beam apertures (`SL-1`, `SL-2`) and the guard slits (`Slit3/4/5`): the internal axis maps. | `Aperture` and `Slit` Assets with base PVs; per-blade axes partial. | The aperture and slit axis maps. |
+| OPT-3 | Blocks-go-live | The JJ CRL transfocator (`9idPyCRL:CRL9ID:`): lens material, count, and which stations it focuses. | One `Transfocator` Asset (the graduated catalog Family). | The transfocator spec. |
+| OPT-4 | Nice-to-have | The AVS attenuator (`9idPyFilter:FL1:`): the foil / absorber set. | One `Filter` Asset. | The attenuator model. |
+| OPT-5 | Nice-to-have | The KB focusing pair (`9idKB:`): the per-mirror bender axes and the focal geometry (capacitive-sensor suffixes resolved at runtime). | One `Mirror` Asset with four bender axes plus a granite support. | The KB axis map. |
+
+### Sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CSSI-1 | Blocks-build | The grazing-incidence sample geometry: which motor sets the incidence angle, and the translation-vs-rotation roles of the CSSI stack (`9idCSSI:mcs2-01`, the Aerotech fly Z, the Kohzu stage). | A `LinearStage` for translation and a `RotaryStage` for the incidence angle; the Kohzu stage folded into a note. | The sample geometry and whether it composes into an Assembly. |
+| CSSI-2 | Nice-to-have | The two Aerotech hexapods (`HP1`, `HP2`): what each aligns (sample, KB, detector). | Two `Hexapod` Assets for sample/optic alignment. | The hexapod roles. |
+| CSSI-3 | Nice-to-have | The viewing microscope (`uscope`, `9idCSSI:CR9D1M2`): on-axis sample viewing or a separate optic. | One `Camera` Asset for sample viewing. | The microscope role. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The area detectors: the Pilatus 1M (`PILATUS_1MF:`), the Eiger (prefix a guess), and the WAXS / GIWAXS detector on its pedestal: models, sensors, frame rates. | `Camera` Assets; models unconfirmed. | The detector Model bindings. |
+| BPM-1 | Nice-to-have | The TetrAMM (`9idTetra:QUAD1:`) and the two XBPMs (`xpbm1`, `xpbm2`): which are position monitors versus intensity (I0) normalizers? | Bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
+| DIAG-1 | Nice-to-have | The diagnostic flag cameras (`flag1-3`) and the DAMM mask (`9ida:CR9A1`): what each is, and whether the flags carry cameras CORA should model. | Folded into a descriptor note; not modelled as Assets (only insertion motors extracted). | The diagnostic identification. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | The vacuum and process-gas supplies the focusing optics and detector flight draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/9-id/questions.md b/docs/deployments/9-id/questions.md
deleted file mode 100644
index 6fcfbaab1bb..00000000000
--- a/docs/deployments/9-id/questions.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Open questions
-
-*What CORA needs the 9-ID team to confirm before the model can be trusted.*
-
-9-ID was reverse-engineered from the beamline's own Bluesky instrument repo ([BCDA-APS/9id_bits](https://github.com/BCDA-APS/9id_bits)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from a config snapshot rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the metadata seam and the graduated `PositionMonitor` catalog Family). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | Do the two stations (`9-ID-A`, `9-ID-D`) run off one beam in series, and is there a single undulator or a canted pair? The config showed one undulator (`S09ID:DSID:`) and `9-ID-A` / `9-ID-D` prefixes. | One root Unit Asset `9-ID` with one optics spine feeding 9-ID-D in series; one undulator. | The beam walk and station count in the [descriptor](index.md). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the 9id_bits config current and correct? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
-| CTRL-2 | Nice-to-have | The fly-scan timing: the multi-channel scaler (`9idCSSI:mcs2-01`) and any pulse routing that gates the grazing-incidence scans. | One `GenericProbe` scaler is modelled; the timing graph is not. | The fly-scan timing model. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the two hutches (`9-ID-A`, `9-ID-D`). | Two hutches exist with permit signals to be named. | The Enclosure permit signals. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The undulator on S09ID: type, period, and whether a second device or a canted pair exists. | One `InsertionDevice` Asset; period unconfirmed. | The insertion-device spec. |
-| MONO-1 | Blocks-go-live | The Kohzu monochromator (`idt_mono`, `9ida:`): energy range, crystal set, and per-axis roles. | One `Monochromator` Asset; range unconfirmed. | The monochromator energy model. |
-| OPT-1 | Nice-to-have | The two FMBO mirrors: coatings and the bender / piezo-pitch axis roles. | Two `Mirror` Assets with the config's axis maps; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The white-beam apertures (`SL-1`, `SL-2`) and the guard slits (`Slit3/4/5`): the internal axis maps. | `Aperture` and `Slit` Assets with base PVs; per-blade axes partial. | The aperture and slit axis maps. |
-| OPT-3 | Blocks-go-live | The JJ CRL transfocator (`9idPyCRL:CRL9ID:`): lens material, count, and which stations it focuses. | One `Transfocator` Asset (the graduated catalog Family). | The transfocator spec. |
-| OPT-4 | Nice-to-have | The AVS attenuator (`9idPyFilter:FL1:`): the foil / absorber set. | One `Filter` Asset. | The attenuator model. |
-| OPT-5 | Nice-to-have | The KB focusing pair (`9idKB:`): the per-mirror bender axes and the focal geometry (capacitive-sensor suffixes resolved at runtime). | One `Mirror` Asset with four bender axes plus a granite support. | The KB axis map. |
-
-## Sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CSSI-1 | Blocks-build | The grazing-incidence sample geometry: which motor sets the incidence angle, and the translation-vs-rotation roles of the CSSI stack (`9idCSSI:mcs2-01`, the Aerotech fly Z, the Kohzu stage). | A `LinearStage` for translation and a `RotaryStage` for the incidence angle; the Kohzu stage folded into a note. | The sample geometry and whether it composes into an Assembly. |
-| CSSI-2 | Nice-to-have | The two Aerotech hexapods (`HP1`, `HP2`): what each aligns (sample, KB, detector). | Two `Hexapod` Assets for sample/optic alignment. | The hexapod roles. |
-| CSSI-3 | Nice-to-have | The viewing microscope (`uscope`, `9idCSSI:CR9D1M2`): on-axis sample viewing or a separate optic. | One `Camera` Asset for sample viewing. | The microscope role. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The area detectors: the Pilatus 1M (`PILATUS_1MF:`), the Eiger (prefix a guess), and the WAXS / GIWAXS detector on its pedestal: models, sensors, frame rates. | `Camera` Assets; models unconfirmed. | The detector Model bindings. |
-| BPM-1 | Nice-to-have | The TetrAMM (`9idTetra:QUAD1:`) and the two XBPMs (`xpbm1`, `xpbm2`): which are position monitors versus intensity (I0) normalizers? | Bound to the graduated catalog `PositionMonitor` Family presenting the Sensor Role. | The monitor classification. |
-| DIAG-1 | Nice-to-have | The diagnostic flag cameras (`flag1-3`) and the DAMM mask (`9ida:CR9A1`): what each is, and whether the flags carry cameras CORA should model. | Folded into a descriptor note; not modelled as Assets (only insertion motors extracted). | The diagnostic identification. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | The vacuum and process-gas supplies the focusing optics and detector flight draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/9-id/techniques.md b/docs/deployments/9-id/techniques.md
deleted file mode 100644
index 4cc86263afe..00000000000
--- a/docs/deployments/9-id/techniques.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Techniques
-
-*What the modelled part of 9-ID is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../aps/index.md#the-techniques-adapted-here) is how a facility adapts it. 9-ID's techniques are coherent surface scattering and grazing-incidence scattering, new to CORA's imaging-heritage catalog, so the Methods below render unlinked and are carried pending until one enters scope (`TECH-1`).
-
-## Coherent surface scattering
-
-The CSSI signature: a coherent beam strikes the sample surface at a shallow grazing angle, so the scattered intensity is sensitive to surface structure and, over time, surface dynamics.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Coherent surface scattering | `coherent_surface_scattering` | the grazing-incidence coherent measurement on the area detectors; Method not yet in catalog |
-| Surface XPCS | [`xpcs`](../../catalog/methods.md) | time-correlation of the surface speckle pattern; shares the 8-ID `xpcs` catalog Method (its DAQ-owned high-rate-stream execution is the event-stream axis, Stage 1) |
-
-Both need the [grazing-incidence sample stack](sample.md) (the incidence rotation sets the angle) and the [coherent detectors](detector.md).
-
-## Grazing-incidence scattering
-
-GISAXS and GIWAXS read the small- and wide-angle scattering from the grazing-incidence geometry.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Grazing-incidence scattering | `grazing_incidence_scattering` | GISAXS on the Pilatus / Eiger and GIWAXS on the pedestal detector (`TECH-1`) |
-| Wide-angle scattering | `wide_angle_scattering` | the GIWAXS leg; shares the i22 WAXS Method |
-
-It needs the same sample stack and the [WAXS detector](detector.md) on its pedestal.
-
-## Not modelled yet
-
-The concrete acquisition recipes (incidence-angle scans, correlation time series, frame rates, exposures) are not written yet; they join as the deployment approaches the point where CORA drives 9-ID. Whether these Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/alvra/governance.md b/docs/deployments/alvra/governance.md
deleted file mode 100644
index ba3a0e4b29f..00000000000
--- a/docs/deployments/alvra/governance.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Governance
-
-*Who would act at Alvra and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
-
-Alvra's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `eco` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Alvra inherits it; what Alvra adds to think about is the same two hazard gates LCLS-MFX raised, now at a second XFEL.
-
-## The pump-probe laser Clearance
-
-Alvra runs a class-4 optical laser for pump-probe. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture LCLS-MFX takes for its pump-probe laser and 32-ID takes for its additive-manufacturing laser. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family (the LCLS-MFX / 4-ID precedent), while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
-
-## The PSS permit
-
-As at every beamline, beam-on work in an enclosure is gated by the facility personnel safety system (PSS). The SwissFEL PSS search-and-secure permit signals are not in the `eco` manifest and are carried pending (PSS-1). Alvra's enclosure structure (a shared Aramis optics hutch plus the Alvra experiment hutch) is itself carried `confirm` because the `eco` PV prefixes encode beamline-line zones (`SARFE10` front end, `SAROP11` optics, `SARES11` endstation), not the access-gated hutch or its safety meaning (ENC-1). The shared optics hutch is the same shared-zone question LCLS-MFX's front-end / transport zone raised, because the Aramis source feeds the Alvra, Bernina, and Cristallina stations (TOPO-1).
-
-## What is not modelled
-
-- **Trust instantiation.** No scenario instantiates Alvra trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `eco` / `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
-
-People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](questions.md) for the governance items still to confirm.
diff --git a/docs/deployments/alvra/model.md b/docs/deployments/alvra/model.md
deleted file mode 100644
index 92e7ce51d49..00000000000
--- a/docs/deployments/alvra/model.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's Alvra content lives, how the device families fold at a second XFEL, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at Alvra |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The headline: the families fold again, at a second XFEL
-
-[LCLS-MFX](../lcls-mfx/model.md) found that an XFEL's device families fold and its gaps are architectural. Alvra re-runs that test against an independently-built free-electron laser, mined from PSI's `eco` rather than SLAC's `pcdshub`, and reaches the same finding. Of Alvra's full `eco` device set, **none** had no CORA Family: every device reuses an existing one. The offset and KB mirrors fold into `Mirror`, the solid attenuators into `Filter`, the slits into `Slit`, the pulse picker into `Shutter` (PULSE-1), the profile monitors into `Scintillator` + `Camera`, the PBPS / PBIG monitors into `FluxMonitor` + `Diagnostic`, the double-crystal mono into `Monochromator`, the Huber sample stage into `LinearStage`, the optical table into `Table`, the sample microscope and the Jungfrau into `Camera`, and the pump-probe and reference lasers into the catalog `Laser` Family (the LCLS-MFX / 4-ID precedent). The von Hamos spectrometer binds the graduated `EmissionSpectrometer` Family, a **fourth sighting** after LCLS-MFX (which introduced it), NSLS-II ISS (which graduated it), and the MAX IV Balder near-sighting (SPEC-1). Each fold was reviewed against coining a synonym and rejected.
-
-So the device taxonomy generalizes from storage rings to an XFEL almost untouched, and that result is now confirmed at two independent XFELs. What does not generalize is the **acquisition ontology**, the same as at LCLS-MFX. That is the product of this exercise, recorded next.
-
-## Deliberately not here yet (the architectural gap register)
-
-These are the parts of Alvra this scaffold leaves out on purpose. Unlike the open questions (facts the PSI team owns), each is a CORA scope decision: a shape the model does not yet have, with the seam it would extend named. None is built speculatively; an XFEL is the trigger that would justify the work, and Alvra is the second sighting of each gap, strengthening the case that the work is real and not LCLS-specific.
-
-- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The load-bearing gap, re-confirmed. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. SwissFEL's `sf-daq` collects a free-running `bsread` stream of per-shot frames correlated by pulse-ID at beam rate, exactly the shape LCLS's DAQ has. The Run-as-provenance-envelope survives and the per-shot data plane lives in the SwissFEL data API (CORA references a `Dataset`, as it does for reconstructions via `ComputePort`), but representing a DAQ run as an actuation is a new event-stream axis. Its shape is sketched as a forward-looking design note in CORA's design memory (gated, not built); Alvra is the second deployment to need it.
-- **Beam-synchronous event-system timing (TIMING-1).** The SwissFEL event system (EVR receivers, e.g. `SLAAR11-LTIM01-EVR0`) gates acquisition at beam rate, the analog of LCLS's EventSequencer. CORA's `TimingController` Family carries the device, but "acquire on event-code N at rate R" has no typed parameter home; today it would be opaque setpoints.
-- **Femtosecond pump-probe synchronization (LASER-1).** The optical pump-probe laser and the FEL are two synchronized timing domains; the `eco` `lxt` timing chain holds them together and the PALM / PSEN arrival-time monitors correct the residual jitter. CORA's `PartitionRule` is single-domain spatial math; a cross-timing-domain synchronization is a relationship it cannot express. The laser device itself folds (catalog `Laser`); the sync is the gap, and Alvra is the second XFEL to expose it (LCLS-MFX's TimeTool is the same role as Alvra's PSEN).
-- **One switched Aramis source feeding co-equal stations (TOPO-1).** One linac and Aramis undulator line serve the Alvra, Bernina, and Cristallina stations, beam routed one at a time. CORA models each beamline as a root Unit owning its source; a shared, switched source feeding co-equal Units has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model. This is the same gap LCLS-MFX's shared-linac topology exposed.
-- **Attenuator transmission solver (ATT-1).** The `eco` `AttenuatorAramis` driver solves a foil combination for a requested transmission, energy-dependent. CORA's `Filter` covers the discrete selection; the solve is the deferred `Attenuable` + `SolverReference` leg. With both LCLS-MFX and Alvra carrying the same energy-dependent attenuator solve, the rule-of-three for this leg is well past its trigger.
-
-## What is deliberately not here yet (modelling, as at the other exercises)
-
-- **New Capabilities / Methods and vendor Models.** Alvra earns no catalog change; the XFEL recipes are carried pending on the [PSI Practices](../psi/index.md), reusing the pending LCLS-MFX Methods. No catalog Model is bound.
-- **Sample delivery and the Subject custody thread.** The fixed-target / liquid-jet delivery on the Prime sample stage is endstation-specific and deferred (SAMPLE-1); no Family is coined, mirroring how LCLS-MFX carries its liquid jet.
-- **The eco cross-line references (XREF-1).** Several Alvra `eco` drivers reference `SAROP21-*` PVs (a sibling Aramis line) for an aperture and an energy readback. Whether that is correct for Alvra or a copy-paste artifact is not determinable from source; carried as an open question, not silently modelled.
-- **Integration scenarios.** No `test_alvra_*.py` registers Alvra Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
diff --git a/docs/deployments/alvra/notes.md b/docs/deployments/alvra/notes.md
new file mode 100644
index 00000000000..5944e843cee
--- /dev/null
+++ b/docs/deployments/alvra/notes.md
@@ -0,0 +1,135 @@
+# Notes
+
+## Techniques
+
+*What Alvra is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
+
+Alvra runs three technique families, none of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They reuse the same pending Methods CORA's first XFEL, [LCLS-MFX](../lcls-mfx/notes.md#techniques), introduced; Alvra is the second deployment to need them, which is part of the point. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
+
+### Femtosecond optical pump-probe
+
+Alvra's reason for existing. An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves the dynamics in time. The PALM (THz-streaking) and PSEN (spectral-encoding) arrival-time monitors correct the residual laser-to-X-ray jitter shot by shot.
+
+- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis on the experiment laser) while acquiring per-shot, with the PSEN / PALM monitors correcting jitter.
+- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `eco` `lxt` timing chain). This is the same gap LCLS-MFX's `lxt_ttc` SyncAxis exposed, now seen at a second XFEL.
+
+### Time-resolved X-ray absorption and emission (XAS / XES / HERFD)
+
+Alvra measures how a sample's electronic structure evolves after the pump: transient X-ray absorption through the incident energy (the double-crystal mono), and X-ray emission through the von Hamos spectrometer. In HERFD mode the incident energy is scanned at a fixed emission line.
+
+- **Spine shape:** an `xas_spectroscopy` Method binding the `Monochromator` for the incident-energy choreography and the `EmissionSpectrometer` for the emitted spectrum, over a per-shot acquisition.
+- **Gap it leans on:** the von Hamos binds the graduated `EmissionSpectrometer` Family (Alvra is a fourth sighting; SPEC-1 now tracks only the analyzer-crystal composition), and the HERFD incident-energy scan reuses the energy-change choreography CORA already models well. The time-resolution makes the acquisition per-shot, which leans on the DAQ gap (DAQ-1).
+
+### Serial femtosecond crystallography (SFX)
+
+On the Prime endstation Alvra also runs time-resolved serial crystallography: a stream of microcrystals is delivered into the focused FEL beam; each pulse records a single-shot diffraction pattern before destroying its crystal. The dataset is many single-shot patterns, indexed and merged downstream.
+
+- **Spine shape:** a `serial_crystallography` Method binding the KB focusing, the sample delivery, the pulse picker, and the Jungfrau detector, over a Run that is a free-running per-shot acquisition rather than a trajectory of points.
+- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). As at LCLS-MFX, this is the technique that most exposes the acquisition-ontology gap: there is no trajectory to walk, only a shot stream to tag and reference.
+
+### Why none is in the catalog yet
+
+The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL pump-probe station shares none of them: there is no rotation, no flat / dark frame pairing, no storage-ring energy ramp. Coining XFEL Methods now, before the acquisition axis they depend on exists, would be inventing recipes for a spine that cannot yet run them. So each is carried pending, reusing the Method name LCLS-MFX named for it, and the deepest dependency (the event-stream acquisition axis, DAQ-1) is sketched as a design note rather than built. That the same three Methods are now needed at a second, independently-built XFEL is the strongest argument yet that they are real Methods to earn, not LCLS-specific. See [Model](#model) for the gap register.
+
+## Governance
+
+*Who would act at Alvra and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
+
+Alvra's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `eco` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Alvra inherits it; what Alvra adds to think about is the same two hazard gates LCLS-MFX raised, now at a second XFEL.
+
+### The pump-probe laser Clearance
+
+Alvra runs a class-4 optical laser for pump-probe. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture LCLS-MFX takes for its pump-probe laser and 32-ID takes for its additive-manufacturing laser. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family (the LCLS-MFX / 4-ID precedent), while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
+
+### The PSS permit
+
+As at every beamline, beam-on work in an enclosure is gated by the facility personnel safety system (PSS). The SwissFEL PSS search-and-secure permit signals are not in the `eco` manifest and are carried pending (PSS-1). Alvra's enclosure structure (a shared Aramis optics hutch plus the Alvra experiment hutch) is itself carried `confirm` because the `eco` PV prefixes encode beamline-line zones (`SARFE10` front end, `SAROP11` optics, `SARES11` endstation), not the access-gated hutch or its safety meaning (ENC-1). The shared optics hutch is the same shared-zone question LCLS-MFX's front-end / transport zone raised, because the Aramis source feeds the Alvra, Bernina, and Cristallina stations (TOPO-1).
+
+### What is not modelled
+
+- **Trust instantiation.** No scenario instantiates Alvra trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `eco` / `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
+
+People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](#open-questions) for the governance items still to confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's Alvra content lives, how the device families fold at a second XFEL, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at Alvra |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The headline: the families fold again, at a second XFEL
+
+[LCLS-MFX](../lcls-mfx/notes.md#model) found that an XFEL's device families fold and its gaps are architectural. Alvra re-runs that test against an independently-built free-electron laser, mined from PSI's `eco` rather than SLAC's `pcdshub`, and reaches the same finding. Of Alvra's full `eco` device set, **none** had no CORA Family: every device reuses an existing one. The offset and KB mirrors fold into `Mirror`, the solid attenuators into `Filter`, the slits into `Slit`, the pulse picker into `Shutter` (PULSE-1), the profile monitors into `Scintillator` + `Camera`, the PBPS / PBIG monitors into `FluxMonitor` + `Diagnostic`, the double-crystal mono into `Monochromator`, the Huber sample stage into `LinearStage`, the optical table into `Table`, the sample microscope and the Jungfrau into `Camera`, and the pump-probe and reference lasers into the catalog `Laser` Family (the LCLS-MFX / 4-ID precedent). The von Hamos spectrometer binds the graduated `EmissionSpectrometer` Family, a **fourth sighting** after LCLS-MFX (which introduced it), NSLS-II ISS (which graduated it), and the MAX IV Balder near-sighting (SPEC-1). Each fold was reviewed against coining a synonym and rejected.
+
+So the device taxonomy generalizes from storage rings to an XFEL almost untouched, and that result is now confirmed at two independent XFELs. What does not generalize is the **acquisition ontology**, the same as at LCLS-MFX. That is the product of this exercise, recorded next.
+
+### Deliberately not here yet (the architectural gap register)
+
+These are the parts of Alvra this scaffold leaves out on purpose. Unlike the open questions (facts the PSI team owns), each is a CORA scope decision: a shape the model does not yet have, with the seam it would extend named. None is built speculatively; an XFEL is the trigger that would justify the work, and Alvra is the second sighting of each gap, strengthening the case that the work is real and not LCLS-specific.
+
+- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The load-bearing gap, re-confirmed. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. SwissFEL's `sf-daq` collects a free-running `bsread` stream of per-shot frames correlated by pulse-ID at beam rate, exactly the shape LCLS's DAQ has. The Run-as-provenance-envelope survives and the per-shot data plane lives in the SwissFEL data API (CORA references a `Dataset`, as it does for reconstructions via `ComputePort`), but representing a DAQ run as an actuation is a new event-stream axis. Its shape is sketched as a forward-looking design note in CORA's design memory (gated, not built); Alvra is the second deployment to need it.
+- **Beam-synchronous event-system timing (TIMING-1).** The SwissFEL event system (EVR receivers, e.g. `SLAAR11-LTIM01-EVR0`) gates acquisition at beam rate, the analog of LCLS's EventSequencer. CORA's `TimingController` Family carries the device, but "acquire on event-code N at rate R" has no typed parameter home; today it would be opaque setpoints.
+- **Femtosecond pump-probe synchronization (LASER-1).** The optical pump-probe laser and the FEL are two synchronized timing domains; the `eco` `lxt` timing chain holds them together and the PALM / PSEN arrival-time monitors correct the residual jitter. CORA's `PartitionRule` is single-domain spatial math; a cross-timing-domain synchronization is a relationship it cannot express. The laser device itself folds (catalog `Laser`); the sync is the gap, and Alvra is the second XFEL to expose it (LCLS-MFX's TimeTool is the same role as Alvra's PSEN).
+- **One switched Aramis source feeding co-equal stations (TOPO-1).** One linac and Aramis undulator line serve the Alvra, Bernina, and Cristallina stations, beam routed one at a time. CORA models each beamline as a root Unit owning its source; a shared, switched source feeding co-equal Units has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model. This is the same gap LCLS-MFX's shared-linac topology exposed.
+- **Attenuator transmission solver (ATT-1).** The `eco` `AttenuatorAramis` driver solves a foil combination for a requested transmission, energy-dependent. CORA's `Filter` covers the discrete selection; the solve is the deferred `Attenuable` + `SolverReference` leg. With both LCLS-MFX and Alvra carrying the same energy-dependent attenuator solve, the rule-of-three for this leg is well past its trigger.
+
+### What is deliberately not here yet (modelling, as at the other exercises)
+
+- **New Capabilities / Methods and vendor Models.** Alvra earns no catalog change; the XFEL recipes are carried pending on the [PSI Practices](../psi/index.md), reusing the pending LCLS-MFX Methods. No catalog Model is bound.
+- **Sample delivery and the Subject custody thread.** The fixed-target / liquid-jet delivery on the Prime sample stage is endstation-specific and deferred (SAMPLE-1); no Family is coined, mirroring how LCLS-MFX carries its liquid jet.
+- **The eco cross-line references (XREF-1).** Several Alvra `eco` drivers reference `SAROP21-*` PVs (a sibling Aramis line) for an aperture and an energy readback. Whether that is correct for Alvra or a copy-paste artifact is not determinable from source; carried as an open question, not silently modelled.
+- **Integration scenarios.** No `test_alvra_*.py` registers Alvra Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
+
+## Open questions
+
+*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
+
+Alvra is modelled from PSI's open [`eco`](https://github.com/paulscherrerinstitute/eco) controls library, treated as a dry, correct DATA source: the Alvra manifest is the `aliases` dict in `eco/alvra/config.py`, and the per-device driver classes derive the motor axes from each PV prefix. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding, none of which is in the manifest. This page collects what `eco` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+As at the LCLS-MFX and Diamond exercises, the EPICS PV prefix for every device is already recorded in the descriptor, so wiring handles is not a question here. The questions concentrate on the XFEL acquisition paradigm and on the few `eco`-specific ambiguities the source itself leaves open.
+
+### Scope, topology, and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is Alvra (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Alvra is CORA's second XFEL, testing whether the XFEL findings generalize across facilities; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
+| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. Should each station be its own root Unit sharing an upstream source, and where does the shared switched source live? | One `Alvra` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
+| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `eco` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
+| ENC-1 | Blocks-build | Which enclosure does each device sit in? `eco` prefixes encode beamline-line zones (`SARFE10`, `SAROP11`, `SARES11` / `SLAAR11`), not the access-gated hutch or its safety meaning. | The shared Aramis optics hutch plus the Alvra experiment hutch. | The per-device Enclosure assignment. |
+
+### Source, optics, and attenuation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the Aramis undulator line parameters and the per-shot photon-energy mechanism? The `eco` manifest carries the downstream device handles, not the source. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
+| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring, so the loose `StorageRing` family used by the synchrotron exercises does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the `FluxMonitor` gas / intensity monitors. | The linac machine-state modelling boundary. |
+| ATT-1 | Blocks-go-live | The `AttenuatorAramis` driver selects a foil combination for a requested transmission (energy-dependent). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With LCLS-MFX carrying the same solve, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
+| MONO-1 | Nice-to-have | The double-crystal mono (ODCM105) is used for monochromatic / spectroscopy modes; Alvra also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCM internals and the pink-vs-mono mode model. |
+| XREF-1 | Blocks-go-live | Several Alvra `eco` drivers reference `SAROP21-*` PVs (a sibling Aramis line): the reference laser hardcodes an aperture on `SAROP21-OLIR134`, and the joint mono+FEL energy device reads `SAROP21-ODCM098:ENERGY`. Is this correct for Alvra, or a copy-paste artifact in the library? | The Alvra-line PVs (`SAROP11-*`) are authoritative; the `SAROP21-*` references are carried `confirm`, not silently modelled. | Whether the cross-line references are real Alvra dependencies. |
+
+### Acquisition and timing (the architectural core)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`, exactly as it does for reconstructions via `ComputePort`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. This is the same gap LCLS-MFX exposed; Alvra is the second sighting. | Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for Alvra. |
+| TIMING-1 | Blocks-go-live | The SwissFEL event system (EVR receivers, e.g. `SLAAR11-LTIM01-EVR0`) gates acquisition at beam rate. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
+| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `eco` `lxt` timing chain) and PALM / PSEN jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (the LCLS-MFX / 4-ID precedent, model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
+
+### Diagnostics, sample, and detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor (PBIG), and the PALM / PSEN arrival-time monitors modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from I22 / 2-BM / LCLS-MFX; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
+| SAMPLE-1 | Blocks-go-live | What is the sample-delivery shape on the Prime endstation (fixed target, liquid jet), and the `Subject` custody lifecycle for serial crystallography? | Sample delivery is endstation-specific and deferred; no Family is coined yet; the `Subject` thread is carried as this question. | The sample-delivery model and the `Subject` custody thread. |
+| SPEC-1 | Nice-to-have | The von Hamos spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector. The Family question is resolved: `EmissionSpectrometer` is in the catalog (Alvra is a fourth sighting). The residual question is whether each analyzer crystal is a child Asset or a setting on the one spectrometer Asset. | The analyzer crystals carried as settings on the one `EmissionSpectrometer` Asset for now; child-Asset-per-crystal deferred. | The analyzer-crystal composition (child-Asset vs setting). |
+| DET-1 | Blocks-go-live | What is the Alvra science detector? `eco` binds a Jungfrau named `JF_4.5M` (the von Hamos 4.5M, serial `JF02T09V03` inferred via `sf_daq_broker`), and the broker lists further Alvra options (16M, 4M, 2M TXS, 0.5M variants). Which is in use, and its threshold / geometry? | The detector reuses `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the model, the active variant, and the calibration are to supply. | The detector model and how its per-shot frames are referenced. |
+| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one LCLS-MFX raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/alvra/questions.md b/docs/deployments/alvra/questions.md
deleted file mode 100644
index 8e27afce808..00000000000
--- a/docs/deployments/alvra/questions.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Open questions
-
-*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
-
-Alvra is modelled from PSI's open [`eco`](https://github.com/paulscherrerinstitute/eco) controls library, treated as a dry, correct DATA source: the Alvra manifest is the `aliases` dict in `eco/alvra/config.py`, and the per-device driver classes derive the motor axes from each PV prefix. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding, none of which is in the manifest. This page collects what `eco` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-As at the LCLS-MFX and Diamond exercises, the EPICS PV prefix for every device is already recorded in the descriptor, so wiring handles is not a question here. The questions concentrate on the XFEL acquisition paradigm and on the few `eco`-specific ambiguities the source itself leaves open.
-
-## Scope, topology, and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is Alvra (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Alvra is CORA's second XFEL, testing whether the XFEL findings generalize across facilities; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
-| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. Should each station be its own root Unit sharing an upstream source, and where does the shared switched source live? | One `Alvra` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
-| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `eco` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
-| ENC-1 | Blocks-build | Which enclosure does each device sit in? `eco` prefixes encode beamline-line zones (`SARFE10`, `SAROP11`, `SARES11` / `SLAAR11`), not the access-gated hutch or its safety meaning. | The shared Aramis optics hutch plus the Alvra experiment hutch. | The per-device Enclosure assignment. |
-
-## Source, optics, and attenuation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the Aramis undulator line parameters and the per-shot photon-energy mechanism? The `eco` manifest carries the downstream device handles, not the source. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
-| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring, so the loose `StorageRing` family used by the synchrotron exercises does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the `FluxMonitor` gas / intensity monitors. | The linac machine-state modelling boundary. |
-| ATT-1 | Blocks-go-live | The `AttenuatorAramis` driver selects a foil combination for a requested transmission (energy-dependent). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With LCLS-MFX carrying the same solve, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
-| MONO-1 | Nice-to-have | The double-crystal mono (ODCM105) is used for monochromatic / spectroscopy modes; Alvra also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCM internals and the pink-vs-mono mode model. |
-| XREF-1 | Blocks-go-live | Several Alvra `eco` drivers reference `SAROP21-*` PVs (a sibling Aramis line): the reference laser hardcodes an aperture on `SAROP21-OLIR134`, and the joint mono+FEL energy device reads `SAROP21-ODCM098:ENERGY`. Is this correct for Alvra, or a copy-paste artifact in the library? | The Alvra-line PVs (`SAROP11-*`) are authoritative; the `SAROP21-*` references are carried `confirm`, not silently modelled. | Whether the cross-line references are real Alvra dependencies. |
-
-## Acquisition and timing (the architectural core)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`, exactly as it does for reconstructions via `ComputePort`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. This is the same gap LCLS-MFX exposed; Alvra is the second sighting. | Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for Alvra. |
-| TIMING-1 | Blocks-go-live | The SwissFEL event system (EVR receivers, e.g. `SLAAR11-LTIM01-EVR0`) gates acquisition at beam rate. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
-| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `eco` `lxt` timing chain) and PALM / PSEN jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (the LCLS-MFX / 4-ID precedent, model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
-
-## Diagnostics, sample, and detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor (PBIG), and the PALM / PSEN arrival-time monitors modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from I22 / 2-BM / LCLS-MFX; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
-| SAMPLE-1 | Blocks-go-live | What is the sample-delivery shape on the Prime endstation (fixed target, liquid jet), and the `Subject` custody lifecycle for serial crystallography? | Sample delivery is endstation-specific and deferred; no Family is coined yet; the `Subject` thread is carried as this question. | The sample-delivery model and the `Subject` custody thread. |
-| SPEC-1 | Nice-to-have | The von Hamos spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector. The Family question is resolved: `EmissionSpectrometer` is in the catalog (Alvra is a fourth sighting). The residual question is whether each analyzer crystal is a child Asset or a setting on the one spectrometer Asset. | The analyzer crystals carried as settings on the one `EmissionSpectrometer` Asset for now; child-Asset-per-crystal deferred. | The analyzer-crystal composition (child-Asset vs setting). |
-| DET-1 | Blocks-go-live | What is the Alvra science detector? `eco` binds a Jungfrau named `JF_4.5M` (the von Hamos 4.5M, serial `JF02T09V03` inferred via `sf_daq_broker`), and the broker lists further Alvra options (16M, 4M, 2M TXS, 0.5M variants). Which is in use, and its threshold / geometry? | The detector reuses `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the model, the active variant, and the calibration are to supply. | The detector model and how its per-shot frames are referenced. |
-| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one LCLS-MFX raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/alvra/techniques.md b/docs/deployments/alvra/techniques.md
deleted file mode 100644
index 02c9d7d7032..00000000000
--- a/docs/deployments/alvra/techniques.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Techniques
-
-*What Alvra is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
-
-Alvra runs three technique families, none of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They reuse the same pending Methods CORA's first XFEL, [LCLS-MFX](../lcls-mfx/techniques.md), introduced; Alvra is the second deployment to need them, which is part of the point. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
-
-## Femtosecond optical pump-probe
-
-Alvra's reason for existing. An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves the dynamics in time. The PALM (THz-streaking) and PSEN (spectral-encoding) arrival-time monitors correct the residual laser-to-X-ray jitter shot by shot.
-
-- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis on the experiment laser) while acquiring per-shot, with the PSEN / PALM monitors correcting jitter.
-- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `eco` `lxt` timing chain). This is the same gap LCLS-MFX's `lxt_ttc` SyncAxis exposed, now seen at a second XFEL.
-
-## Time-resolved X-ray absorption and emission (XAS / XES / HERFD)
-
-Alvra measures how a sample's electronic structure evolves after the pump: transient X-ray absorption through the incident energy (the double-crystal mono), and X-ray emission through the von Hamos spectrometer. In HERFD mode the incident energy is scanned at a fixed emission line.
-
-- **Spine shape:** an `xas_spectroscopy` Method binding the `Monochromator` for the incident-energy choreography and the `EmissionSpectrometer` for the emitted spectrum, over a per-shot acquisition.
-- **Gap it leans on:** the von Hamos binds the graduated `EmissionSpectrometer` Family (Alvra is a fourth sighting; SPEC-1 now tracks only the analyzer-crystal composition), and the HERFD incident-energy scan reuses the energy-change choreography CORA already models well. The time-resolution makes the acquisition per-shot, which leans on the DAQ gap (DAQ-1).
-
-## Serial femtosecond crystallography (SFX)
-
-On the Prime endstation Alvra also runs time-resolved serial crystallography: a stream of microcrystals is delivered into the focused FEL beam; each pulse records a single-shot diffraction pattern before destroying its crystal. The dataset is many single-shot patterns, indexed and merged downstream.
-
-- **Spine shape:** a `serial_crystallography` Method binding the KB focusing, the sample delivery, the pulse picker, and the Jungfrau detector, over a Run that is a free-running per-shot acquisition rather than a trajectory of points.
-- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). As at LCLS-MFX, this is the technique that most exposes the acquisition-ontology gap: there is no trajectory to walk, only a shot stream to tag and reference.
-
-## Why none is in the catalog yet
-
-The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL pump-probe station shares none of them: there is no rotation, no flat / dark frame pairing, no storage-ring energy ramp. Coining XFEL Methods now, before the acquisition axis they depend on exists, would be inventing recipes for a spine that cannot yet run them. So each is carried pending, reusing the Method name LCLS-MFX named for it, and the deepest dependency (the event-stream acquisition axis, DAQ-1) is sketched as a design note rather than built. That the same three Methods are now needed at a second, independently-built XFEL is the strongest argument yet that they are real Methods to earn, not LCLS-specific. See [Model](model.md) for the gap register.
diff --git a/docs/deployments/amx/governance.md b/docs/deployments/amx/governance.md
deleted file mode 100644
index 9c5b674e606..00000000000
--- a/docs/deployments/amx/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at AMX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An AMX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, move the goniometer, start a rotation data collection or a grid scan, drive the robot, override a caution, or commit a beam-centre calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer (the LSDC Governor). The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## The autonomous loop under custody
-
-AMX is "highly automated": its defining governance wrinkle is the unattended EMBL-robot sample-exchange loop. CORA's Campaign, Trust, and Subject shapes are where that resolves: the robot loading a crystal is a command the trust boundary gates, and the crystal is a `Subject` whose custody (Received to mounted-on-goniometer to measured to Returned / Stored) is the record of record. The autonomous loop is gated by a `Clearance` issued after a safety review, the same pattern as i03 and FMX. An autonomous Agent driving the load-centre-collect-unmount cycle would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; the autonomous-loop lifecycle is deferred (ROBOT-1).
diff --git a/docs/deployments/amx/model.md b/docs/deployments/amx/model.md
deleted file mode 100644
index 4a21ab9009b..00000000000
--- a/docs/deployments/amx/model.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's AMX content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at AMX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) (17-ID-A optics, 17-ID-B experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Subject (the crystal custody thread) | [Governance](governance.md#the-autonomous-loop-under-custody) (deferred, ROBOT-1) |
-| Procedure, Recipe, Caution, Supply, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates: nothing (and that is the finding)
-
-AMX is a clean **pure-reuse** deployment, completing the NSLS-II MX pair as FMX's sibling. Its finding is that the MX vocabulary generalizes across a third independent beamline with no new modelling: the graduated `Goniometer` (single-omega micro-goniometer), the `Camera` (Eiger), the `Monochromator` (here vertical), the `Mirror` (tandem-deflection + KB), the `Filter` (BCU attenuator), the `BeamStop`, the `EnergyDispersiveSpectrometer` (Mercury), the `FluxMonitor` (Keithley), the `TimingController` (Zebra), and the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux) all bind unchanged. The robot is one Positioner-presenting Asset, not a new Family (the i03 / 19-BM / FMX precedent).
-
-### FMX-vs-AMX differences
-
-The 17-ID pair is not identical, and the differences exercise the modelling: AMX uses a **vertical** DCM (FMX horizontal), **tandem-deflection** mirrors (FMX a horizontal focusing mirror), an **EMBL** robot, and has **no CRL transfocator** and **no on-axis backlight** in source. Each is a per-Asset settings or device-presence difference, not a Family split; both beamlines bind the same Families.
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring FMX and the other NSLS-II beamlines. Left out on purpose:
-
-- **No catalog change.** AMX graduates nothing and coins nothing. The three MX Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) stay pending: AMX is their third consumer, which strengthens but does not coin them. Methods coin on a **conduct-path** (a deployment that runs them), not on a sighting count, which is why even at n=3 they defer (the `energy_scan` discipline; TECH-1). Coining them is a follow-on that needs an **MX conduct-path scenario** (event-sourced spine work), the genuine MX-graduation path.
-- **The robot is not a Family.** The EMBL sample-changing robot is one Positioner-presenting Asset, gated by a Clearance, loading a `Subject`, vendor in a bound Model; not a new SampleChanger Family (the i03 / 19-BM precedent, ROBOT-1).
-- **The autonomous loop and the Subject custody thread.** The unattended exchange loop is a Procedure over the spine threaded through the `Subject` aggregate; deferred with i03 / FMX (ROBOT-1).
-- **Sample cryo-cooling.** The cold-gas cryostream is not exposed in the profile collection, so it is deferred (CRYO-1); it would bind `TemperatureController` (the i03 cryostream precedent) when its PV is supplied.
-- **The area detector PV.** The Eiger is not exposed in the AMX profile collection; it is carried `Camera` confirm-only (DET-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/amx/notes.md b/docs/deployments/amx/notes.md
new file mode 100644
index 00000000000..d2182f72ec9
--- /dev/null
+++ b/docs/deployments/amx/notes.md
@@ -0,0 +1,112 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at AMX: macromolecular crystallography, each a [Catalog](../../catalog/methods.md) Method. AMX is CORA's third MX beamline (after Diamond i03 and NSLS-II FMX) and follows the same Method-deferral discipline.*
+
+AMX's science is high-throughput protein crystallography: rotate a cryo-cooled crystal in a focused microbeam and read the diffraction on the Eiger, locate crystals with fast grid scans, and exchange samples with an automated robot. These are the MX Methods i03 and FMX brought to CORA; AMX is their third consumer. The Methods below render unlinked and stay pending until a conduct-path coins them (TECH-1).
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Rotation (oscillation) data collection | monochromatic, microfocused | `AreaDetector` (Eiger, Detector Role) | the `mx_data_collection` Method, pending; 3rd consumer (TECH-1) |
+| Grid scan / sample location | monochromatic, microfocused | `AreaDetector` + `SampleCamera` | the `grid_scan` Method over the Zebra-triggered goniometer raster, pending; 3rd consumer (TECH-1) |
+| Autonomous sample exchange | n/a | n/a | the `sample_exchange` Method: a Procedure over the spine + a Subject custody thread, pending; 3rd consumer (ROBOT-1) |
+| Anomalous element ID (fluorescence) | monochromatic, energy-swept | `FluorescenceDetector` (Mercury, Sensor) | the edge scan picks the energy for SAD / MAD; reuses the energy axis (DET-1) |
+
+### Why the Methods stay pending
+
+AMX reuses the three MX Methods i03 and FMX left pending, and is the third consumer of each. This is the moment the consumer count is strongest, so it is worth being precise about why they still do not graduate: unlike a device *Family* (which a second sighting promotes on a mechanical rule-of-three, as ISS did for the emission spectrometer), a *Method* is coined on a **conduct-path**, when a deployment actually runs it (an integration scenario or operational pilot, the way `tomography` and `xpcs` were coined). i03, FMX, and AMX are all descriptor-only scaffolds with no conduct-path, so three consumers strengthen the case but do not coin the Methods, exactly the discipline that keeps `energy_scan` deferred across its consumers. The device Roles already exist (the graduated `Goniometer` presents Positioner, the Eiger presents Detector); what is pending is the recipe.
+
+The genuine MX graduation, coining these Methods, is a follow-on that needs an MX conduct-path scenario (the event-sourced spine work), not another descriptor scaffold. The autonomous sample-exchange loop is the non-obvious modelling: an unattended Procedure over the spine, threaded through the `Subject` custody lifecycle and gated by a Clearance (ROBOT-1).
+
+## Governance
+
+*Who may act at AMX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An AMX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, move the goniometer, start a rotation data collection or a grid scan, drive the robot, override a caution, or commit a beam-centre calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer (the LSDC Governor). The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### The autonomous loop under custody
+
+AMX is "highly automated": its defining governance wrinkle is the unattended EMBL-robot sample-exchange loop. CORA's Campaign, Trust, and Subject shapes are where that resolves: the robot loading a crystal is a command the trust boundary gates, and the crystal is a `Subject` whose custody (Received to mounted-on-goniometer to measured to Returned / Stored) is the record of record. The autonomous loop is gated by a `Clearance` issued after a safety review, the same pattern as i03 and FMX. An autonomous Agent driving the load-centre-collect-unmount cycle would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; the autonomous-loop lifecycle is deferred (ROBOT-1).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's AMX content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at AMX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) (17-ID-A optics, 17-ID-B experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Subject (the crystal custody thread) | [Governance](#the-autonomous-loop-under-custody) (deferred, ROBOT-1) |
+| Procedure, Recipe, Caution, Supply, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates: nothing (and that is the finding)
+
+AMX is a clean **pure-reuse** deployment, completing the NSLS-II MX pair as FMX's sibling. Its finding is that the MX vocabulary generalizes across a third independent beamline with no new modelling: the graduated `Goniometer` (single-omega micro-goniometer), the `Camera` (Eiger), the `Monochromator` (here vertical), the `Mirror` (tandem-deflection + KB), the `Filter` (BCU attenuator), the `BeamStop`, the `EnergyDispersiveSpectrometer` (Mercury), the `FluxMonitor` (Keithley), the `TimingController` (Zebra), and the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux) all bind unchanged. The robot is one Positioner-presenting Asset, not a new Family (the i03 / 19-BM / FMX precedent).
+
+#### FMX-vs-AMX differences
+
+The 17-ID pair is not identical, and the differences exercise the modelling: AMX uses a **vertical** DCM (FMX horizontal), **tandem-deflection** mirrors (FMX a horizontal focusing mirror), an **EMBL** robot, and has **no CRL transfocator** and **no on-axis backlight** in source. Each is a per-Asset settings or device-presence difference, not a Family split; both beamlines bind the same Families.
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring FMX and the other NSLS-II beamlines. Left out on purpose:
+
+- **No catalog change.** AMX graduates nothing and coins nothing. The three MX Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) stay pending: AMX is their third consumer, which strengthens but does not coin them. Methods coin on a **conduct-path** (a deployment that runs them), not on a sighting count, which is why even at n=3 they defer (the `energy_scan` discipline; TECH-1). Coining them is a follow-on that needs an **MX conduct-path scenario** (event-sourced spine work), the genuine MX-graduation path.
+- **The robot is not a Family.** The EMBL sample-changing robot is one Positioner-presenting Asset, gated by a Clearance, loading a `Subject`, vendor in a bound Model; not a new SampleChanger Family (the i03 / 19-BM precedent, ROBOT-1).
+- **The autonomous loop and the Subject custody thread.** The unattended exchange loop is a Procedure over the spine threaded through the `Subject` aggregate; deferred with i03 / FMX (ROBOT-1).
+- **Sample cryo-cooling.** The cold-gas cryostream is not exposed in the profile collection, so it is deferred (CRYO-1); it would bind `TemperatureController` (the i03 cryostream precedent) when its PV is supplied.
+- **The area detector PV.** The Eiger is not exposed in the AMX profile collection; it is carried `Camera` confirm-only (DET-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the AMX team to confirm. This model is reverse-engineered from public open source (the `NSLS2/amx-profile-collection` bluesky / ophyd startup files; the MX acquisition logic lives in the `lsdc` / `mxtools` libraries): the EPICS PVs are read from the `startup/*.py` device classes, but the goniometer / robot / detector vendor identities, the crystal cut, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The IVU21 undulator period, gap range, and gap-to-energy curve. The device (`SR:C17-ID:G1{IVU21:1}`) is in source; the parameters are not. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
+| TOPO-1 | Nice-to-have | AMX (17-ID-1) shares the IVU21 undulator and the 17-ID straight with FMX (17-ID-2, which uses IVU21:2). Is the straight canted (two beams), and is one root Unit per branch the right model? | One root Unit feeding the 17-ID-1 branch (the FMX / CSX canted precedent); FMX is the sibling branch. | The sector topology and the FMX relationship. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the front-end / photon shutter PVs (not in the profile collection; the front end is shared with FMX). | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The vertical DCM crystal cut, d-spacing, and energy range. The monochromator (`Mono:DCM`) and its axes are in source. | One Monochromator Asset, crystal settings blank. | The Monochromator settings. |
+| KB-1 | Nice-to-have | The tandem-deflection and KB mirror coatings and calibration. The mirrors (`Mir:TDM`, `Mir:KBH/KBV`) are in source. | The mirror internals are per-Asset settings on the existing Mirror Family. | The focusing-optic settings. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The goniometer axis decomposition (single omega + GX / GY / GZ centring + PY / PZ pin fine) and the centre-of-rotation calibration. The stack (`Gon:1`) is in source. | A `Goniometer` Asset (catalog Family, graduated on the i03 Smargon); per-axis decomposition to confirm. | The goniometer model. |
+| ROBOT-1 | Blocks-go-live | The EMBL sample-changing robot model, the dewar / puck layout, the exchange workflow, and the Subject custody lifecycle. The robot (`EMBL`) and Governor are in source. | One Positioner-presenting `Robot` Asset (not a new Family); the autonomous loop is a Procedure + a Subject custody thread, gated by a Clearance. | The robot model and the autonomous-loop modelling. |
+| DET-1 | Blocks-go-live | The Eiger model and beam centre (not exposed in the profile collection), and the Mercury fluorescence detector element count and ROI map. | An Eiger (`Camera`, PV pending) and a Mercury (`EnergyDispersiveSpectrometer`); model / ROIs to confirm. | The detector roster. |
+| DIAG-1 | Nice-to-have | The beam-position channel map (the four-quadrant BPMs); the `PositionMonitor` Family is graduated (catalog, presenting `Sensor`), only the per-Asset channel map stays pending. | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The BeamPositionMonitor bindings. |
+| CRYO-1 | Nice-to-have | The sample cryo-cooling (cold-gas cryostream), not exposed in the profile collection. | Sample cooling deferred; a `TemperatureController` when its PV is supplied. | The sample-environment Assets. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the goniometer vector controller is a PowerBrick; the profile's vector PV is misconfigured to the FMX prefix). | Family bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the MX Methods (rotation `mx_data_collection`, `grid_scan`, `sample_exchange`) enter CORA's catalog, or stay pending? AMX is the third consumer (after i03, FMX). | The three Methods reused pending; coining awaits a conduct-path (an MX integration scenario), not the sighting count (the energy_scan discipline). | The MX Method scope. |
diff --git a/docs/deployments/amx/questions.md b/docs/deployments/amx/questions.md
deleted file mode 100644
index 0c918d6848c..00000000000
--- a/docs/deployments/amx/questions.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Open questions
-
-*What CORA needs the AMX team to confirm. This model is reverse-engineered from public open source (the `NSLS2/amx-profile-collection` bluesky / ophyd startup files; the MX acquisition logic lives in the `lsdc` / `mxtools` libraries): the EPICS PVs are read from the `startup/*.py` device classes, but the goniometer / robot / detector vendor identities, the crystal cut, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The IVU21 undulator period, gap range, and gap-to-energy curve. The device (`SR:C17-ID:G1{IVU21:1}`) is in source; the parameters are not. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
-| TOPO-1 | Nice-to-have | AMX (17-ID-1) shares the IVU21 undulator and the 17-ID straight with FMX (17-ID-2, which uses IVU21:2). Is the straight canted (two beams), and is one root Unit per branch the right model? | One root Unit feeding the 17-ID-1 branch (the FMX / CSX canted precedent); FMX is the sibling branch. | The sector topology and the FMX relationship. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the front-end / photon shutter PVs (not in the profile collection; the front end is shared with FMX). | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The vertical DCM crystal cut, d-spacing, and energy range. The monochromator (`Mono:DCM`) and its axes are in source. | One Monochromator Asset, crystal settings blank. | The Monochromator settings. |
-| KB-1 | Nice-to-have | The tandem-deflection and KB mirror coatings and calibration. The mirrors (`Mir:TDM`, `Mir:KBH/KBV`) are in source. | The mirror internals are per-Asset settings on the existing Mirror Family. | The focusing-optic settings. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The goniometer axis decomposition (single omega + GX / GY / GZ centring + PY / PZ pin fine) and the centre-of-rotation calibration. The stack (`Gon:1`) is in source. | A `Goniometer` Asset (catalog Family, graduated on the i03 Smargon); per-axis decomposition to confirm. | The goniometer model. |
-| ROBOT-1 | Blocks-go-live | The EMBL sample-changing robot model, the dewar / puck layout, the exchange workflow, and the Subject custody lifecycle. The robot (`EMBL`) and Governor are in source. | One Positioner-presenting `Robot` Asset (not a new Family); the autonomous loop is a Procedure + a Subject custody thread, gated by a Clearance. | The robot model and the autonomous-loop modelling. |
-| DET-1 | Blocks-go-live | The Eiger model and beam centre (not exposed in the profile collection), and the Mercury fluorescence detector element count and ROI map. | An Eiger (`Camera`, PV pending) and a Mercury (`EnergyDispersiveSpectrometer`); model / ROIs to confirm. | The detector roster. |
-| DIAG-1 | Nice-to-have | The beam-position channel map (the four-quadrant BPMs); the `PositionMonitor` Family is graduated (catalog, presenting `Sensor`), only the per-Asset channel map stays pending. | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The BeamPositionMonitor bindings. |
-| CRYO-1 | Nice-to-have | The sample cryo-cooling (cold-gas cryostream), not exposed in the profile collection. | Sample cooling deferred; a `TemperatureController` when its PV is supplied. | The sample-environment Assets. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the goniometer vector controller is a PowerBrick; the profile's vector PV is misconfigured to the FMX prefix). | Family bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the MX Methods (rotation `mx_data_collection`, `grid_scan`, `sample_exchange`) enter CORA's catalog, or stay pending? AMX is the third consumer (after i03, FMX). | The three Methods reused pending; coining awaits a conduct-path (an MX integration scenario), not the sighting count (the energy_scan discipline). | The MX Method scope. |
diff --git a/docs/deployments/amx/techniques.md b/docs/deployments/amx/techniques.md
deleted file mode 100644
index f33f6462598..00000000000
--- a/docs/deployments/amx/techniques.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Techniques
-
-*What CORA would run at AMX: macromolecular crystallography, each a [Catalog](../../catalog/methods.md) Method. AMX is CORA's third MX beamline (after Diamond i03 and NSLS-II FMX) and follows the same Method-deferral discipline.*
-
-AMX's science is high-throughput protein crystallography: rotate a cryo-cooled crystal in a focused microbeam and read the diffraction on the Eiger, locate crystals with fast grid scans, and exchange samples with an automated robot. These are the MX Methods i03 and FMX brought to CORA; AMX is their third consumer. The Methods below render unlinked and stay pending until a conduct-path coins them (TECH-1).
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Rotation (oscillation) data collection | monochromatic, microfocused | `AreaDetector` (Eiger, Detector Role) | the `mx_data_collection` Method, pending; 3rd consumer (TECH-1) |
-| Grid scan / sample location | monochromatic, microfocused | `AreaDetector` + `SampleCamera` | the `grid_scan` Method over the Zebra-triggered goniometer raster, pending; 3rd consumer (TECH-1) |
-| Autonomous sample exchange | n/a | n/a | the `sample_exchange` Method: a Procedure over the spine + a Subject custody thread, pending; 3rd consumer (ROBOT-1) |
-| Anomalous element ID (fluorescence) | monochromatic, energy-swept | `FluorescenceDetector` (Mercury, Sensor) | the edge scan picks the energy for SAD / MAD; reuses the energy axis (DET-1) |
-
-## Why the Methods stay pending
-
-AMX reuses the three MX Methods i03 and FMX left pending, and is the third consumer of each. This is the moment the consumer count is strongest, so it is worth being precise about why they still do not graduate: unlike a device *Family* (which a second sighting promotes on a mechanical rule-of-three, as ISS did for the emission spectrometer), a *Method* is coined on a **conduct-path**, when a deployment actually runs it (an integration scenario or operational pilot, the way `tomography` and `xpcs` were coined). i03, FMX, and AMX are all descriptor-only scaffolds with no conduct-path, so three consumers strengthen the case but do not coin the Methods, exactly the discipline that keeps `energy_scan` deferred across its consumers. The device Roles already exist (the graduated `Goniometer` presents Positioner, the Eiger presents Detector); what is pending is the recipe.
-
-The genuine MX graduation, coining these Methods, is a follow-on that needs an MX conduct-path scenario (the event-sourced spine work), not another descriptor scaffold. The autonomous sample-exchange loop is the non-obvious modelling: an unattended Procedure over the spine, threaded through the `Subject` custody lifecycle and gated by a Clearance (ROBOT-1).
diff --git a/docs/deployments/bernina/governance.md b/docs/deployments/bernina/governance.md
deleted file mode 100644
index e195c2a5e54..00000000000
--- a/docs/deployments/bernina/governance.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Governance
-
-*Who would act at Bernina and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
-
-Bernina's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `eco` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Bernina inherits it. Bernina shares its Site, its Aramis source, and its safety posture with the sibling [Alvra](../alvra/governance.md) station, so most of the governance shape is the PSI-Site shape already described there; what is worth drawing out is the shared-source boundary and the laser Clearance.
-
-## The shared Aramis source and the optics zone
-
-Bernina is one of three co-equal stations (with Alvra and Cristallina) on one Aramis source, beam routed to one at a time (TOPO-1). The `SAROP21` optics hutch conditions the beam on the way to Bernina, but the source upstream of it is shared. That makes the optics-hutch Zone a shared-access boundary, the same question Alvra's optics hutch and LCLS-MFX's front-end / transport zone raise: who holds the permit when the beam is routed to a neighbour, and how the routing state gates each station's commands. The SwissFEL PSS search-and-secure permit signals are not in the `eco` manifest and are carried pending (PSS-1). Bernina's enclosure structure (the shared `SAROP21` optics hutch plus the Bernina experiment hutch) is carried `confirm` because the `eco` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
-
-## The pump-probe laser Clearance
-
-Bernina runs a class-4 optical laser for pump-probe. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture Alvra, LCLS-MFX, and 32-ID take. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family, while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
-
-## What is not modelled
-
-- **Trust instantiation.** No scenario instantiates Bernina trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-- **The Staeubli sample / detector robot as a principal or driven Asset.** The robot runs over PShell (HTTP), not EPICS, and its modelling is deferred (ROBOT-1); when it is modelled, whether an autonomous sample-handling Agent acts through it is part of that work.
-- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `eco` / `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
-
-People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](questions.md) for the governance items still to confirm.
diff --git a/docs/deployments/bernina/model.md b/docs/deployments/bernina/model.md
deleted file mode 100644
index e3cd665d52e..00000000000
--- a/docs/deployments/bernina/model.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's Bernina content lives, how the diffraction platform composes as an Assembly rather than a Family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at Bernina |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The headline: the diffraction platform is an Assembly, not a Family
-
-Bernina's defining endstation is two reconfigurable diffraction platforms: GPS (`SARES22-GPS`, a six-circle station) and XRD (`SARES21-XRD`, a You-geometry station). The `eco` driver `bernina_diffractometers.py` builds, from literal PV suffixes, a base (gamma / mu plus translations and tilts), a 2-theta detector arm (delta / detector translation), a polarization-analyzer branch (pol / pthe / ptth), a kappa goniometer (with on-the-fly kappa-to-Eulerian eta / chi / phi conversion), a heavy-load goniometer table, and a PI hexapod, with an optional Staeubli robot contributing gamma / delta.
-
-That is far more than the catalog `Goniometer`, the integrated single-device sample orienter that [I03](../i03/model.md) graduated and [MX3](../mx3/model.md) reused. But it is **exactly the graduated `Diffractometer` Assembly** that 4-ID and 8-ID earned: a composed scattering instrument that
-
-- binds **one `Goniometer`** for the sample-orientation circles plus x / y / z centring,
-- binds **zero or more `RotaryStage`** detector-arm circles (here the `delta` 2-theta arm), and
-- binds **one reciprocal-space `PseudoAxis`** whose partition rule resolves the inverse kinematics (here the `SixCircleBernina` and kappa-to-You conversions).
-
-So Bernina coins **no new Family and adds no new Assembly**. Each platform is modelled as a `Goniometer` Asset + a `PseudoAxis` Asset (and, for XRD, a `RotaryStage` detector-arm Asset), composed through the existing `Diffractometer` Assembly. The GPS and XRD platforms are its third and fourth bindings, reinforcing the 4-ID / 8-ID graduation from a third facility and, for the first time, at an XFEL (DIFF-1). The reciprocal-space partition rule (the hkl inverse kinematics, and the kappa-to-Eulerian conversion XRD adds) is the same `PartitionRule` design the synchrotron diffractometers carry, deferred here as DIFF-2.
-
-## Deliberately not here yet: the externalized configuration (CONFIG-1)
-
-This is the boundary that makes Bernina a partial first cut, and it is a different boundary from i13-1's. At i13-1 the upstream source was simply absent from the public module. At Bernina the device **list** and the diffractometer **axis topology** are public (in `bernina.py` and `bernina_diffractometers.py`), but the **configuration state** is loaded at runtime from non-public PSI files:
-
-- `eco/bernina/config.py`'s entire `components` device list is commented out and `extend`-ed from `/sf/bernina/config/eco/bernina_config_eco.json` (not in the repo).
-- `bernina.py` reads `/sf/bernina/config/eco/configuration/bernina_config.json` for the per-diffractometer flags that decide **which sub-assemblies are mounted** (base / arm / polana / kappa / heavy-load / hexapod / robot) and **which detectors attach to each diffractometer**.
-
-So CORA can model the platforms' shape but not their current instantiation: the inventory carries the recoverable devices, and the mount state and detector wiring are carried unknown, not guessed (CONFIG-1). This is the honest scope line, and it is recorded so a later cut (or a staff confirmation) can fill it without re-deriving the topology.
-
-## The architectural gap register (shared with the other XFELs)
-
-These are the same deferrals Alvra and LCLS-MFX recorded; Bernina re-confirms them on a diffraction platform rather than a spectroscopy one, which is itself the point (the gaps are about acquisition, not technique).
-
-- **One switched Aramis source feeding co-equal stations (TOPO-1).** Now concrete: Bernina is the second root Unit on the same source as Alvra. Two co-equal Units sharing one upstream source has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model.
-- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The `sf-daq` records a free-running `bsread` stream of per-shot frames correlated by pulse-ID; CORA's poll-to-Done acquisition has no representation for it. The Run stays the provenance envelope and the per-shot plane is a referenced `Dataset`.
-- **Beam-synchronous event-system timing (TIMING-1).** The SwissFEL master timing, CTA sequencer, and EVR receivers gate acquisition at beam rate; `TimingController` carries the device but the trigger pattern has no typed home.
-- **Femtosecond pump-probe synchronization (LASER-1).** The `eco` `lxt` timing chain and the PSEN arrival-time monitor hold and correct the laser-to-X-ray delay; CORA's single-domain `PartitionRule` cannot express the cross-timing-domain sync. The laser folds (catalog `Laser`); the sync is the gap.
-
-## What is deliberately not here yet (modelling, as at the other exercises)
-
-- **New Capabilities / Methods and vendor Models.** Bernina earns no catalog change; the pump-probe and diffraction recipes are carried pending on the [PSI Practices](../psi/index.md). No catalog Model is bound.
-- **The Staeubli TX200 robot (ROBOT-1).** The sample / detector handling robot runs over PShell (HTTP), not EPICS, and its modelling is deferred, the same posture I03 and MX3 take for their sample-exchange arms.
-- **The RIXS / tape-drive / liquid-jet sample environments (ENV-1).** `eco` defines these but their appends are commented out, so they are not in the live module; deferred, not invented.
-- **The eco cross-line reference (XREF-1).** A live Bernina profile monitor (`prof_mirr_alv1`) carries an Alvra-line PV (`SAROP11-PPRM066`); whether that is a real shared device or a copy-paste residue is carried as an open question.
-- **Integration scenarios.** No `test_bernina_*.py` registers Bernina Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
diff --git a/docs/deployments/bernina/notes.md b/docs/deployments/bernina/notes.md
new file mode 100644
index 00000000000..254828d650f
--- /dev/null
+++ b/docs/deployments/bernina/notes.md
@@ -0,0 +1,148 @@
+# Notes
+
+## Techniques
+
+*What Bernina is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
+
+Bernina runs two technique families, neither of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
+
+### Femtosecond optical pump-probe
+
+The shared SwissFEL technique, the same one [Alvra](../alvra/notes.md#techniques) and [LCLS-MFX](../lcls-mfx/notes.md#techniques) run. An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves the dynamics in time. The PSEN spectral-encoding arrival-time monitor corrects the residual laser-to-X-ray jitter shot by shot.
+
+- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis on the experiment laser) while acquiring per-shot, with the PSEN monitor correcting jitter.
+- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `eco` `lxt` timing chain). Bernina is the third deployment to reach this gap (after LCLS-MFX and Alvra).
+
+### Time-resolved hard X-ray diffraction and scattering
+
+Bernina's reason for existing, and what distinguishes it from Alvra. After the pump, the sample's structural response is read by diffraction: Bragg peaks and diffuse scattering recorded shot by shot on the area detector, as a function of pump-probe delay. The sample is oriented and the detector positioned by the GPS six-circle or XRD You-geometry diffractometer.
+
+- **Spine shape:** a `diffraction` Method binding the diffractometer (a `Goniometer` for the sample circles, a `RotaryStage` 2-theta detector arm, and a reciprocal-space `PseudoAxis`), composed through the graduated `Diffractometer` Assembly (DIFF-1), over a per-shot acquisition. The reciprocal-space layer resolves the hkl inverse kinematics, and for the XRD platform the kappa-to-Eulerian conversion (DIFF-2).
+- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). A time-resolved diffraction run is a free-running shot stream tagged by pulse-ID and delay, not a trajectory of points the spine walks. The diffractometer itself is fully covered by the existing Assembly; the acquisition is the gap.
+
+### Why neither is in the catalog yet
+
+The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL diffraction station shares none of them: there is no rotation tomography, no flat / dark frame pairing, no storage-ring energy ramp. The `diffraction` Method is genuinely new for the fleet (the synchrotron diffractometers at 4-ID and 8-ID carry their own pending Methods), and coining it now, before the per-shot acquisition axis it depends on exists (DAQ-1), would be inventing a recipe for a spine that cannot yet run it. So it is carried pending. That a diffraction technique reaches the **same** acquisition gaps a spectroscopy technique (Alvra) and a crystallography technique (LCLS-MFX) reached is the reinforcement Bernina adds: the gaps are about the XFEL acquisition paradigm, not about any one technique. See [Model](#model) for the gap register and the `Diffractometer` Assembly design.
+
+## Governance
+
+*Who would act at Bernina and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
+
+Bernina's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `eco` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Bernina inherits it. Bernina shares its Site, its Aramis source, and its safety posture with the sibling [Alvra](../alvra/notes.md#governance) station, so most of the governance shape is the PSI-Site shape already described there; what is worth drawing out is the shared-source boundary and the laser Clearance.
+
+### The shared Aramis source and the optics zone
+
+Bernina is one of three co-equal stations (with Alvra and Cristallina) on one Aramis source, beam routed to one at a time (TOPO-1). The `SAROP21` optics hutch conditions the beam on the way to Bernina, but the source upstream of it is shared. That makes the optics-hutch Zone a shared-access boundary, the same question Alvra's optics hutch and LCLS-MFX's front-end / transport zone raise: who holds the permit when the beam is routed to a neighbour, and how the routing state gates each station's commands. The SwissFEL PSS search-and-secure permit signals are not in the `eco` manifest and are carried pending (PSS-1). Bernina's enclosure structure (the shared `SAROP21` optics hutch plus the Bernina experiment hutch) is carried `confirm` because the `eco` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
+
+### The pump-probe laser Clearance
+
+Bernina runs a class-4 optical laser for pump-probe. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture Alvra, LCLS-MFX, and 32-ID take. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family, while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
+
+### What is not modelled
+
+- **Trust instantiation.** No scenario instantiates Bernina trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+- **The Staeubli sample / detector robot as a principal or driven Asset.** The robot runs over PShell (HTTP), not EPICS, and its modelling is deferred (ROBOT-1); when it is modelled, whether an autonomous sample-handling Agent acts through it is part of that work.
+- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `eco` / `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
+
+People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](#open-questions) for the governance items still to confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's Bernina content lives, how the diffraction platform composes as an Assembly rather than a Family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at Bernina |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The headline: the diffraction platform is an Assembly, not a Family
+
+Bernina's defining endstation is two reconfigurable diffraction platforms: GPS (`SARES22-GPS`, a six-circle station) and XRD (`SARES21-XRD`, a You-geometry station). The `eco` driver `bernina_diffractometers.py` builds, from literal PV suffixes, a base (gamma / mu plus translations and tilts), a 2-theta detector arm (delta / detector translation), a polarization-analyzer branch (pol / pthe / ptth), a kappa goniometer (with on-the-fly kappa-to-Eulerian eta / chi / phi conversion), a heavy-load goniometer table, and a PI hexapod, with an optional Staeubli robot contributing gamma / delta.
+
+That is far more than the catalog `Goniometer`, the integrated single-device sample orienter that [I03](../i03/notes.md#model) graduated and [MX3](../mx3/notes.md#model) reused. But it is **exactly the graduated `Diffractometer` Assembly** that 4-ID and 8-ID earned: a composed scattering instrument that
+
+- binds **one `Goniometer`** for the sample-orientation circles plus x / y / z centring,
+- binds **zero or more `RotaryStage`** detector-arm circles (here the `delta` 2-theta arm), and
+- binds **one reciprocal-space `PseudoAxis`** whose partition rule resolves the inverse kinematics (here the `SixCircleBernina` and kappa-to-You conversions).
+
+So Bernina coins **no new Family and adds no new Assembly**. Each platform is modelled as a `Goniometer` Asset + a `PseudoAxis` Asset (and, for XRD, a `RotaryStage` detector-arm Asset), composed through the existing `Diffractometer` Assembly. The GPS and XRD platforms are its third and fourth bindings, reinforcing the 4-ID / 8-ID graduation from a third facility and, for the first time, at an XFEL (DIFF-1). The reciprocal-space partition rule (the hkl inverse kinematics, and the kappa-to-Eulerian conversion XRD adds) is the same `PartitionRule` design the synchrotron diffractometers carry, deferred here as DIFF-2.
+
+### Deliberately not here yet: the externalized configuration (CONFIG-1)
+
+This is the boundary that makes Bernina a partial first cut, and it is a different boundary from i13-1's. At i13-1 the upstream source was simply absent from the public module. At Bernina the device **list** and the diffractometer **axis topology** are public (in `bernina.py` and `bernina_diffractometers.py`), but the **configuration state** is loaded at runtime from non-public PSI files:
+
+- `eco/bernina/config.py`'s entire `components` device list is commented out and `extend`-ed from `/sf/bernina/config/eco/bernina_config_eco.json` (not in the repo).
+- `bernina.py` reads `/sf/bernina/config/eco/configuration/bernina_config.json` for the per-diffractometer flags that decide **which sub-assemblies are mounted** (base / arm / polana / kappa / heavy-load / hexapod / robot) and **which detectors attach to each diffractometer**.
+
+So CORA can model the platforms' shape but not their current instantiation: the inventory carries the recoverable devices, and the mount state and detector wiring are carried unknown, not guessed (CONFIG-1). This is the honest scope line, and it is recorded so a later cut (or a staff confirmation) can fill it without re-deriving the topology.
+
+### The architectural gap register (shared with the other XFELs)
+
+These are the same deferrals Alvra and LCLS-MFX recorded; Bernina re-confirms them on a diffraction platform rather than a spectroscopy one, which is itself the point (the gaps are about acquisition, not technique).
+
+- **One switched Aramis source feeding co-equal stations (TOPO-1).** Now concrete: Bernina is the second root Unit on the same source as Alvra. Two co-equal Units sharing one upstream source has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model.
+- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The `sf-daq` records a free-running `bsread` stream of per-shot frames correlated by pulse-ID; CORA's poll-to-Done acquisition has no representation for it. The Run stays the provenance envelope and the per-shot plane is a referenced `Dataset`.
+- **Beam-synchronous event-system timing (TIMING-1).** The SwissFEL master timing, CTA sequencer, and EVR receivers gate acquisition at beam rate; `TimingController` carries the device but the trigger pattern has no typed home.
+- **Femtosecond pump-probe synchronization (LASER-1).** The `eco` `lxt` timing chain and the PSEN arrival-time monitor hold and correct the laser-to-X-ray delay; CORA's single-domain `PartitionRule` cannot express the cross-timing-domain sync. The laser folds (catalog `Laser`); the sync is the gap.
+
+### What is deliberately not here yet (modelling, as at the other exercises)
+
+- **New Capabilities / Methods and vendor Models.** Bernina earns no catalog change; the pump-probe and diffraction recipes are carried pending on the [PSI Practices](../psi/index.md). No catalog Model is bound.
+- **The Staeubli TX200 robot (ROBOT-1).** The sample / detector handling robot runs over PShell (HTTP), not EPICS, and its modelling is deferred, the same posture I03 and MX3 take for their sample-exchange arms.
+- **The RIXS / tape-drive / liquid-jet sample environments (ENV-1).** `eco` defines these but their appends are commented out, so they are not in the live module; deferred, not invented.
+- **The eco cross-line reference (XREF-1).** A live Bernina profile monitor (`prof_mirr_alv1`) carries an Alvra-line PV (`SAROP11-PPRM066`); whether that is a real shared device or a copy-paste residue is carried as an open question.
+- **Integration scenarios.** No `test_bernina_*.py` registers Bernina Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
+
+## Open questions
+
+*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
+
+Bernina is modelled from PSI's open [`eco`](https://github.com/paulscherrerinstitute/eco) controls library, treated as a dry, correct DATA source: the device list with PV prefixes comes from the live `eco/bernina/bernina.py`, and the diffractometer motor-axis topology from `eco/endstations/bernina_diffractometers.py`. That gives the device shape and the EPICS PV prefixes at high confidence. It does not give the configuration state, the motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding. This page collects what `eco` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+The defining Bernina question is **CONFIG-1**: unlike Alvra, Bernina's live device list and per-diffractometer configuration are loaded from non-public PSI files, so this is a deliberately partial first cut.
+
+### Scope, configuration, topology, and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is Bernina (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Bernina extends the PSI / XFEL exercise to a second station on the shared source and to a diffraction platform; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
+| CONFIG-1 | Blocks-build | `eco` loads Bernina's authoritative device list from `/sf/bernina/config/eco/bernina_config_eco.json` and the per-diffractometer configuration (which of base / arm / polana / kappa / heavy-load / hexapod / robot sub-assemblies are mounted, and which detector attaches to each) from `/sf/bernina/config/eco/configuration/bernina_config.json`, neither in the public repo. What is the current configuration? | The device list and diffractometer axis topology are taken from the public inline source; the mount state and detector wiring are carried unknown, not invented. | The full device list and the per-diffractometer mount + detector state. |
+| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. Should each station be its own root Unit sharing an upstream source, and where does the shared switched source live? Bernina is the second such station, so this is now concrete, not hypothetical. | One `Bernina` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
+| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `eco` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
+| ENC-1 | Blocks-build | Which enclosure does each device sit in? `eco` prefixes encode beamline-line zones (`SARFE10`, `SAROP21`, `SARES2x` / `SLAAR21`), not the access-gated hutch or its safety meaning. | The shared `SAROP21` optics hutch plus the Bernina experiment hutch. | The per-device Enclosure assignment. |
+
+### Source, optics, and attenuation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the Aramis undulator line parameters and the per-shot photon-energy mechanism? The `eco` manifest carries the downstream device handles, not the source. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
+| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring, so the loose `StorageRing` family does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the `FluxMonitor` gas / intensity monitors. | The linac machine-state modelling boundary. |
+| ATT-1 | Blocks-go-live | The `AttenuatorAramis` driver selects a foil combination for a requested transmission (energy-dependent). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With LCLS-MFX and Alvra carrying the same solve, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
+| MONO-1 | Nice-to-have | The double-crystal mono (ODCM098) is used for monochromatic modes; Bernina also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCM internals and the pink-vs-mono mode model. |
+| XREF-1 | Blocks-go-live | A live Bernina profile monitor (`prof_mirr_alv1`) carries an Alvra-line PV (`SAROP11-PPRM066`). Is this a real shared device, or a copy-paste residue in the library? | The Bernina-line PVs (`SAROP21-*`) are authoritative; the `SAROP11-*` reference is carried `confirm`, not silently modelled. | Whether the cross-line reference is a real Bernina dependency. |
+
+### Endstation: the diffractometers
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The GPS six-circle and XRD You-geometry platforms compose a goniometer, a 2-theta detector arm, a polarization-analyzer branch, a kappa goniometer, a heavy-load table, and a PI hexapod. Are they correctly modelled as the graduated `Diffractometer` Assembly (Goniometer + RotaryStage detector arm + reciprocal-space PseudoAxis), and which sub-assemblies does each carry? | Both reuse the `Diffractometer` Assembly (4-ID / 8-ID), no new Family; the mounted sub-assemblies are read from the external config (CONFIG-1). | The Assembly composition and the per-platform slot bindings. |
+| DIFF-2 | Nice-to-have | The reciprocal-space layer resolves hkl inverse kinematics (`SixCircleBernina`), and the XRD platform adds a kappa-to-Eulerian conversion. What is the `PartitionRule` shape for the `PseudoAxis`? | The reciprocal-space `PseudoAxis` carries a partition rule like the synchrotron diffractometers'; the kappa-to-You conversion is part of it. | The reciprocal-space partition rule. |
+| ROBOT-1 | Nice-to-have | The Staeubli TX200 robot handles samples / the detector over PShell (HTTP), not EPICS. How is it modelled? | Deferred; the robot is not modelled in this cut, the same posture I03 and MX3 take for their sample-exchange arms. | The robot's modelling and its `Subject` custody thread. |
+| ENV-1 | Nice-to-have | `eco` defines RIXS, tape-drive, and liquid-jet sample environments but their appends are commented out. Are they current Bernina endstation options? | Deferred; not in the live module, so not modelled, not invented. | The sample-environment variants. |
+
+### Acquisition, timing, diagnostics, and detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. Bernina is the third sighting (after LCLS-MFX and Alvra). | Whether CORA gains an event-stream acquisition axis. |
+| TIMING-1 | Blocks-go-live | The SwissFEL event system (master timing, CTA sequencer, EVR receivers) gates acquisition at beam rate. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
+| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `eco` `lxt` timing chain) and PSEN jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
+| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor, and the PSEN arrival-time monitor modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from Alvra / I22 / 2-BM; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
+| DET-1 | Blocks-go-live | What is the Bernina science detector? `eco` wires a 1.5M Jungfrau (`JF01T03V01`) inline; `sf_daq_broker` lists a 16M (`JF07T32V02`) plus I0 / vacuum / fluorescence / RIXS 0.5M variants, and the `eco` / broker version strings differ (V01 vs V02). Which is in use per diffractometer? | The detector reuses `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the active variant and wiring are external (CONFIG-1) and to supply. | The detector model, the per-diffractometer wiring, and the version mismatch. |
+| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one Alvra and LCLS-MFX raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/bernina/questions.md b/docs/deployments/bernina/questions.md
deleted file mode 100644
index 5667f718825..00000000000
--- a/docs/deployments/bernina/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
-
-Bernina is modelled from PSI's open [`eco`](https://github.com/paulscherrerinstitute/eco) controls library, treated as a dry, correct DATA source: the device list with PV prefixes comes from the live `eco/bernina/bernina.py`, and the diffractometer motor-axis topology from `eco/endstations/bernina_diffractometers.py`. That gives the device shape and the EPICS PV prefixes at high confidence. It does not give the configuration state, the motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding. This page collects what `eco` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-The defining Bernina question is **CONFIG-1**: unlike Alvra, Bernina's live device list and per-diffractometer configuration are loaded from non-public PSI files, so this is a deliberately partial first cut.
-
-## Scope, configuration, topology, and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is Bernina (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Bernina extends the PSI / XFEL exercise to a second station on the shared source and to a diffraction platform; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
-| CONFIG-1 | Blocks-build | `eco` loads Bernina's authoritative device list from `/sf/bernina/config/eco/bernina_config_eco.json` and the per-diffractometer configuration (which of base / arm / polana / kappa / heavy-load / hexapod / robot sub-assemblies are mounted, and which detector attaches to each) from `/sf/bernina/config/eco/configuration/bernina_config.json`, neither in the public repo. What is the current configuration? | The device list and diffractometer axis topology are taken from the public inline source; the mount state and detector wiring are carried unknown, not invented. | The full device list and the per-diffractometer mount + detector state. |
-| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. Should each station be its own root Unit sharing an upstream source, and where does the shared switched source live? Bernina is the second such station, so this is now concrete, not hypothetical. | One `Bernina` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
-| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `eco` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
-| ENC-1 | Blocks-build | Which enclosure does each device sit in? `eco` prefixes encode beamline-line zones (`SARFE10`, `SAROP21`, `SARES2x` / `SLAAR21`), not the access-gated hutch or its safety meaning. | The shared `SAROP21` optics hutch plus the Bernina experiment hutch. | The per-device Enclosure assignment. |
-
-## Source, optics, and attenuation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the Aramis undulator line parameters and the per-shot photon-energy mechanism? The `eco` manifest carries the downstream device handles, not the source. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
-| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring, so the loose `StorageRing` family does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the `FluxMonitor` gas / intensity monitors. | The linac machine-state modelling boundary. |
-| ATT-1 | Blocks-go-live | The `AttenuatorAramis` driver selects a foil combination for a requested transmission (energy-dependent). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With LCLS-MFX and Alvra carrying the same solve, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
-| MONO-1 | Nice-to-have | The double-crystal mono (ODCM098) is used for monochromatic modes; Bernina also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCM internals and the pink-vs-mono mode model. |
-| XREF-1 | Blocks-go-live | A live Bernina profile monitor (`prof_mirr_alv1`) carries an Alvra-line PV (`SAROP11-PPRM066`). Is this a real shared device, or a copy-paste residue in the library? | The Bernina-line PVs (`SAROP21-*`) are authoritative; the `SAROP11-*` reference is carried `confirm`, not silently modelled. | Whether the cross-line reference is a real Bernina dependency. |
-
-## Endstation: the diffractometers
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The GPS six-circle and XRD You-geometry platforms compose a goniometer, a 2-theta detector arm, a polarization-analyzer branch, a kappa goniometer, a heavy-load table, and a PI hexapod. Are they correctly modelled as the graduated `Diffractometer` Assembly (Goniometer + RotaryStage detector arm + reciprocal-space PseudoAxis), and which sub-assemblies does each carry? | Both reuse the `Diffractometer` Assembly (4-ID / 8-ID), no new Family; the mounted sub-assemblies are read from the external config (CONFIG-1). | The Assembly composition and the per-platform slot bindings. |
-| DIFF-2 | Nice-to-have | The reciprocal-space layer resolves hkl inverse kinematics (`SixCircleBernina`), and the XRD platform adds a kappa-to-Eulerian conversion. What is the `PartitionRule` shape for the `PseudoAxis`? | The reciprocal-space `PseudoAxis` carries a partition rule like the synchrotron diffractometers'; the kappa-to-You conversion is part of it. | The reciprocal-space partition rule. |
-| ROBOT-1 | Nice-to-have | The Staeubli TX200 robot handles samples / the detector over PShell (HTTP), not EPICS. How is it modelled? | Deferred; the robot is not modelled in this cut, the same posture I03 and MX3 take for their sample-exchange arms. | The robot's modelling and its `Subject` custody thread. |
-| ENV-1 | Nice-to-have | `eco` defines RIXS, tape-drive, and liquid-jet sample environments but their appends are commented out. Are they current Bernina endstation options? | Deferred; not in the live module, so not modelled, not invented. | The sample-environment variants. |
-
-## Acquisition, timing, diagnostics, and detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. Bernina is the third sighting (after LCLS-MFX and Alvra). | Whether CORA gains an event-stream acquisition axis. |
-| TIMING-1 | Blocks-go-live | The SwissFEL event system (master timing, CTA sequencer, EVR receivers) gates acquisition at beam rate. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
-| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `eco` `lxt` timing chain) and PSEN jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
-| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor, and the PSEN arrival-time monitor modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from Alvra / I22 / 2-BM; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
-| DET-1 | Blocks-go-live | What is the Bernina science detector? `eco` wires a 1.5M Jungfrau (`JF01T03V01`) inline; `sf_daq_broker` lists a 16M (`JF07T32V02`) plus I0 / vacuum / fluorescence / RIXS 0.5M variants, and the `eco` / broker version strings differ (V01 vs V02). Which is in use per diffractometer? | The detector reuses `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the active variant and wiring are external (CONFIG-1) and to supply. | The detector model, the per-diffractometer wiring, and the version mismatch. |
-| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one Alvra and LCLS-MFX raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/bernina/techniques.md b/docs/deployments/bernina/techniques.md
deleted file mode 100644
index d38ded9f204..00000000000
--- a/docs/deployments/bernina/techniques.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Techniques
-
-*What Bernina is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
-
-Bernina runs two technique families, neither of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
-
-## Femtosecond optical pump-probe
-
-The shared SwissFEL technique, the same one [Alvra](../alvra/techniques.md) and [LCLS-MFX](../lcls-mfx/techniques.md) run. An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves the dynamics in time. The PSEN spectral-encoding arrival-time monitor corrects the residual laser-to-X-ray jitter shot by shot.
-
-- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis on the experiment laser) while acquiring per-shot, with the PSEN monitor correcting jitter.
-- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `eco` `lxt` timing chain). Bernina is the third deployment to reach this gap (after LCLS-MFX and Alvra).
-
-## Time-resolved hard X-ray diffraction and scattering
-
-Bernina's reason for existing, and what distinguishes it from Alvra. After the pump, the sample's structural response is read by diffraction: Bragg peaks and diffuse scattering recorded shot by shot on the area detector, as a function of pump-probe delay. The sample is oriented and the detector positioned by the GPS six-circle or XRD You-geometry diffractometer.
-
-- **Spine shape:** a `diffraction` Method binding the diffractometer (a `Goniometer` for the sample circles, a `RotaryStage` 2-theta detector arm, and a reciprocal-space `PseudoAxis`), composed through the graduated `Diffractometer` Assembly (DIFF-1), over a per-shot acquisition. The reciprocal-space layer resolves the hkl inverse kinematics, and for the XRD platform the kappa-to-Eulerian conversion (DIFF-2).
-- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). A time-resolved diffraction run is a free-running shot stream tagged by pulse-ID and delay, not a trajectory of points the spine walks. The diffractometer itself is fully covered by the existing Assembly; the acquisition is the gap.
-
-## Why neither is in the catalog yet
-
-The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL diffraction station shares none of them: there is no rotation tomography, no flat / dark frame pairing, no storage-ring energy ramp. The `diffraction` Method is genuinely new for the fleet (the synchrotron diffractometers at 4-ID and 8-ID carry their own pending Methods), and coining it now, before the per-shot acquisition axis it depends on exists (DAQ-1), would be inventing a recipe for a spine that cannot yet run it. So it is carried pending. That a diffraction technique reaches the **same** acquisition gaps a spectroscopy technique (Alvra) and a crystallography technique (LCLS-MFX) reached is the reinforcement Bernina adds: the gaps are about the XFEL acquisition paradigm, not about any one technique. See [Model](model.md) for the gap register and the `Diffractometer` Assembly design.
diff --git a/docs/deployments/bmm/governance.md b/docs/deployments/bmm/governance.md
deleted file mode 100644
index a47849202cf..00000000000
--- a/docs/deployments/bmm/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at BMM and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A BMM beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a scan, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Batch automation and agents
-
-BMM's batch XAS, a wheel of many samples scanned unattended, is a natural place for an autonomous Agent: choosing the next sample, deciding when a spectrum has enough signal-to-noise, flagging a bad scan. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each decision (which sample, rescan-or-advance) would be a [Decision](../../architecture/modules/decision/index.md) recorded in the run provenance. None is declared for BMM yet; the unattended wheel loop is conducted, not agent-driven, in this scaffold.
diff --git a/docs/deployments/bmm/model.md b/docs/deployments/bmm/model.md
deleted file mode 100644
index 9144818197c..00000000000
--- a/docs/deployments/bmm/model.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's BMM content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at BMM |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (6-BM-A optics, 6-BM-B endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring HXN and the Diamond beamlines. Left out on purpose:
-
-- **The `energy_scan` Capability.** BMM is the first real consumer of the energy-scan sweep the catalog already anticipates (pending in code), but a Capability is coined when a conduct-path consumes it, not at scaffold time (see [Techniques](techniques.md), ENERGY-1). This is the live earn-the-abstraction question BMM surfaces.
-- **No new Family.** BMM reuses existing catalog Families: the ion chambers reuse `FluxMonitor` (graduated in #353), the fluorescence detector the catalog `EnergyDispersiveSpectrometer`, plus the catalog `Screen` Family (FLAG-1) for the diagnostic screens. The sample wheel reuses `RotaryStage`; whether a sample-changer Family is earned across BMM and the Diamond robots is open (WHEEL-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/bmm/notes.md b/docs/deployments/bmm/notes.md
new file mode 100644
index 00000000000..e74ab0ab98f
--- /dev/null
+++ b/docs/deployments/bmm/notes.md
@@ -0,0 +1,100 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at BMM: X-ray absorption spectroscopy, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). BMM raises the spectroscopy Capability question CORA has not yet had to answer.*
+
+BMM does transmission and fluorescence XAS / EXAFS: sweep the beam energy across an element's absorption edge, record the per-energy detector readings, and fit the absorption spectrum downstream.
+
+| BMM technique | CORA expression | Earn-the-abstraction call |
+| --- | --- | --- |
+| Transmission XAS / EXAFS | an energy sweep reading I0/It/Ir | the live question (ENERGY-1): coin `energy_scan`, or hold under `characterization`? |
+| Fluorescence XAS | the same sweep reading the `EnergyDispersiveSpectrometer` | same Capability, different detector in the slot |
+| Energy calibration | reference foil + `Ir` channel each scan | a Calibration, not a separate technique |
+| Alignment | beam-finding and slit/mirror tuning | reuse [`alignment`](../../catalog/methods.md) |
+
+### The energy_scan Capability question (ENERGY-1)
+
+BMM is the first CORA deployment whose measurement *is* an energy scan. The catalog already anticipates this: alongside `cora.capability.energy_change` (a coordinated *setpoint* move to one energy), a note records `cora.capability.energy_scan` as **pending in code**, and describes energy_change as "distinct from a future energy_scan sweep." BMM is that future consumer.
+
+Per the design-phase discipline (Diamond i03/i22, 32-ID, and HXN all coined no new Capability at scaffold time), this scaffold **defers** coining `energy_scan`: an XAS scan is mapped to `characterization` plus `energy_change` for now, and the Capability is coined when a conduct-path actually sweeps the energy. The argument to coin is strong (the sweep is the measurement, exactly the in-kind case), and the catalog already reserved the name; it is held open deliberately, not because it is weak, but because a Capability is coined when a conduct-path forces it, not at scaffold time.
+
+EXAFS data reduction (background subtraction, normalization, the chi(k) transform) is a `ComputePort` leg, not a beamline Method, the same way tomographic and ptychographic reconstruction are.
+
+## Governance
+
+*Who may act at BMM and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A BMM beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a scan, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Batch automation and agents
+
+BMM's batch XAS, a wheel of many samples scanned unattended, is a natural place for an autonomous Agent: choosing the next sample, deciding when a spectrum has enough signal-to-noise, flagging a bad scan. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each decision (which sample, rescan-or-advance) would be a [Decision](../../architecture/modules/decision/index.md) recorded in the run provenance. None is declared for BMM yet; the unattended wheel loop is conducted, not agent-driven, in this scaffold.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's BMM content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at BMM |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (6-BM-A optics, 6-BM-B endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring HXN and the Diamond beamlines. Left out on purpose:
+
+- **The `energy_scan` Capability.** BMM is the first real consumer of the energy-scan sweep the catalog already anticipates (pending in code), but a Capability is coined when a conduct-path consumes it, not at scaffold time (see [Techniques](#techniques), ENERGY-1). This is the live earn-the-abstraction question BMM surfaces.
+- **No new Family.** BMM reuses existing catalog Families: the ion chambers reuse `FluxMonitor` (graduated in #353), the fluorescence detector the catalog `EnergyDispersiveSpectrometer`, plus the catalog `Screen` Family (FLAG-1) for the diagnostic screens. The sample wheel reuses `RotaryStage`; whether a sample-changer Family is earned across BMM and the Diamond robots is open (WHEEL-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the BMM team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/bmm-profile-collection`](https://github.com/NSLS2/bmm-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build` (changes the model structure), `Blocks-go-live` (needed before CORA controls or observes the hardware), `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The 6-BM bending-magnet source parameters (critical energy, fan). The source is confirmed a bending magnet (`SR:C06`), not an insertion device. | A bending-magnet PhotonBeam Supply, identity-only. | The Source Supply settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the front-end and photon shutters (`XF:06BM-PPS{Sh:FE}`, `{Sh:A}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | Is the endstation a distinct hutch (6-BM-B) from the optics hutch (6-BM-A)? | Two enclosures, optics + experiment. | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The DCM crystal sets available (Si(111) confirmed; a Si(311) set?) and the energy range. | Si(111), range blank. | The Monochromator settings. |
+| OPTIC-1 | Nice-to-have | The mirror coatings / stripes on M1 and M2 (harmonic rejection). | Two mirrors, coatings blank. | The Mirror settings. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| WHEEL-1 | Blocks-go-live | The sample wheel: how many sample positions, and is batch sample-changing a CORA-modelled automation or operator-driven? Should a dedicated sample-changer Family be earned across BMM and the Diamond robots, or does the wheel stay a `RotaryStage`? | A `RotaryStage` indexing samples; sample-changer behaviour is a Method/automation concern, not a new Family. | The sample-wheel model and the sample-changer abstraction. |
+| DET-1 | Blocks-go-live | The fluorescence detector configuration: which Xspress3 element count (1, 4, or 7) is the installed/default, and the vendor (Quantum Detectors?). Source carries all three configurations. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; element count blank. | The detector Model and element count. |
+| DIAG-1 | Blocks-go-live | The ion chambers (`I0`/`It`/`Ir`) gas fill and the per-channel PV bindings. | The quad electrometer binds the catalog `FluxMonitor` Family (graduated in #353); gas fill and per-channel detail unconfirmed. | The I0/It/Ir bindings and gas fill. |
+
+### Controls and techniques
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, serials, IPs. The endstation controller PV (`MC:09`) is in source; vendor detail is not. | A `MotionController`, specifics blank. | The MotionController Models. |
+| ENERGY-1 | Blocks-build | Should CORA coin the `energy_scan` Capability (the catalog anticipates it as pending) now that BMM is its first real consumer, or keep XAS under `characterization` + `energy_change` until a conduct-path forces it? An XAS scan sweeps the energy axis and reads the detectors per point, distinct from the `beamline_energy_change` setpoint move. | XAS mapped to existing Capabilities for now; `energy_scan` deferred per the design-phase discipline. | The spectroscopy Capability decision. |
diff --git a/docs/deployments/bmm/questions.md b/docs/deployments/bmm/questions.md
deleted file mode 100644
index f8daab9818f..00000000000
--- a/docs/deployments/bmm/questions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Open questions
-
-*What CORA needs the BMM team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/bmm-profile-collection`](https://github.com/NSLS2/bmm-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build` (changes the model structure), `Blocks-go-live` (needed before CORA controls or observes the hardware), `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The 6-BM bending-magnet source parameters (critical energy, fan). The source is confirmed a bending magnet (`SR:C06`), not an insertion device. | A bending-magnet PhotonBeam Supply, identity-only. | The Source Supply settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the front-end and photon shutters (`XF:06BM-PPS{Sh:FE}`, `{Sh:A}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | Is the endstation a distinct hutch (6-BM-B) from the optics hutch (6-BM-A)? | Two enclosures, optics + experiment. | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The DCM crystal sets available (Si(111) confirmed; a Si(311) set?) and the energy range. | Si(111), range blank. | The Monochromator settings. |
-| OPTIC-1 | Nice-to-have | The mirror coatings / stripes on M1 and M2 (harmonic rejection). | Two mirrors, coatings blank. | The Mirror settings. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| WHEEL-1 | Blocks-go-live | The sample wheel: how many sample positions, and is batch sample-changing a CORA-modelled automation or operator-driven? Should a dedicated sample-changer Family be earned across BMM and the Diamond robots, or does the wheel stay a `RotaryStage`? | A `RotaryStage` indexing samples; sample-changer behaviour is a Method/automation concern, not a new Family. | The sample-wheel model and the sample-changer abstraction. |
-| DET-1 | Blocks-go-live | The fluorescence detector configuration: which Xspress3 element count (1, 4, or 7) is the installed/default, and the vendor (Quantum Detectors?). Source carries all three configurations. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; element count blank. | The detector Model and element count. |
-| DIAG-1 | Blocks-go-live | The ion chambers (`I0`/`It`/`Ir`) gas fill and the per-channel PV bindings. | The quad electrometer binds the catalog `FluxMonitor` Family (graduated in #353); gas fill and per-channel detail unconfirmed. | The I0/It/Ir bindings and gas fill. |
-
-## Controls and techniques
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, serials, IPs. The endstation controller PV (`MC:09`) is in source; vendor detail is not. | A `MotionController`, specifics blank. | The MotionController Models. |
-| ENERGY-1 | Blocks-build | Should CORA coin the `energy_scan` Capability (the catalog anticipates it as pending) now that BMM is its first real consumer, or keep XAS under `characterization` + `energy_change` until a conduct-path forces it? An XAS scan sweeps the energy axis and reads the detectors per point, distinct from the `beamline_energy_change` setpoint move. | XAS mapped to existing Capabilities for now; `energy_scan` deferred per the design-phase discipline. | The spectroscopy Capability decision. |
diff --git a/docs/deployments/bmm/techniques.md b/docs/deployments/bmm/techniques.md
deleted file mode 100644
index 7eef4f6384e..00000000000
--- a/docs/deployments/bmm/techniques.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Techniques
-
-*What CORA would run at BMM: X-ray absorption spectroscopy, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). BMM raises the spectroscopy Capability question CORA has not yet had to answer.*
-
-BMM does transmission and fluorescence XAS / EXAFS: sweep the beam energy across an element's absorption edge, record the per-energy detector readings, and fit the absorption spectrum downstream.
-
-| BMM technique | CORA expression | Earn-the-abstraction call |
-| --- | --- | --- |
-| Transmission XAS / EXAFS | an energy sweep reading I0/It/Ir | the live question (ENERGY-1): coin `energy_scan`, or hold under `characterization`? |
-| Fluorescence XAS | the same sweep reading the `EnergyDispersiveSpectrometer` | same Capability, different detector in the slot |
-| Energy calibration | reference foil + `Ir` channel each scan | a Calibration, not a separate technique |
-| Alignment | beam-finding and slit/mirror tuning | reuse [`alignment`](../../catalog/methods.md) |
-
-## The energy_scan Capability question (ENERGY-1)
-
-BMM is the first CORA deployment whose measurement *is* an energy scan. The catalog already anticipates this: alongside `cora.capability.energy_change` (a coordinated *setpoint* move to one energy), a note records `cora.capability.energy_scan` as **pending in code**, and describes energy_change as "distinct from a future energy_scan sweep." BMM is that future consumer.
-
-Per the design-phase discipline (Diamond i03/i22, 32-ID, and HXN all coined no new Capability at scaffold time), this scaffold **defers** coining `energy_scan`: an XAS scan is mapped to `characterization` plus `energy_change` for now, and the Capability is coined when a conduct-path actually sweeps the energy. The argument to coin is strong (the sweep is the measurement, exactly the in-kind case), and the catalog already reserved the name; it is held open deliberately, not because it is weak, but because a Capability is coined when a conduct-path forces it, not at scaffold time.
-
-EXAFS data reduction (background subtraction, normalization, the chi(k) transform) is a `ComputePort` leg, not a beamline Method, the same way tomographic and ptychographic reconstruction are.
diff --git a/docs/deployments/cdi/governance.md b/docs/deployments/cdi/governance.md
deleted file mode 100644
index d91dcecbdba..00000000000
--- a/docs/deployments/cdi/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at CDI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A CDI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may align the KB nanofocus, change the incident energy, arm a ptychographic scan, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Long unattended scans
-
-A ptychographic map or a Bragg-CDI rocking series can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the scan while the trust boundary bounds what may change mid-acquisition and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next scan region, decide when the diffraction signal is sufficient, trigger a reconstruction to check convergence), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/cdi/model.md b/docs/deployments/cdi/model.md
deleted file mode 100644
index 95168edc471..00000000000
--- a/docs/deployments/cdi/model.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's CDI content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at CDI |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [the stage pages](source.md) (`EnergyAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (9-ID-A optics, 9-ID-C endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring CHX, HXN, and the other reverse-engineered deployments. Left out on purpose:
-
-- **No new Family.** CDI is a reuse-and-reinforce deployment: the area detectors and diagnostic cameras bind `Camera`, the foil intensity monitor `FluxMonitor`, the pre-mirrors and the KB nanofocus pair `Mirror`, both monochromators `Monochromator`, the sample stack `Goniometer`, the white-beam / branch / conditioning slits `Slit`, the attenuator foils `Filter`, the undulator `InsertionDevice`, the master energy a `PseudoAxis`, and the endstation towers `LinearStage`. Nothing graduates and the catalog is unchanged.
-- **The diagnostics and supply readback.** The `DiamondBeamMonitor` binds the graduated catalog `PositionMonitor` Family, which presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The `StorageRing` current readback is a loose supply observation (machine state), never an Asset Family.
-- **No new Capability or Method.** Ptychography reuses the pending `ptychography` Method Diamond i13-1 opened (the fleet's first coherent diffractive imaging); forward and Bragg CDI are the single-shot variants of the same deferred coherent-imaging cohort, not separately coined (`TECH-1`). CDI reinforces the Method without coining anything and records no Practice until the scope lands. The phase retrieval and ptychographic reconstruction are `ComputePort` work, not a Method.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/cdi/notes.md b/docs/deployments/cdi/notes.md
new file mode 100644
index 00000000000..ed91ed6c3f6
--- /dev/null
+++ b/docs/deployments/cdi/notes.md
@@ -0,0 +1,106 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at CDI: coherent-imaging techniques, each a [Catalog](../../catalog/methods.md) Method. CDI follows the deferral the coherent and scanning beamlines set, after Diamond [i13-1](../i13-1/notes.md#techniques), which opened the pending `ptychography` Method, and APS [8-ID](../8-id/notes.md#techniques), [CHX](../chx/notes.md#techniques), and [HXN](../hxn/notes.md#techniques).*
+
+CDI's techniques are coherent diffractive imaging: focus a coherent beam, record the far-field diffraction pattern, and recover the real-space image offline by phase retrieval. These Methods are new to CORA's imaging- and spectroscopy-heritage catalog, so the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Ptychography | `ptychography` | a scan of overlapping coherent-diffraction frames across the sample; reuses the pending `ptychography` Method Diamond i13-1 opened; the reconstruction is a `ComputePort` leg, not a beamline Method (the HXN framing) |
+| Forward CDI | `coherent_diffraction_imaging` | a single far-field coherent-diffraction frame on the Eiger2 / Merlin from an isolated object; the single-shot variant of the same deferred coherent-imaging cohort, not separately coined |
+| Bragg CDI | `coherent_diffraction_imaging` | a rocking series around a Bragg peak for strain imaging of a crystalline grain, with the [goniometer](sample.md) setting the orientation; the same deferred coherent-imaging cohort |
+| Alignment | [`alignment`](../../catalog/methods.md) | beam, KB, mirror, and slit tuning; reuses the existing Method |
+
+All three imaging techniques need the [KB nanofocus and sample stack](sample.md) and the [coherent detectors](detector.md); how the exposure is gated on the floor is the open timing question (TIMING-1).
+
+### Why the Methods stay deferred
+
+Diamond i13-1 opened the coherent-imaging Method as the pending `ptychography` Method (the fleet's first coherent diffractive imaging), carried pending until a conduct-path earns it (TECH-1). CDI reinforces that Method at a second facility and adds the single-shot forward and Bragg CDI variants, which are not separately coined; the concrete acquisition recipes (frame counts, scan grids, rocking ranges, exposures) join as the deployment approaches the point where CORA drives the beamline. This is the same earn-the-abstraction discipline the deferred `small_angle_scattering` (8-ID, CHX) techniques follow. Because the full coherent-imaging Method scope is not in the catalog, CDI records **no Practice** in the [NSLS-II Site](../nsls2/index.md), as CHX records none for its coherent-scattering Methods; the binding lands when the Method does.
+
+The phase retrieval itself (the iterative reconstruction that turns the diffraction frames into a real-space image, and the ptychographic engine that solves for object and probe together) is `ComputePort` work, not a beamline Method. This is the imaging analogue of CHX's correlation analysis: the beamline takes the frames, CORA's compute leg turns them into the result.
+
+## Governance
+
+*Who may act at CDI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A CDI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may align the KB nanofocus, change the incident energy, arm a ptychographic scan, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Long unattended scans
+
+A ptychographic map or a Bragg-CDI rocking series can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the scan while the trust boundary bounds what may change mid-acquisition and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next scan region, decide when the diffraction signal is sufficient, trigger a reconstruction to check convergence), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's CDI content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at CDI |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [the stage pages](source.md) (`EnergyAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (9-ID-A optics, 9-ID-C endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring CHX, HXN, and the other reverse-engineered deployments. Left out on purpose:
+
+- **No new Family.** CDI is a reuse-and-reinforce deployment: the area detectors and diagnostic cameras bind `Camera`, the foil intensity monitor `FluxMonitor`, the pre-mirrors and the KB nanofocus pair `Mirror`, both monochromators `Monochromator`, the sample stack `Goniometer`, the white-beam / branch / conditioning slits `Slit`, the attenuator foils `Filter`, the undulator `InsertionDevice`, the master energy a `PseudoAxis`, and the endstation towers `LinearStage`. Nothing graduates and the catalog is unchanged.
+- **The diagnostics and supply readback.** The `DiamondBeamMonitor` binds the graduated catalog `PositionMonitor` Family, which presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The `StorageRing` current readback is a loose supply observation (machine state), never an Asset Family.
+- **No new Capability or Method.** Ptychography reuses the pending `ptychography` Method Diamond i13-1 opened (the fleet's first coherent diffractive imaging); forward and Bragg CDI are the single-shot variants of the same deferred coherent-imaging cohort, not separately coined (`TECH-1`). CDI reinforces the Method without coining anything and records no Practice until the scope lands. The phase retrieval and ptychographic reconstruction are `ComputePort` work, not a Method.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the CDI team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/cdi-profile-collection`](https://github.com/NSLS2/cdi-profile-collection) profile collection and the [`NSLS2/cditools`](https://github.com/NSLS2/cditools) device library): the EPICS PVs are read from them, but vendor identities, physical positions, and the timing configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | IVU18 undulator period, gap range, and harmonic usage. The device (`SR:C09-ID:G1{IVU18:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the photon-shutter PVs. Neither is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | Whether the 09IDB branch zone (`Slt:DM3`, the quadrant BPM) is a distinct access-gated enclosure or part of the optics hutch. | Two enclosures (9-ID-A optics, 9-ID-C endstation); 09IDB folded into the optics zone. | The Enclosure boundaries. |
+| MACHINE-1 | Nice-to-have | The storage-ring state CDI reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs beyond `ring_current` pending. | The machine-state observation. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The Si DCM cryo detail and full range (the Si(111) reflection and `d = 3.1287 A` are read from the Energy model), and the DMM multilayer coating and bandpass. Both monochromators (`Mono:HDCM`, `Mono:DMM`) are in source. | Two Monochromator Assets, Si(111) recorded, other settings blank. | The Monochromator settings. |
+| KB-1 | Blocks-go-live | The KB mirror focal size, coating / stripe, and working distance; whether both VKB and HKB are always installed. | A `Mirror` Asset (the KB pair); focus geometry blank. | The KB nanofocus spec. |
+| ENERGY-1 | Nice-to-have | Whether incident energy is ever scanned as the measurement, and the true energy range (the `5-15 keV` bounds are marked `TODO: CHECK` in source). | Fixed-energy imaging; the range left provisional. | The energy Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | Which endstation tower (`TDMS:T1` / `TDMS:T2`) carries the sample versus the detector, the sample-to-detector distance that sets the q-range, and the full `Gon:1` goniometer axis set. Some tower axes are read-only pending commissioning in source. | Two `LinearStage` towers and a `Goniometer`; roles and distance deferred. | The endstation geometry. |
+| DET-1 | Blocks-go-live | Which detector (Eiger2 / Merlin) is primary for which technique, the foil materials / thicknesses, and whether a direct-beam beamstop is installed (none is in source). | Both Cameras; Eiger2 primary; no beamstop modelled. | The detector roster and beamstop. |
+| CAM-1 | Nice-to-have | Which diagnostic cameras (the BCU inline camera, the sample camera, the optics-module Prosilicas) are live. | The inline and sample cameras modelled; others noted. | The diagnostic-camera set. |
+| DIAG-1 | Nice-to-have | The foil-monitor channel map and the quadrant / diamond BPM channels (the diamond BPM was repurposed from ion-chamber use in source). | Read-only flux and beam-position probes; channel maps blank. | The `FluxMonitor` and `PositionMonitor` bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TIMING-1 | Blocks-go-live | The exposure-gating chain. The profile collection exposes no trigger box (no Zebra / PandA startup file, no shutter PVs); the Eiger2 and Merlin carry internal and external trigger modes. How is a coherent-imaging exposure gated and synchronized with the scan? | Detector-internal triggering; no floor trigger box modelled. | The triggering chain. |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs behind the EPICS motor records. | One `MotionController` family bound (`EndstationMotionController`), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the coherent-imaging Methods (forward CDI, ptychography, Bragg CDI) enter CORA's catalog, or stay deferred? This is the same owner-scope decision 8-ID opened. | Methods deferred (rendered unlinked), no Practice recorded. | The coherent-imaging Method scope. |
diff --git a/docs/deployments/cdi/questions.md b/docs/deployments/cdi/questions.md
deleted file mode 100644
index 4b06dd8632e..00000000000
--- a/docs/deployments/cdi/questions.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Open questions
-
-*What CORA needs the CDI team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/cdi-profile-collection`](https://github.com/NSLS2/cdi-profile-collection) profile collection and the [`NSLS2/cditools`](https://github.com/NSLS2/cditools) device library): the EPICS PVs are read from them, but vendor identities, physical positions, and the timing configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | IVU18 undulator period, gap range, and harmonic usage. The device (`SR:C09-ID:G1{IVU18:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the photon-shutter PVs. Neither is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | Whether the 09IDB branch zone (`Slt:DM3`, the quadrant BPM) is a distinct access-gated enclosure or part of the optics hutch. | Two enclosures (9-ID-A optics, 9-ID-C endstation); 09IDB folded into the optics zone. | The Enclosure boundaries. |
-| MACHINE-1 | Nice-to-have | The storage-ring state CDI reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs beyond `ring_current` pending. | The machine-state observation. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The Si DCM cryo detail and full range (the Si(111) reflection and `d = 3.1287 A` are read from the Energy model), and the DMM multilayer coating and bandpass. Both monochromators (`Mono:HDCM`, `Mono:DMM`) are in source. | Two Monochromator Assets, Si(111) recorded, other settings blank. | The Monochromator settings. |
-| KB-1 | Blocks-go-live | The KB mirror focal size, coating / stripe, and working distance; whether both VKB and HKB are always installed. | A `Mirror` Asset (the KB pair); focus geometry blank. | The KB nanofocus spec. |
-| ENERGY-1 | Nice-to-have | Whether incident energy is ever scanned as the measurement, and the true energy range (the `5-15 keV` bounds are marked `TODO: CHECK` in source). | Fixed-energy imaging; the range left provisional. | The energy Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | Which endstation tower (`TDMS:T1` / `TDMS:T2`) carries the sample versus the detector, the sample-to-detector distance that sets the q-range, and the full `Gon:1` goniometer axis set. Some tower axes are read-only pending commissioning in source. | Two `LinearStage` towers and a `Goniometer`; roles and distance deferred. | The endstation geometry. |
-| DET-1 | Blocks-go-live | Which detector (Eiger2 / Merlin) is primary for which technique, the foil materials / thicknesses, and whether a direct-beam beamstop is installed (none is in source). | Both Cameras; Eiger2 primary; no beamstop modelled. | The detector roster and beamstop. |
-| CAM-1 | Nice-to-have | Which diagnostic cameras (the BCU inline camera, the sample camera, the optics-module Prosilicas) are live. | The inline and sample cameras modelled; others noted. | The diagnostic-camera set. |
-| DIAG-1 | Nice-to-have | The foil-monitor channel map and the quadrant / diamond BPM channels (the diamond BPM was repurposed from ion-chamber use in source). | Read-only flux and beam-position probes; channel maps blank. | The `FluxMonitor` and `PositionMonitor` bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TIMING-1 | Blocks-go-live | The exposure-gating chain. The profile collection exposes no trigger box (no Zebra / PandA startup file, no shutter PVs); the Eiger2 and Merlin carry internal and external trigger modes. How is a coherent-imaging exposure gated and synchronized with the scan? | Detector-internal triggering; no floor trigger box modelled. | The triggering chain. |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs behind the EPICS motor records. | One `MotionController` family bound (`EndstationMotionController`), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the coherent-imaging Methods (forward CDI, ptychography, Bragg CDI) enter CORA's catalog, or stay deferred? This is the same owner-scope decision 8-ID opened. | Methods deferred (rendered unlinked), no Practice recorded. | The coherent-imaging Method scope. |
diff --git a/docs/deployments/cdi/techniques.md b/docs/deployments/cdi/techniques.md
deleted file mode 100644
index 0bac07b2a7e..00000000000
--- a/docs/deployments/cdi/techniques.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Techniques
-
-*What CORA would run at CDI: coherent-imaging techniques, each a [Catalog](../../catalog/methods.md) Method. CDI follows the deferral the coherent and scanning beamlines set, after Diamond [i13-1](../i13-1/techniques.md), which opened the pending `ptychography` Method, and APS [8-ID](../8-id/techniques.md), [CHX](../chx/techniques.md), and [HXN](../hxn/techniques.md).*
-
-CDI's techniques are coherent diffractive imaging: focus a coherent beam, record the far-field diffraction pattern, and recover the real-space image offline by phase retrieval. These Methods are new to CORA's imaging- and spectroscopy-heritage catalog, so the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Ptychography | `ptychography` | a scan of overlapping coherent-diffraction frames across the sample; reuses the pending `ptychography` Method Diamond i13-1 opened; the reconstruction is a `ComputePort` leg, not a beamline Method (the HXN framing) |
-| Forward CDI | `coherent_diffraction_imaging` | a single far-field coherent-diffraction frame on the Eiger2 / Merlin from an isolated object; the single-shot variant of the same deferred coherent-imaging cohort, not separately coined |
-| Bragg CDI | `coherent_diffraction_imaging` | a rocking series around a Bragg peak for strain imaging of a crystalline grain, with the [goniometer](sample.md) setting the orientation; the same deferred coherent-imaging cohort |
-| Alignment | [`alignment`](../../catalog/methods.md) | beam, KB, mirror, and slit tuning; reuses the existing Method |
-
-All three imaging techniques need the [KB nanofocus and sample stack](sample.md) and the [coherent detectors](detector.md); how the exposure is gated on the floor is the open timing question (TIMING-1).
-
-## Why the Methods stay deferred
-
-Diamond i13-1 opened the coherent-imaging Method as the pending `ptychography` Method (the fleet's first coherent diffractive imaging), carried pending until a conduct-path earns it (TECH-1). CDI reinforces that Method at a second facility and adds the single-shot forward and Bragg CDI variants, which are not separately coined; the concrete acquisition recipes (frame counts, scan grids, rocking ranges, exposures) join as the deployment approaches the point where CORA drives the beamline. This is the same earn-the-abstraction discipline the deferred `small_angle_scattering` (8-ID, CHX) techniques follow. Because the full coherent-imaging Method scope is not in the catalog, CDI records **no Practice** in the [NSLS-II Site](../nsls2/index.md), as CHX records none for its coherent-scattering Methods; the binding lands when the Method does.
-
-The phase retrieval itself (the iterative reconstruction that turns the diffraction frames into a real-space image, and the ptychographic engine that solves for object and probe together) is `ComputePort` work, not a beamline Method. This is the imaging analogue of CHX's correlation analysis: the beamline takes the frames, CORA's compute leg turns them into the result.
diff --git a/docs/deployments/chx/governance.md b/docs/deployments/chx/governance.md
deleted file mode 100644
index 6ef066a7e84..00000000000
--- a/docs/deployments/chx/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at CHX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A CHX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may arm a long XPCS series, change the q-range, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Long unattended runs
-
-XPCS time series can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the gated exposure while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next sample temperature, decide when enough frames are collected), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/chx/model.md b/docs/deployments/chx/model.md
deleted file mode 100644
index 0dced9f4908..00000000000
--- a/docs/deployments/chx/model.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's CHX content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at CHX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (11-ID-A optics, 11-ID-B endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring HXN, BMM, SRX, and the Diamond beamlines. Left out on purpose:
-
-- **No new Family.** CHX is a reuse-and-reinforce deployment: the area detectors bind `Camera`, the flux counter `FluxMonitor`, the thermal stage `TemperatureController`, the fluorescence detector `EnergyDispersiveSpectrometer`, the beamstop `BeamStop`, the mirrors `Mirror`, both monochromators `Monochromator`, the coherence-defining and guard slits `Slit`, and the compound-refractive-lens focusing optic the graduated `Transfocator` catalog Family (a CRL focusing optic, also bound at 4-ID, 8-ID, 9-ID, i22). The `Transfocator` graduation settled the focusing-optic abstraction, so it is a normal catalog reuse like `Mirror`; what remains open for the transfocator is only its per-Asset lens material and count, tracked as `CRL-1`. CHX also carries a **second**, distinct kind of refractive focusing optic, the endstation kinoform lenses (`k1`/`k2`): a single profiled refractive lens, not a compound-lens transfocator, so it does not bind the `Transfocator` Family. It is named but not modelled as a device; whether a kinoform earns its own Family is a separate future question if a deployment binds one, not part of `CRL-1`.
-- **The graduated `PositionMonitor`.** The `PositionMonitor` (4-ID, 8-ID, 9-ID) binds the graduated catalog Family, which presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux.
-- **No new Capability or Method.** XPCS and small-angle scattering sit on the deferred `xpcs` / `small_angle_scattering` Methods 8-ID left pending (`TECH-1`); CHX reinforces both without coining either, and records no Practice until they land. The correlation analysis is `ComputePort` work, not a Method.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/chx/notes.md b/docs/deployments/chx/notes.md
new file mode 100644
index 00000000000..1dad38b97a0
--- /dev/null
+++ b/docs/deployments/chx/notes.md
@@ -0,0 +1,104 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at CHX: coherent-scattering techniques, each a [Catalog](../../catalog/methods.md) Method. CHX is the second coherent beamline CORA models, after APS [8-ID](../8-id/notes.md#techniques), and it follows 8-ID's deferral exactly.*
+
+CHX's techniques are coherent-scattering, new to CORA's imaging- and spectroscopy-heritage catalog. As at 8-ID, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| XPCS | `xpcs` | coherent-speckle intensity time series on the Eiger, gated by the Zebra / fast shutter (TIMING-1); Method not yet in catalog |
+| Small-angle scattering | `small_angle_scattering` | static SAXS/WAXS on the same detectors; a Plan setting over the same chain |
+| Grazing-incidence scattering | `small_angle_scattering` | GISAXS: the same scattering Method with the beam steered onto a surface by the `GrazingIncidenceMirror` (GI-1) |
+| Alignment | [`alignment`](../../catalog/methods.md) | beam, mirror, transfocator, and slit tuning; reuses the existing Method |
+
+All three scattering techniques need the [sample stack](sample.md) and the [coherent detectors](detector.md); the fast shutter and Zebra (TIMING-1) gate the exposure.
+
+### Why the Methods stay deferred
+
+8-ID opened the question of whether the XPCS and small-angle-scattering Methods enter CORA's catalog (TECH-1), and `main` deliberately left them pending: the concrete acquisition recipes (correlation time series, frame rates, exposures) join as the deployment approaches the point where CORA drives the beamline. CHX reinforces the case for both Methods at a second facility without coining either, the same earn-the-abstraction discipline the deferred `scanning` (HXN) and `energy_scan` (BMM) Capabilities follow. Because the defining Methods are not in the catalog, CHX records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here), exactly as 8-ID records none at APS; the binding lands when the Method does.
+
+The correlation analysis itself (the g2 / multi-tau computation that turns the frame series into dynamics) is `ComputePort` work, not a beamline Method.
+
+## Governance
+
+*Who may act at CHX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A CHX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may arm a long XPCS series, change the q-range, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Long unattended runs
+
+XPCS time series can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the gated exposure while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next sample temperature, decide when enough frames are collected), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's CHX content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at CHX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (11-ID-A optics, 11-ID-B endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring HXN, BMM, SRX, and the Diamond beamlines. Left out on purpose:
+
+- **No new Family.** CHX is a reuse-and-reinforce deployment: the area detectors bind `Camera`, the flux counter `FluxMonitor`, the thermal stage `TemperatureController`, the fluorescence detector `EnergyDispersiveSpectrometer`, the beamstop `BeamStop`, the mirrors `Mirror`, both monochromators `Monochromator`, the coherence-defining and guard slits `Slit`, and the compound-refractive-lens focusing optic the graduated `Transfocator` catalog Family (a CRL focusing optic, also bound at 4-ID, 8-ID, 9-ID, i22). The `Transfocator` graduation settled the focusing-optic abstraction, so it is a normal catalog reuse like `Mirror`; what remains open for the transfocator is only its per-Asset lens material and count, tracked as `CRL-1`. CHX also carries a **second**, distinct kind of refractive focusing optic, the endstation kinoform lenses (`k1`/`k2`): a single profiled refractive lens, not a compound-lens transfocator, so it does not bind the `Transfocator` Family. It is named but not modelled as a device; whether a kinoform earns its own Family is a separate future question if a deployment binds one, not part of `CRL-1`.
+- **The graduated `PositionMonitor`.** The `PositionMonitor` (4-ID, 8-ID, 9-ID) binds the graduated catalog Family, which presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux.
+- **No new Capability or Method.** XPCS and small-angle scattering sit on the deferred `xpcs` / `small_angle_scattering` Methods 8-ID left pending (`TECH-1`); CHX reinforces both without coining either, and records no Practice until they land. The correlation analysis is `ComputePort` work, not a Method.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the CHX team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/chx-profile-collection`](https://github.com/NSLS2/chx-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector/timing configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | IVU20 undulator period, gap range, and harmonic usage. The device (`SR:C11-ID:G1{IVU20:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:11ID-PPS{Sh:FE}`, `XF:11IDA-PPS{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The Si DCM cryo detail and full range (the Si(111) cut and harmonic 5 are read from the production `move_E` routine), and the DMM multilayer coating and bandpass. Both monochromators (`Mono:DCM`, `Mono:DMM`) are in source. | Two Monochromator Assets, Si(111) cut recorded, other settings blank. | The Monochromator settings. |
+| CRL-1 | Blocks-go-live | The FOE transfocator (`XF:11IDA-OP{Lens:`) lens material and lenslet count. Its catalog home is settled: it binds the graduated `Transfocator` CRL Family; only the per-Asset lens spec is open. (The endstation kinoform lenses `k1`/`k2`, `XF:11IDB-OP{Lens:1` / `{Lens:2`, are a distinct refractive optic, not a compound-lens transfocator; they are named but not modelled as devices, and whether they earn their own Family is a separate future question, not part of CRL-1.) | The transfocator binds the graduated `Transfocator` Family; lens material and count left blank. | The transfocator lens spec. |
+| GI-1 | Nice-to-have | Is grazing-incidence scattering (GISAXS) a live routine, and does the `Mir:GI` mirror steer the beam for it? | A `Mirror` Asset; GISAXS noted as a technique. | The GISAXS geometry. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The full diffractometer axis set behind the `SamplePositioner` pseudomotor, and whether the goniometric axes warrant a `Goniometer` plus a Diffractometer Assembly (the 8-ID precedent). | A `LinearStage` sample stack, rotation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
+| DET-1 | Blocks-go-live | Which Eiger (4M / 1M / 500K) is the primary XPCS detector vs the spare set, whether a separate along-beam stage sets the sample-to-detector distance (the `Det:SAXS` motor is transverse X/Y only), and the Xspress3 element count. | Eiger 4M primary; all Cameras; no distance stage modelled. | The detector roster and q-range. |
+| CAM-1 | Nice-to-have | Which beam-viewing cameras (the Prosilica x-ray-eyes, the PointGrey, the OAV) are live. | The OAV modelled as a Camera; others noted. | The beam-viewing camera set. |
+| DIAG-1 | Nice-to-have | The scaler flux channel map (which channel is I0) and the BPM / AH401B electrometer channels. | Read-only flux and beam-position probes; channel maps blank. | The FluxCounter and PositionMonitor bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TIMING-1 | Blocks-go-live | The XPCS exposure-gating chain: how the Zebra, the delay generator (`delaygen:DG0:`), and the fast shutter co-time the Eiger frame triggers, and their vendor identities. | One `TimingController` (Zebra) gating the fast shutter and frames; chain detail blank. | The triggering chain. |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| ENERGY-1 | Nice-to-have | Is CHX always fixed-energy, or does anomalous XPCS scan energy as the measurement (the `energy_scan` Capability the catalog anticipates, shared with BMM)? | Fixed-energy; energy_scan deferred (the BMM question). | The energy Capability decision. |
+| TECH-1 | Blocks-go-live | Do the XPCS and small-angle-scattering Methods enter CORA's catalog, or stay deferred? This is the same owner-scope decision 8-ID opened. | Methods deferred (rendered unlinked), no Practice recorded. | The coherent-scattering Method scope. |
diff --git a/docs/deployments/chx/questions.md b/docs/deployments/chx/questions.md
deleted file mode 100644
index 7f7a23bbd95..00000000000
--- a/docs/deployments/chx/questions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Open questions
-
-*What CORA needs the CHX team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/chx-profile-collection`](https://github.com/NSLS2/chx-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector/timing configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | IVU20 undulator period, gap range, and harmonic usage. The device (`SR:C11-ID:G1{IVU20:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:11ID-PPS{Sh:FE}`, `XF:11IDA-PPS{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The Si DCM cryo detail and full range (the Si(111) cut and harmonic 5 are read from the production `move_E` routine), and the DMM multilayer coating and bandpass. Both monochromators (`Mono:DCM`, `Mono:DMM`) are in source. | Two Monochromator Assets, Si(111) cut recorded, other settings blank. | The Monochromator settings. |
-| CRL-1 | Blocks-go-live | The FOE transfocator (`XF:11IDA-OP{Lens:`) lens material and lenslet count. Its catalog home is settled: it binds the graduated `Transfocator` CRL Family; only the per-Asset lens spec is open. (The endstation kinoform lenses `k1`/`k2`, `XF:11IDB-OP{Lens:1` / `{Lens:2`, are a distinct refractive optic, not a compound-lens transfocator; they are named but not modelled as devices, and whether they earn their own Family is a separate future question, not part of CRL-1.) | The transfocator binds the graduated `Transfocator` Family; lens material and count left blank. | The transfocator lens spec. |
-| GI-1 | Nice-to-have | Is grazing-incidence scattering (GISAXS) a live routine, and does the `Mir:GI` mirror steer the beam for it? | A `Mirror` Asset; GISAXS noted as a technique. | The GISAXS geometry. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The full diffractometer axis set behind the `SamplePositioner` pseudomotor, and whether the goniometric axes warrant a `Goniometer` plus a Diffractometer Assembly (the 8-ID precedent). | A `LinearStage` sample stack, rotation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
-| DET-1 | Blocks-go-live | Which Eiger (4M / 1M / 500K) is the primary XPCS detector vs the spare set, whether a separate along-beam stage sets the sample-to-detector distance (the `Det:SAXS` motor is transverse X/Y only), and the Xspress3 element count. | Eiger 4M primary; all Cameras; no distance stage modelled. | The detector roster and q-range. |
-| CAM-1 | Nice-to-have | Which beam-viewing cameras (the Prosilica x-ray-eyes, the PointGrey, the OAV) are live. | The OAV modelled as a Camera; others noted. | The beam-viewing camera set. |
-| DIAG-1 | Nice-to-have | The scaler flux channel map (which channel is I0) and the BPM / AH401B electrometer channels. | Read-only flux and beam-position probes; channel maps blank. | The FluxCounter and PositionMonitor bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TIMING-1 | Blocks-go-live | The XPCS exposure-gating chain: how the Zebra, the delay generator (`delaygen:DG0:`), and the fast shutter co-time the Eiger frame triggers, and their vendor identities. | One `TimingController` (Zebra) gating the fast shutter and frames; chain detail blank. | The triggering chain. |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| ENERGY-1 | Nice-to-have | Is CHX always fixed-energy, or does anomalous XPCS scan energy as the measurement (the `energy_scan` Capability the catalog anticipates, shared with BMM)? | Fixed-energy; energy_scan deferred (the BMM question). | The energy Capability decision. |
-| TECH-1 | Blocks-go-live | Do the XPCS and small-angle-scattering Methods enter CORA's catalog, or stay deferred? This is the same owner-scope decision 8-ID opened. | Methods deferred (rendered unlinked), no Practice recorded. | The coherent-scattering Method scope. |
diff --git a/docs/deployments/chx/techniques.md b/docs/deployments/chx/techniques.md
deleted file mode 100644
index 35ba4f3f787..00000000000
--- a/docs/deployments/chx/techniques.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Techniques
-
-*What CORA would run at CHX: coherent-scattering techniques, each a [Catalog](../../catalog/methods.md) Method. CHX is the second coherent beamline CORA models, after APS [8-ID](../8-id/techniques.md), and it follows 8-ID's deferral exactly.*
-
-CHX's techniques are coherent-scattering, new to CORA's imaging- and spectroscopy-heritage catalog. As at 8-ID, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| XPCS | `xpcs` | coherent-speckle intensity time series on the Eiger, gated by the Zebra / fast shutter (TIMING-1); Method not yet in catalog |
-| Small-angle scattering | `small_angle_scattering` | static SAXS/WAXS on the same detectors; a Plan setting over the same chain |
-| Grazing-incidence scattering | `small_angle_scattering` | GISAXS: the same scattering Method with the beam steered onto a surface by the `GrazingIncidenceMirror` (GI-1) |
-| Alignment | [`alignment`](../../catalog/methods.md) | beam, mirror, transfocator, and slit tuning; reuses the existing Method |
-
-All three scattering techniques need the [sample stack](sample.md) and the [coherent detectors](detector.md); the fast shutter and Zebra (TIMING-1) gate the exposure.
-
-## Why the Methods stay deferred
-
-8-ID opened the question of whether the XPCS and small-angle-scattering Methods enter CORA's catalog (TECH-1), and `main` deliberately left them pending: the concrete acquisition recipes (correlation time series, frame rates, exposures) join as the deployment approaches the point where CORA drives the beamline. CHX reinforces the case for both Methods at a second facility without coining either, the same earn-the-abstraction discipline the deferred `scanning` (HXN) and `energy_scan` (BMM) Capabilities follow. Because the defining Methods are not in the catalog, CHX records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here), exactly as 8-ID records none at APS; the binding lands when the Method does.
-
-The correlation analysis itself (the g2 / multi-tau computation that turns the frame series into dynamics) is `ComputePort` work, not a beamline Method.
diff --git a/docs/deployments/cms/governance.md b/docs/deployments/cms/governance.md
deleted file mode 100644
index f417c200603..00000000000
--- a/docs/deployments/cms/governance.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Governance
-
-*Who will act at CMS, and the trust shape that will gate it. First cut.*
-
-Governance at CMS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-CMS is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (GOV-1).
-
-## The safety boundary
-
-The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (PSS-1). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-CMS adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
-
-| Hazard class | Where it lands | Tracking |
-| --- | --- | --- |
-| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:11BMA, XF:11BMB) (ENC-1) | (PSS-1) |
-| Vacuum optics and the telescoping flight path | the [Source](source.md) walk and the detector translations | (SUP-1) |
-| In-situ temperature environments | the [Sample](sample.md) thermal / tensile stage | (TEMP-1) |
-
-The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (PSS-1). The vacuum extent and the cooling supply that the optics and flight path depend on are carried pending (SUP-1), and the in-situ temperature range that the Linkam stage brings is carried with it (TEMP-1). None of these is invented; each is recorded against its question.
-
-## When the shape lands
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives CMS, following the [2-BM governance](../2-bm/governance.md) shape. Because CMS shares the NSLS-II EPICS and ophyd floor with FXI, HXN, SRX, BMM, SIX, CHX, ESM, and its twin SMI, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Conduit binds the command surfaces; the Policies bind to the NSLS-II operator roles carried pending at the Site (GOV-1).
diff --git a/docs/deployments/cms/model.md b/docs/deployments/cms/model.md
deleted file mode 100644
index 3c7cee04557..00000000000
--- a/docs/deployments/cms/model.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's CMS content lives, how it models specular reflectivity without a device, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at CMS |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes CMS new
-
-The honest answer is: not much on the scattering, and one real thing on reflectivity. CMS measures soft-matter and thin-film structure by small- and wide-angle scattering (SAXS / WAXS / MAXS), grazing-incidence scattering (GISAXS / GIWAXS), and specular X-ray reflectivity (XR). The scattering overlaps the fleet heavily: CMS is the direct NSLS-II twin of SMI (12-ID), and shares its science axis with Diamond I22 and APS 9-ID / 12-ID. That scattering reuses the existing `Camera` / `Goniometer` / `Slit` / `BeamStop` / `FluxMonitor` / `Monochromator` / `Mirror` vocabulary and contributes reinforcement, not novelty.
-
-CMS's two genuinely distinct contributions are:
-
-- **Specular X-ray reflectivity (XR), the fleet's first hard X-ray reflectometry.** It measures the specularly reflected intensity as a function of incidence angle to recover a film's depth profile. What is interesting for CORA is the mechanism: there is no physical two-theta detector arm. The area detector stays fixed, and the "two-theta" is synthetic, a software region-of-interest that slides across the fixed Pilatus face to where the reflected beam lands as the sample theta (sth) is stepped. So XR is purely a Method, realized over existing devices.
-- **CMS as a further NSLS-II beamline, re-testing the Site and Federation kernel.** Its double-multilayer monochromator reuses the same `Monochromator` Family as the APS 2-BM DMM, reinforcing that reuse.
-
-## No new families
-
-CMS coins no new Family and changes nothing in the catalog.
-
-- **11-BM is a bending-magnet source, not an insertion device** (the 2-BM / 7-BM pattern), so there is no `InsertionDevice` Asset; the machine state is observed through the loose `StorageRing`, and the source detail is `SRC-1`.
-- **The DMM binds `Monochromator`** (a multilayer Bragg optic, the 2-BM double-multilayer precedent, not the soft X-ray `GratingMonochromator`); the incident energy is a `PseudoAxis` over its Bragg angle.
-- **The scattering devices all reuse:** the focusing mirrors bind `Mirror`; the slits bind `Slit`; the attenuator foils bind `Filter`; the sample-orientation circles bind `Goniometer` (sth is the grazing / specular incidence axis); the surface-leveling stage binds `TiltStage`; the SAXS / WAXS / MAXS Pilatus detectors bind `Camera`; the detector translations and the telescoping flight path bind `LinearStage`; the beamstop binds `BeamStop`; the ion chamber, electrometers, and scintillation counter bind `FluxMonitor`; the diamond-diode beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; the per-Asset channel map stays `DIAG-1`); the Linkam stage binds `TemperatureController`; the support table binds `Table`.
-
-## How reflectivity is modelled (no device)
-
-Specular reflectivity (XR) is modelled as a Method (a Practice) over existing devices, not as a new device or a new detector arm:
-
-- the incidence angle is the `Goniometer` sample theta (sth);
-- the reflected-beam intensity is read on the `Camera` (the Pilatus 2M, the same detector as SAXS) over a tracked region-of-interest;
-- the incident flux for normalization is the `FluxMonitor` ion chamber.
-
-The "two-theta" is synthetic: the detector does not move, and the region-of-interest is slid across the fixed detector face to follow where the reflected beam lands as sth is stepped. So XR coins no device, no `Diffractometer` detector arm, and no point detector. The reflectivity Method is **shared with i10** (its soft X-ray RASOR sibling); CMS is the second consumer (`XR-1`). i10 (point-detector, soft X-ray) and CMS (area-detector region-of-interest, hard X-ray) are the rule-of-three pressure that could eventually graduate one reflectivity Method into the catalog; the soft-versus-hard and point-versus-area distinctions are Practice-level adaptations, not a Method split.
-
-## Deliberately not here yet
-
-- **The GIBar sample-exchange arm (`ROBOT-1`).** The multi-axis sample-bar loader is genuinely new automation that no catalog Family covers. Per earn-the-abstraction it is modelled by its stage axes (`LinearStage` / `RotaryStage`) at n=1, and no `SampleExchanger` Family is coined; a second fleet sample robot would earn the abstraction. The garage-indexed pick / place semantics are carried as a note, not modelled.
-- **The auxiliary analog I/O and viewing cameras.** The generic analog diode box is carried as flux / diagnostic channels per its wiring, not a Family; the Prosilica sample-viewing cameras are not modelled in this cut.
-- **The scattering and reflectivity Methods.** Whether SAXS, WAXS, GISAXS, and XR enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. The scattering Methods are shared with i22 / SMI / 9-ID and the reflectivity Method with i10 (`TECH-1`, `XR-1`).
-- **The chamber rebinding and the sth / schi swap.** The beamline_stage configurations rebind the logical goniometer axes across physical PVs at startup, and staff have at times swapped sth and schi; CORA models the logical `Goniometer` and carries the active binding as a setting (`SAMPLE-1`), not as separate Assets.
-- **The simulated devices and full asset-tree scenarios.** No `test_cms_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/cms/notes.md b/docs/deployments/cms/notes.md
new file mode 100644
index 00000000000..5aa061d2bc5
--- /dev/null
+++ b/docs/deployments/cms/notes.md
@@ -0,0 +1,174 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of CMS is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. CMS measures soft-matter and thin-film structure four ways: small-, wide-, and medium-angle scattering (SAXS / WAXS / MAXS), grazing-incidence scattering (GISAXS / GIWAXS), and specular X-ray reflectivity (XR). Three of those four are scattering the fleet already speaks; the Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings any of them into the catalog.
+
+CMS is the NSLS-II twin of [SMI](../smi/notes.md#techniques) (12-ID), and most of what it does reinforces vocabulary CORA already holds. Read this page for the one technique that is genuinely distinct: specular reflectivity.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Small-angle scattering (SAXS) | `small_angle_scattering` | low-Q on the [SAXS Pilatus 2M](detector.md); shares the science axis with [i22](../i22/notes.md#techniques) and [SMI](../smi/notes.md#techniques); Method not yet in catalog (`TECH-1`) |
+| Wide- and medium-angle scattering (WAXS / MAXS) | `wide_angle_scattering` | wider-Q on the [Pilatus 800K heads](detector.md), one powered per configuration; shares the axis with [i22](../i22/notes.md#techniques); Method not yet in catalog (`TECH-1`) |
+| Grazing-incidence scattering (GISAXS / GIWAXS) | `grazing_incidence_scattering` | the same scattering with the sample at a grazing angle on `sth`; shares the axis with APS 9-ID and its NSLS-II twin [SMI](../smi/notes.md#techniques); Method not yet in catalog (`TECH-1`) |
+| Specular X-ray reflectivity (XR) | `reflectivity` | step `sth`, slide a detector region-of-interest in lockstep across the fixed [Pilatus 2M](detector.md), integrate the specular intensity; the second consumer of the reflectivity Method after [i10](../i10/notes.md#techniques) (`XR-1`, `TECH-1`) |
+
+All four techniques need the [incident-beam chain](source.md) (the DMM for energy, the mirrors, slits, and absorber foils), the [sample stack](sample.md) (the [Goniometer](sample.md), surface-leveling tilts, temperature stage), and the [endstation detectors](detector.md) (the Pilatus heads, beamstop, flux monitors). Scattering reads an area frame at one orientation; reflectivity reads the same area detector while the orientation is stepped.
+
+### The scattering is reinforcement, not novelty
+
+SAXS, WAXS, MAXS, and grazing-incidence scattering overlap the fleet heavily. CMS is the direct NSLS-II twin of [SMI](../smi/notes.md#techniques), and the two share their science axis with Diamond [i22](../i22/notes.md#techniques) and APS 9-ID / 12-ID: the same Camera / Goniometer / Slit / BeamStop / FluxMonitor vocabulary, zero new families, the same pending scattering Method slugs. MAXS is a detector-position variant of wide-angle scattering on a second Pilatus 800K head, not a technique of its own. GISAXS / GIWAXS is the same scattering with the sample tipped to a grazing angle on `sth`, a sample-orientation variant rather than a new Capability.
+
+So the scattering side of CMS earns no new abstraction. It reinforces, at a second NSLS-II beamline, the case that the small- and wide-angle scattering Capabilities belong in the catalog (`TECH-1`), the same earn-the-abstraction discipline SMI and i22 already follow. The device Roles exist (the Pilatus heads present Detector, the flux monitors present Sensor), so what stays pending is the science Capability, not a device shape. Because those Capabilities are not yet in the catalog, the matching Site Practices (`CMS_small_angle_scattering_practice`, `CMS_wide_angle_scattering_practice`, `CMS_grazing_incidence_scattering_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
+
+### Specular reflectivity, the distinct contribution
+
+Specular X-ray reflectivity is the one technique CMS brings that the scattering vocabulary does not cover, and CORA models it as a **Method over existing devices**, coining no hardware.
+
+There is no physical two-theta detector arm at CMS, and no point detector. The area detector stays fixed. The measurement steps the sample incidence angle `sth` (the same grazing-incidence angle the GISAXS Method uses) and, in lockstep, slides a software region-of-interest across the face of the fixed [Pilatus 2M](detector.md) to where the specularly reflected beam lands at each angle. The intensity inside that tracked region is integrated; the angle the region sits at is a **synthetic** two-theta computed from the geometry, not a value read off a moving arm. The result is the reflectivity curve: specular intensity versus angle, with the incident flux read on the [endstation flux monitor](detector.md) to normalize.
+
+| Reuses | Role in XR |
+| --- | --- |
+| [Goniometer](sample.md) (`sth`) | steps the specular incidence angle |
+| [Pilatus 2M Camera](detector.md) | read over a tracked region-of-interest; the synthetic two-theta is where that region sits |
+| [endstation FluxMonitor](detector.md) | incident flux, for normalization |
+
+That is the whole device list. XR coins no two-theta arm, no point detector, no new family. The reflectivity Method is the same one [i10](../i10/notes.md#techniques) brought to CORA at its soft X-ray sibling, where the geometry is realized differently; CMS is the **second consumer** of the Method (`XR-1`), realizing it in the hard X-ray regime with no new hardware. As with the scattering Capabilities, the Method is not yet in the catalog and `CMS_reflectivity_practice` is carried pending (`TECH-1`, `XR-1`).
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet. For scattering that is the per-frame exposures, detector distances, beamstop placement, and the azimuthal integration that turns 2D frames into I(Q) curves (the integration and reduction are `ComputePort` work, not beamline Methods). For reflectivity it is the `sth` step list, the region-of-interest tracking model that maps each angle to its place on the fixed Pilatus, and the synthetic two-theta calibration. These join as the deployment approaches the point where CORA drives CMS.
+
+Whether any of these four techniques enters CORA's catalog is an owner-scope decision on [Model](#model): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. The scattering Capabilities are shared pending slugs the fleet already debates; what CMS adds is a second consumer of the pending `reflectivity` Method (i10 plus CMS), which strengthens the case for cataloging it but leaves that an owner decision, not an automatic one (`XR-1`, `TECH-1`). See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at CMS, and the trust shape that will gate it. First cut.*
+
+Governance at CMS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+CMS is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (GOV-1).
+
+### The safety boundary
+
+The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (PSS-1). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+CMS adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
+
+| Hazard class | Where it lands | Tracking |
+| --- | --- | --- |
+| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:11BMA, XF:11BMB) (ENC-1) | (PSS-1) |
+| Vacuum optics and the telescoping flight path | the [Source](source.md) walk and the detector translations | (SUP-1) |
+| In-situ temperature environments | the [Sample](sample.md) thermal / tensile stage | (TEMP-1) |
+
+The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (PSS-1). The vacuum extent and the cooling supply that the optics and flight path depend on are carried pending (SUP-1), and the in-situ temperature range that the Linkam stage brings is carried with it (TEMP-1). None of these is invented; each is recorded against its question.
+
+### When the shape lands
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives CMS, following the [2-BM governance](../2-bm/governance.md) shape. Because CMS shares the NSLS-II EPICS and ophyd floor with FXI, HXN, SRX, BMM, SIX, CHX, ESM, and its twin SMI, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Conduit binds the command surfaces; the Policies bind to the NSLS-II operator roles carried pending at the Site (GOV-1).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's CMS content lives, how it models specular reflectivity without a device, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at CMS |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes CMS new
+
+The honest answer is: not much on the scattering, and one real thing on reflectivity. CMS measures soft-matter and thin-film structure by small- and wide-angle scattering (SAXS / WAXS / MAXS), grazing-incidence scattering (GISAXS / GIWAXS), and specular X-ray reflectivity (XR). The scattering overlaps the fleet heavily: CMS is the direct NSLS-II twin of SMI (12-ID), and shares its science axis with Diamond I22 and APS 9-ID / 12-ID. That scattering reuses the existing `Camera` / `Goniometer` / `Slit` / `BeamStop` / `FluxMonitor` / `Monochromator` / `Mirror` vocabulary and contributes reinforcement, not novelty.
+
+CMS's two genuinely distinct contributions are:
+
+- **Specular X-ray reflectivity (XR), the fleet's first hard X-ray reflectometry.** It measures the specularly reflected intensity as a function of incidence angle to recover a film's depth profile. What is interesting for CORA is the mechanism: there is no physical two-theta detector arm. The area detector stays fixed, and the "two-theta" is synthetic, a software region-of-interest that slides across the fixed Pilatus face to where the reflected beam lands as the sample theta (sth) is stepped. So XR is purely a Method, realized over existing devices.
+- **CMS as a further NSLS-II beamline, re-testing the Site and Federation kernel.** Its double-multilayer monochromator reuses the same `Monochromator` Family as the APS 2-BM DMM, reinforcing that reuse.
+
+### No new families
+
+CMS coins no new Family and changes nothing in the catalog.
+
+- **11-BM is a bending-magnet source, not an insertion device** (the 2-BM / 7-BM pattern), so there is no `InsertionDevice` Asset; the machine state is observed through the loose `StorageRing`, and the source detail is `SRC-1`.
+- **The DMM binds `Monochromator`** (a multilayer Bragg optic, the 2-BM double-multilayer precedent, not the soft X-ray `GratingMonochromator`); the incident energy is a `PseudoAxis` over its Bragg angle.
+- **The scattering devices all reuse:** the focusing mirrors bind `Mirror`; the slits bind `Slit`; the attenuator foils bind `Filter`; the sample-orientation circles bind `Goniometer` (sth is the grazing / specular incidence axis); the surface-leveling stage binds `TiltStage`; the SAXS / WAXS / MAXS Pilatus detectors bind `Camera`; the detector translations and the telescoping flight path bind `LinearStage`; the beamstop binds `BeamStop`; the ion chamber, electrometers, and scintillation counter bind `FluxMonitor`; the diamond-diode beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; the per-Asset channel map stays `DIAG-1`); the Linkam stage binds `TemperatureController`; the support table binds `Table`.
+
+### How reflectivity is modelled (no device)
+
+Specular reflectivity (XR) is modelled as a Method (a Practice) over existing devices, not as a new device or a new detector arm:
+
+- the incidence angle is the `Goniometer` sample theta (sth);
+- the reflected-beam intensity is read on the `Camera` (the Pilatus 2M, the same detector as SAXS) over a tracked region-of-interest;
+- the incident flux for normalization is the `FluxMonitor` ion chamber.
+
+The "two-theta" is synthetic: the detector does not move, and the region-of-interest is slid across the fixed detector face to follow where the reflected beam lands as sth is stepped. So XR coins no device, no `Diffractometer` detector arm, and no point detector. The reflectivity Method is **shared with i10** (its soft X-ray RASOR sibling); CMS is the second consumer (`XR-1`). i10 (point-detector, soft X-ray) and CMS (area-detector region-of-interest, hard X-ray) are the rule-of-three pressure that could eventually graduate one reflectivity Method into the catalog; the soft-versus-hard and point-versus-area distinctions are Practice-level adaptations, not a Method split.
+
+### Deliberately not here yet
+
+- **The GIBar sample-exchange arm (`ROBOT-1`).** The multi-axis sample-bar loader is genuinely new automation that no catalog Family covers. Per earn-the-abstraction it is modelled by its stage axes (`LinearStage` / `RotaryStage`) at n=1, and no `SampleExchanger` Family is coined; a second fleet sample robot would earn the abstraction. The garage-indexed pick / place semantics are carried as a note, not modelled.
+- **The auxiliary analog I/O and viewing cameras.** The generic analog diode box is carried as flux / diagnostic channels per its wiring, not a Family; the Prosilica sample-viewing cameras are not modelled in this cut.
+- **The scattering and reflectivity Methods.** Whether SAXS, WAXS, GISAXS, and XR enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. The scattering Methods are shared with i22 / SMI / 9-ID and the reflectivity Method with i10 (`TECH-1`, `XR-1`).
+- **The chamber rebinding and the sth / schi swap.** The beamline_stage configurations rebind the logical goniometer axes across physical PVs at startup, and staff have at times swapped sth and schi; CORA models the logical `Goniometer` and carries the active binding as a setting (`SAMPLE-1`), not as separate Assets.
+- **The simulated devices and full asset-tree scenarios.** No `test_cms_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the CMS team to confirm before the model can be trusted.*
+
+CMS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/cms-profile-collection](https://github.com/NSLS2/cms-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the PV zones XF:11BMA (first optics) and XF:11BMB (endstation) two separate hutches? | Two enclosures: a `cms-optics` zone and the `cms-endstation` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The 11-BM source: a bending magnet or a three-pole wiggler (absent from the profile collection as a device). | A bending-magnet source, observed only through the machine state. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state CMS reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The DMM multilayer d-spacing, the energy range (calibrations near 13.5 keV), and the energy partition rule. | A double-multilayer `Monochromator`; the energy is a `PseudoAxis` over the Bragg angle; d-spacing pending. | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The toroidal and elliptical mirror coatings and bend mechanisms. | Focusing mirrors bound to `Mirror`; coatings and bend pending. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis roles of each slit (the FOE slit and the five endstation JJ slits, including the s4 transmission / grazing geometry presets). | Four-blade and center / gap slits bound to `Slit`. | The slit Asset detail. |
+| ATTN-1 | Nice-to-have | The attenuator foil set (the eight pneumatic absorbers) and whether it folds into `Filter` or earns a distinct `Attenuator` kind (the fleet-wide question). | The foils bound to `Filter` (the i03 / i15-1 precedent). | The attenuator's catalog home. |
+
+### Sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The sample-goniometer axes, the grazing / specular incidence axis (the historical sth versus schi swap), and the chamber rebinding (the beamline_stage configurations remap the logical axes across physical PVs at startup). | A `Goniometer` with sth as the incidence axis; the swap and the rebinding carried as settings. | The sample-stage modelling. |
+| ROBOT-1 | Nice-to-have | The GIBar sample-exchange arm (a multi-axis sample-bar loader) and whether it earns a `SampleExchanger` Family or stays modelled as stage axes. | Modelled as `LinearStage` / `RotaryStage` axes at n=1; no `SampleExchanger` Family coined pending a second fleet sample robot. | The sample-exchange modelling; the CORA family decision is on [Model](#deliberately-not-here-yet). |
+| TEMP-1 | Nice-to-have | The Linkam thermal / tensile stage temperature range and the tensile-load axis. | A `TemperatureController` Asset presenting the `Regulator` Role; range and load axis pending. | The temperature-environment modelling. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The SAXS / WAXS / MAXS Pilatus detector assignment (which 800K head is powered per configuration), the detector-distance calibrations, and the flux / beam-position channel map. | Three `Camera` Assets (Pilatus 2M SAXS, two 800K WAXS / MAXS); the monitors bind `FluxMonitor` and the diode beam-position monitor the graduated catalog `PositionMonitor`. | The detector modelling. |
+| XR-1 | Blocks-go-live | The specular reflectivity (XR) realization: a fixed area detector read over a software region-of-interest tracking the reflected beam as the sample theta is stepped, with no physical two-theta arm. | XR is a Method over `Goniometer` (sth) + `Camera` (the Pilatus region) + `FluxMonitor`; no device coined; the reflectivity Method is shared with i10. | The reflectivity modelling; the CORA decision is on [Model](#deliberately-not-here-yet). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the optics, the sample chamber, the SAXS flight path) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do the scattering and reflectivity techniques (SAXS, WAXS, GISAXS, XR) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; the scattering Methods are shared with i22 / SMI / 9-ID and the reflectivity Method with i10; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/cms/questions.md b/docs/deployments/cms/questions.md
deleted file mode 100644
index e0ead6b804d..00000000000
--- a/docs/deployments/cms/questions.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Open questions
-
-*What CORA needs the CMS team to confirm before the model can be trusted.*
-
-CMS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/cms-profile-collection](https://github.com/NSLS2/cms-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the PV zones XF:11BMA (first optics) and XF:11BMB (endstation) two separate hutches? | Two enclosures: a `cms-optics` zone and the `cms-endstation` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The 11-BM source: a bending magnet or a three-pole wiggler (absent from the profile collection as a device). | A bending-magnet source, observed only through the machine state. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state CMS reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The DMM multilayer d-spacing, the energy range (calibrations near 13.5 keV), and the energy partition rule. | A double-multilayer `Monochromator`; the energy is a `PseudoAxis` over the Bragg angle; d-spacing pending. | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The toroidal and elliptical mirror coatings and bend mechanisms. | Focusing mirrors bound to `Mirror`; coatings and bend pending. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis roles of each slit (the FOE slit and the five endstation JJ slits, including the s4 transmission / grazing geometry presets). | Four-blade and center / gap slits bound to `Slit`. | The slit Asset detail. |
-| ATTN-1 | Nice-to-have | The attenuator foil set (the eight pneumatic absorbers) and whether it folds into `Filter` or earns a distinct `Attenuator` kind (the fleet-wide question). | The foils bound to `Filter` (the i03 / i15-1 precedent). | The attenuator's catalog home. |
-
-## Sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The sample-goniometer axes, the grazing / specular incidence axis (the historical sth versus schi swap), and the chamber rebinding (the beamline_stage configurations remap the logical axes across physical PVs at startup). | A `Goniometer` with sth as the incidence axis; the swap and the rebinding carried as settings. | The sample-stage modelling. |
-| ROBOT-1 | Nice-to-have | The GIBar sample-exchange arm (a multi-axis sample-bar loader) and whether it earns a `SampleExchanger` Family or stays modelled as stage axes. | Modelled as `LinearStage` / `RotaryStage` axes at n=1; no `SampleExchanger` Family coined pending a second fleet sample robot. | The sample-exchange modelling; the CORA family decision is on [Model](model.md#deliberately-not-here-yet). |
-| TEMP-1 | Nice-to-have | The Linkam thermal / tensile stage temperature range and the tensile-load axis. | A `TemperatureController` Asset presenting the `Regulator` Role; range and load axis pending. | The temperature-environment modelling. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The SAXS / WAXS / MAXS Pilatus detector assignment (which 800K head is powered per configuration), the detector-distance calibrations, and the flux / beam-position channel map. | Three `Camera` Assets (Pilatus 2M SAXS, two 800K WAXS / MAXS); the monitors bind `FluxMonitor` and the diode beam-position monitor the graduated catalog `PositionMonitor`. | The detector modelling. |
-| XR-1 | Blocks-go-live | The specular reflectivity (XR) realization: a fixed area detector read over a software region-of-interest tracking the reflected beam as the sample theta is stepped, with no physical two-theta arm. | XR is a Method over `Goniometer` (sth) + `Camera` (the Pilatus region) + `FluxMonitor`; no device coined; the reflectivity Method is shared with i10. | The reflectivity modelling; the CORA decision is on [Model](model.md#deliberately-not-here-yet). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the optics, the sample chamber, the SAXS flight path) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do the scattering and reflectivity techniques (SAXS, WAXS, GISAXS, XR) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; the scattering Methods are shared with i22 / SMI / 9-ID and the reflectivity Method with i10; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/cms/techniques.md b/docs/deployments/cms/techniques.md
deleted file mode 100644
index 59a07536ed5..00000000000
--- a/docs/deployments/cms/techniques.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Techniques
-
-*What the modelled part of CMS is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. CMS measures soft-matter and thin-film structure four ways: small-, wide-, and medium-angle scattering (SAXS / WAXS / MAXS), grazing-incidence scattering (GISAXS / GIWAXS), and specular X-ray reflectivity (XR). Three of those four are scattering the fleet already speaks; the Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings any of them into the catalog.
-
-CMS is the NSLS-II twin of [SMI](../smi/techniques.md) (12-ID), and most of what it does reinforces vocabulary CORA already holds. Read this page for the one technique that is genuinely distinct: specular reflectivity.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Small-angle scattering (SAXS) | `small_angle_scattering` | low-Q on the [SAXS Pilatus 2M](detector.md); shares the science axis with [i22](../i22/techniques.md) and [SMI](../smi/techniques.md); Method not yet in catalog (`TECH-1`) |
-| Wide- and medium-angle scattering (WAXS / MAXS) | `wide_angle_scattering` | wider-Q on the [Pilatus 800K heads](detector.md), one powered per configuration; shares the axis with [i22](../i22/techniques.md); Method not yet in catalog (`TECH-1`) |
-| Grazing-incidence scattering (GISAXS / GIWAXS) | `grazing_incidence_scattering` | the same scattering with the sample at a grazing angle on `sth`; shares the axis with APS 9-ID and its NSLS-II twin [SMI](../smi/techniques.md); Method not yet in catalog (`TECH-1`) |
-| Specular X-ray reflectivity (XR) | `reflectivity` | step `sth`, slide a detector region-of-interest in lockstep across the fixed [Pilatus 2M](detector.md), integrate the specular intensity; the second consumer of the reflectivity Method after [i10](../i10/techniques.md) (`XR-1`, `TECH-1`) |
-
-All four techniques need the [incident-beam chain](source.md) (the DMM for energy, the mirrors, slits, and absorber foils), the [sample stack](sample.md) (the [Goniometer](sample.md), surface-leveling tilts, temperature stage), and the [endstation detectors](detector.md) (the Pilatus heads, beamstop, flux monitors). Scattering reads an area frame at one orientation; reflectivity reads the same area detector while the orientation is stepped.
-
-## The scattering is reinforcement, not novelty
-
-SAXS, WAXS, MAXS, and grazing-incidence scattering overlap the fleet heavily. CMS is the direct NSLS-II twin of [SMI](../smi/techniques.md), and the two share their science axis with Diamond [i22](../i22/techniques.md) and APS 9-ID / 12-ID: the same Camera / Goniometer / Slit / BeamStop / FluxMonitor vocabulary, zero new families, the same pending scattering Method slugs. MAXS is a detector-position variant of wide-angle scattering on a second Pilatus 800K head, not a technique of its own. GISAXS / GIWAXS is the same scattering with the sample tipped to a grazing angle on `sth`, a sample-orientation variant rather than a new Capability.
-
-So the scattering side of CMS earns no new abstraction. It reinforces, at a second NSLS-II beamline, the case that the small- and wide-angle scattering Capabilities belong in the catalog (`TECH-1`), the same earn-the-abstraction discipline SMI and i22 already follow. The device Roles exist (the Pilatus heads present Detector, the flux monitors present Sensor), so what stays pending is the science Capability, not a device shape. Because those Capabilities are not yet in the catalog, the matching Site Practices (`CMS_small_angle_scattering_practice`, `CMS_wide_angle_scattering_practice`, `CMS_grazing_incidence_scattering_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
-
-## Specular reflectivity, the distinct contribution
-
-Specular X-ray reflectivity is the one technique CMS brings that the scattering vocabulary does not cover, and CORA models it as a **Method over existing devices**, coining no hardware.
-
-There is no physical two-theta detector arm at CMS, and no point detector. The area detector stays fixed. The measurement steps the sample incidence angle `sth` (the same grazing-incidence angle the GISAXS Method uses) and, in lockstep, slides a software region-of-interest across the face of the fixed [Pilatus 2M](detector.md) to where the specularly reflected beam lands at each angle. The intensity inside that tracked region is integrated; the angle the region sits at is a **synthetic** two-theta computed from the geometry, not a value read off a moving arm. The result is the reflectivity curve: specular intensity versus angle, with the incident flux read on the [endstation flux monitor](detector.md) to normalize.
-
-| Reuses | Role in XR |
-| --- | --- |
-| [Goniometer](sample.md) (`sth`) | steps the specular incidence angle |
-| [Pilatus 2M Camera](detector.md) | read over a tracked region-of-interest; the synthetic two-theta is where that region sits |
-| [endstation FluxMonitor](detector.md) | incident flux, for normalization |
-
-That is the whole device list. XR coins no two-theta arm, no point detector, no new family. The reflectivity Method is the same one [i10](../i10/techniques.md) brought to CORA at its soft X-ray sibling, where the geometry is realized differently; CMS is the **second consumer** of the Method (`XR-1`), realizing it in the hard X-ray regime with no new hardware. As with the scattering Capabilities, the Method is not yet in the catalog and `CMS_reflectivity_practice` is carried pending (`TECH-1`, `XR-1`).
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet. For scattering that is the per-frame exposures, detector distances, beamstop placement, and the azimuthal integration that turns 2D frames into I(Q) curves (the integration and reduction are `ComputePort` work, not beamline Methods). For reflectivity it is the `sth` step list, the region-of-interest tracking model that maps each angle to its place on the fixed Pilatus, and the synthetic two-theta calibration. These join as the deployment approaches the point where CORA drives CMS.
-
-Whether any of these four techniques enters CORA's catalog is an owner-scope decision on [Model](model.md): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. The scattering Capabilities are shared pending slugs the fleet already debates; what CMS adds is a second consumer of the pending `reflectivity` Method (i10 plus CMS), which strengthens the case for cataloging it but leaves that an owner decision, not an automatic one (`XR-1`, `TECH-1`). See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/cristallina/governance.md b/docs/deployments/cristallina/governance.md
deleted file mode 100644
index f4e0cdd95d4..00000000000
--- a/docs/deployments/cristallina/governance.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Governance
-
-*Who would act at Cristallina and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
-
-Cristallina's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `slic` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Cristallina inherits it. Cristallina shares its Site, its Aramis source, and its safety posture with the sibling [Alvra](../alvra/governance.md) and [Bernina](../bernina/governance.md) stations, so most of the governance shape is the PSI-Site shape; what is worth drawing out is the shared-source boundary and the high-field-magnet hazard.
-
-## The shared Aramis source and the optics zone
-
-Cristallina is the third of three co-equal stations (with Alvra and Bernina) on one Aramis source, beam routed to one at a time (TOPO-1). The `SAROP31` optics hutch conditions the beam on the way to Cristallina, but the source upstream is shared. That makes the optics-hutch Zone a shared-access boundary, the same question Alvra and Bernina raise: who holds the permit when the beam is routed to a neighbour, and how the routing state gates each station's commands. With three stations now modelled on the one source, the routing state is a three-way selection, not a pair. The SwissFEL PSS search-and-secure permit signals are not in the `slic` manifest and are carried pending (PSS-1). Cristallina's enclosure structure (the shared `SAROP31` optics hutch plus the Cristallina experiment hutch) is carried `confirm` because the `slic` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
-
-## The high-field-magnet Clearance
-
-Cristallina's defining hazard is not a laser (the `slic` source has no pump-probe laser, LASER-1) but the **vector superconducting magnet** and its cryogens. The DilSc dilution refrigerator runs an Oxford Mercury iPS magnet to 5.2 Tesla on the z-axis, cooled by liquid helium. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before high-field work), the same posture [ESRF ID32](../id32/governance.md) takes for its 9 T XMCD magnet and its liquid-helium plant. This is distinct from whether the magnet is a driven Asset: the device binds the graduated `Magnet` Family (a further consumer, the per-Asset field detail pending, MAG-1), while the personnel- and quench-safety permit is a Clearance. The two coexist, the same way the laser device and the laser Clearance coexist at Alvra and Bernina.
-
-## What is not modelled
-
-- **Trust instantiation.** No scenario instantiates Cristallina trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-- **The magnet as a safety-driven Asset.** The vector magnet is modelled as a hazard via a Clearance, not as an Asset CORA drives for safety (the ID32 magnet and the Alvra / Bernina laser precedent). Its field setpoints are an experiment concern; its safety is a permit.
-- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
-
-People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](questions.md) for the governance items still to confirm.
diff --git a/docs/deployments/cristallina/model.md b/docs/deployments/cristallina/model.md
deleted file mode 100644
index 59daa1d86f9..00000000000
--- a/docs/deployments/cristallina/model.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's Cristallina content lives, how the diffractometers reuse the graduated Assembly and the vector magnet binds an earned Family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at Cristallina |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The headline: no new Family, three things tested
-
-Cristallina coins **no new Family**, the same finding as Alvra and Bernina. But it tests the model against three things the prior PSI stations did not have, and the interest is in how each is absorbed by existing shapes.
-
-### The diffractometers reuse the graduated Assembly (DIFF-1)
-
-Cristallina-Q has two diffraction platforms: DM1 (the dilution-fridge diffractometer, `SARES31-GPS`) and DM2 (the pulsed-magnet diffractometer, `SARES32-GPS`). Both are built by the `slic` `Diffractometer` driver from ECMC servo-motor axes (twotheta / theta plus base and sample translations; DM2 adds rot_x / rot_z swivels). As at [Bernina](../bernina/model.md), each is the graduated [`Diffractometer` Assembly](../../catalog/assemblies.md): a composed `Goniometer` (the sample circles) plus a `RotaryStage` detector-arm circle plus a reciprocal-space `PseudoAxis`. The GPS / XRD platforms at Bernina were the Assembly's third and fourth bindings; the Cristallina DM1 / DM2 are its fifth and sixth. No new Family or Assembly is coined (DIFF-1; the reciprocal-space partition rule is DIFF-2). DM2's PV channels are commented out of the active `slic` config, so it is carried as present-hardware-not-acquired (DISABLED-1).
-
-### The vector magnet is a further `Magnet` consumer (MAG-1)
-
-The DilSc sample environment is a dilution refrigerator with a 3-axis vector superconducting magnet (an Oxford Mercury iPS, field limits X,Y = ±0.6 T and Z = ±5.2 T). The magnet binds the **graduated `Magnet`** Family, whose rule-of-three was earned across 4-ID, i10-1, and ESRF ID32 (the 9 T XMCD magnet). Cristallina is a **further consumer**, binding the catalog Family like any other (MAG-1 now covers only the per-Asset field ranges and control handles). The `Magnet` Family presents the `Regulator` Role, the field a settable process variable, and the LakeShore 372 thermometry / heater binds the **graduated `TemperatureController`** Family (also presents the Regulator Role), the ID32 VTI precedent. The vector geometry (three independently-ramped field axes) is a richer setting than the single-axis magnets, but it is a per-Asset setting, not a Family split, the same way the diffractometer axis counts are.
-
-### The absent pump-probe laser (LASER-1, reframed)
-
-Alvra and Bernina each carry a pump-probe `Laser` and an arrival-time monitor. Cristallina's `slic` source has neither: no `SLAAR` / `PALM` / `PSEN` devices appear, and the only laser is the X-ray alignment laser (`SAROP31-OLAS147`, a catalog `Laser`). Pump-probe timing is mediated by the CTA sequencer (`SAR-CCTA-ESC`) and the EVR, with a server-side pulse-tube synchronization service (`oscillations.psi.ch`). So this cut models no pump-probe-laser Asset. Whether Cristallina has a pump-probe laser in a different controls layer (as Alvra and Bernina do in `eco`'s `loptics`) is carried as an open question rather than invented (LASER-1).
-
-## The provenance boundary: slic, in-repo
-
-Cristallina is CORA's first deployment mined from `slic` rather than `eco`. The boundary is cleaner than Bernina's: where Bernina's `eco` config loaded its device list from a non-public JSON, Cristallina's `slic` repo keeps the device identities, axes, and PV prefixes as in-repo Python literals. What is non-public is only runtime state, not device definitions: the working directory and data paths, a PSSS motion helper script, the DilSc SECoP / Frappy magnet server (`dilsc.psi.ch:5000`, an alternative to the live EPICS driver), and the pulse-tube synchronization HTTP service (server-side). Those are recorded under `software_iocs_not_modeled` and ENV-1, not modelled.
-
-One provenance caution shapes the inventory: many `slic` drivers are instantiated but their PV channels are commented out of the active tuples (DM2, several SmarAct stages, the Attocube, the PuMa stack, the cameras). These are carried as present-hardware-not-acquired where carried at all (DISABLED-1), not as live Assets.
-
-## The architectural gap register (shared with the other XFELs)
-
-These are the same deferrals Alvra and Bernina recorded; Cristallina re-confirms them a third time at PSI, now in a vector-magnet diffraction context.
-
-- **One switched Aramis source feeding co-equal stations (TOPO-1).** Now the full triad: Cristallina is the third root Unit on the same source as Alvra and Bernina. Three co-equal Units sharing one upstream source has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model.
-- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The `sf-daq` records a free-running `bsread` stream of per-shot frames; CORA's poll-to-Done acquisition has no representation for it. The Run stays the provenance envelope and the per-shot plane is a referenced `Dataset`.
-- **Beam-synchronous event timing (TIMING-1).** The CTA sequencer and EVR gate acquisition at beam rate (and here also mediate the pump-probe delay, in the absence of a laser device); `TimingController` carries the device but the trigger pattern has no typed home.
-
-## What is deliberately not here yet (modelling, as at the other exercises)
-
-- **New Capabilities / Methods and vendor Models.** Cristallina earns no catalog change; the diffraction and serial-crystallography recipes are carried pending on the [PSI Practices](../psi/index.md). No catalog Model is bound.
-- **The pump-probe laser layer (LASER-1).** Absent from `slic`; not invented.
-- **The vector-magnet field ranges and control handles (MAG-1).** The `Magnet` Family has graduated (Cristallina is a further consumer); only the per-Asset field detail stays pending.
-- **The disabled stages (DISABLED-1).** DM2, the SmarAct / Attocube / PuMa stages, and the cameras are instantiated but commented out of the active config; carried as present-hardware, not live Assets.
-- **The serial-crystallography sample delivery (SAMPLE-1).** Beyond the fast XY stage, the Cristallina-MX delivery is deferred.
-- **The transmission-readback cross-reference (XREF-1).** The front-end attenuator's transmission readbacks alias to `SAROP31-OATT053`; carried `confirm`.
-- **Integration scenarios.** No `test_cristallina_*.py` registers Cristallina Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
diff --git a/docs/deployments/cristallina/notes.md b/docs/deployments/cristallina/notes.md
new file mode 100644
index 00000000000..339354b024d
--- /dev/null
+++ b/docs/deployments/cristallina/notes.md
@@ -0,0 +1,153 @@
+# Notes
+
+## Techniques
+
+*What Cristallina is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
+
+Cristallina runs two technique families, neither of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
+
+### Time-resolved hard X-ray diffraction and scattering (quantum materials)
+
+Cristallina's reason for existing. The Cristallina-Q endstation studies quantum materials: their structural and electronic response is read by diffraction and scattering, shot by shot, in a controlled low-temperature, high-magnetic-field environment. The sample is oriented and the detector positioned by the DM1 dilution-fridge or DM2 pulsed-magnet diffractometer, inside the DilSc dilution refrigerator and its vector superconducting magnet.
+
+- **Spine shape:** a `diffraction` Method binding the diffractometer (a `Goniometer` for the sample circles, a `RotaryStage` 2-theta detector arm, and a reciprocal-space `PseudoAxis`), composed through the graduated `Diffractometer` Assembly (DIFF-1), over a per-shot acquisition, with the sample-environment state (temperature from the LakeShore 372, field from the vector magnet) as conditions. It shares the `diffraction` Method Bernina introduced.
+- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). A time-resolved diffraction run is a free-running shot stream tagged by pulse-ID, not a trajectory of points. The diffractometer is covered by the existing Assembly, and the sample environment by the `TemperatureController` Family and the graduated `Magnet` Family; the acquisition is the gap.
+
+The vector magnet is what distinguishes Cristallina-Q from Bernina's diffraction: the experiment sweeps not just delay and orientation but a three-axis magnetic field, in a dilution-fridge temperature regime. That sample environment is modelled (the LakeShore as `TemperatureController`, the magnet as the graduated `Magnet` Family, a further consumer, MAG-1) and gated by a Clearance hazard, but it adds no new technique-modelling shape beyond the conditions a Run already carries.
+
+### Serial femtosecond crystallography
+
+The Cristallina-MX endstation runs serial crystallography: microcrystals are delivered onto the fast XY sample stage and each X-ray pulse records a single-shot diffraction pattern. It shares the `serial_crystallography` Method LCLS-MFX and Alvra carry.
+
+- **Spine shape:** a `serial_crystallography` Method binding the fast sample stage, the focusing optics, and the 8M Jungfrau, over a free-running per-shot acquisition.
+- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1), the same as for the other XFEL serial-crystallography exercises. The sample delivery beyond the fast stage is endstation-specific and deferred (SAMPLE-1).
+
+### Why neither is in the catalog yet
+
+The catalog's Methods are all tomography-family. An XFEL diffraction / crystallography station shares none of them, and coining XFEL Methods now, before the per-shot acquisition axis they depend on exists (DAQ-1), would be inventing recipes for a spine that cannot yet run them. So each is carried pending, reusing the Method name Bernina or LCLS-MFX named for it. That a third PSI station, on a different controls library (`slic`) and with a novel sample environment (the vector magnet), reaches the same acquisition gaps is the reinforcement Cristallina adds: the gaps are about the XFEL acquisition paradigm, not the technique or the controls house style. See [Model](#model) for the gap register, the `Diffractometer` Assembly design, and the `Magnet` rule-of-three.
+
+## Governance
+
+*Who would act at Cristallina and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
+
+Cristallina's principals are facility principals at the [PSI Site](../psi/index.md), not beamline-local: the SwissFEL instrument-scientist and operator pool, and the PSI safety-review body. Both are carried pending in the [site descriptor](../psi/index.md) until the PSI structure is confirmed; the `slic` device library is a controls library, not an organizational record, so it exposes no human roster (GOV-1). CORA's role kernel (the five-role authorization model) is facility-invariant, so Cristallina inherits it. Cristallina shares its Site, its Aramis source, and its safety posture with the sibling [Alvra](../alvra/notes.md#governance) and [Bernina](../bernina/notes.md#governance) stations, so most of the governance shape is the PSI-Site shape; what is worth drawing out is the shared-source boundary and the high-field-magnet hazard.
+
+### The shared Aramis source and the optics zone
+
+Cristallina is the third of three co-equal stations (with Alvra and Bernina) on one Aramis source, beam routed to one at a time (TOPO-1). The `SAROP31` optics hutch conditions the beam on the way to Cristallina, but the source upstream is shared. That makes the optics-hutch Zone a shared-access boundary, the same question Alvra and Bernina raise: who holds the permit when the beam is routed to a neighbour, and how the routing state gates each station's commands. With three stations now modelled on the one source, the routing state is a three-way selection, not a pair. The SwissFEL PSS search-and-secure permit signals are not in the `slic` manifest and are carried pending (PSS-1). Cristallina's enclosure structure (the shared `SAROP31` optics hutch plus the Cristallina experiment hutch) is carried `confirm` because the `slic` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
+
+### The high-field-magnet Clearance
+
+Cristallina's defining hazard is not a laser (the `slic` source has no pump-probe laser, LASER-1) but the **vector superconducting magnet** and its cryogens. The DilSc dilution refrigerator runs an Oxford Mercury iPS magnet to 5.2 Tesla on the z-axis, cooled by liquid helium. CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before high-field work), the same posture [ESRF ID32](../id32/notes.md#governance) takes for its 9 T XMCD magnet and its liquid-helium plant. This is distinct from whether the magnet is a driven Asset: the device binds the graduated `Magnet` Family (a further consumer, the per-Asset field detail pending, MAG-1), while the personnel- and quench-safety permit is a Clearance. The two coexist, the same way the laser device and the laser Clearance coexist at Alvra and Bernina.
+
+### What is not modelled
+
+- **Trust instantiation.** No scenario instantiates Cristallina trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+- **The magnet as a safety-driven Asset.** The vector magnet is modelled as a hazard via a Clearance, not as an Asset CORA drives for safety (the ID32 magnet and the Alvra / Bernina laser precedent). Its field setpoints are an experiment concern; its safety is a permit.
+- **The DAQ and acquisition software as principals.** The SwissFEL `sf-daq`, `bsread`, and the `slic` scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
+
+People and agents are facility principals at the [PSI Site](../psi/index.md); see [Open questions](#open-questions) for the governance items still to confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's Cristallina content lives, how the diffractometers reuse the graduated Assembly and the vector magnet binds an earned Family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at Cristallina |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The headline: no new Family, three things tested
+
+Cristallina coins **no new Family**, the same finding as Alvra and Bernina. But it tests the model against three things the prior PSI stations did not have, and the interest is in how each is absorbed by existing shapes.
+
+#### The diffractometers reuse the graduated Assembly (DIFF-1)
+
+Cristallina-Q has two diffraction platforms: DM1 (the dilution-fridge diffractometer, `SARES31-GPS`) and DM2 (the pulsed-magnet diffractometer, `SARES32-GPS`). Both are built by the `slic` `Diffractometer` driver from ECMC servo-motor axes (twotheta / theta plus base and sample translations; DM2 adds rot_x / rot_z swivels). As at [Bernina](../bernina/notes.md#model), each is the graduated [`Diffractometer` Assembly](../../catalog/assemblies.md): a composed `Goniometer` (the sample circles) plus a `RotaryStage` detector-arm circle plus a reciprocal-space `PseudoAxis`. The GPS / XRD platforms at Bernina were the Assembly's third and fourth bindings; the Cristallina DM1 / DM2 are its fifth and sixth. No new Family or Assembly is coined (DIFF-1; the reciprocal-space partition rule is DIFF-2). DM2's PV channels are commented out of the active `slic` config, so it is carried as present-hardware-not-acquired (DISABLED-1).
+
+#### The vector magnet is a further `Magnet` consumer (MAG-1)
+
+The DilSc sample environment is a dilution refrigerator with a 3-axis vector superconducting magnet (an Oxford Mercury iPS, field limits X,Y = ±0.6 T and Z = ±5.2 T). The magnet binds the **graduated `Magnet`** Family, whose rule-of-three was earned across 4-ID, i10-1, and ESRF ID32 (the 9 T XMCD magnet). Cristallina is a **further consumer**, binding the catalog Family like any other (MAG-1 now covers only the per-Asset field ranges and control handles). The `Magnet` Family presents the `Regulator` Role, the field a settable process variable, and the LakeShore 372 thermometry / heater binds the **graduated `TemperatureController`** Family (also presents the Regulator Role), the ID32 VTI precedent. The vector geometry (three independently-ramped field axes) is a richer setting than the single-axis magnets, but it is a per-Asset setting, not a Family split, the same way the diffractometer axis counts are.
+
+#### The absent pump-probe laser (LASER-1, reframed)
+
+Alvra and Bernina each carry a pump-probe `Laser` and an arrival-time monitor. Cristallina's `slic` source has neither: no `SLAAR` / `PALM` / `PSEN` devices appear, and the only laser is the X-ray alignment laser (`SAROP31-OLAS147`, a catalog `Laser`). Pump-probe timing is mediated by the CTA sequencer (`SAR-CCTA-ESC`) and the EVR, with a server-side pulse-tube synchronization service (`oscillations.psi.ch`). So this cut models no pump-probe-laser Asset. Whether Cristallina has a pump-probe laser in a different controls layer (as Alvra and Bernina do in `eco`'s `loptics`) is carried as an open question rather than invented (LASER-1).
+
+### The provenance boundary: slic, in-repo
+
+Cristallina is CORA's first deployment mined from `slic` rather than `eco`. The boundary is cleaner than Bernina's: where Bernina's `eco` config loaded its device list from a non-public JSON, Cristallina's `slic` repo keeps the device identities, axes, and PV prefixes as in-repo Python literals. What is non-public is only runtime state, not device definitions: the working directory and data paths, a PSSS motion helper script, the DilSc SECoP / Frappy magnet server (`dilsc.psi.ch:5000`, an alternative to the live EPICS driver), and the pulse-tube synchronization HTTP service (server-side). Those are recorded under `software_iocs_not_modeled` and ENV-1, not modelled.
+
+One provenance caution shapes the inventory: many `slic` drivers are instantiated but their PV channels are commented out of the active tuples (DM2, several SmarAct stages, the Attocube, the PuMa stack, the cameras). These are carried as present-hardware-not-acquired where carried at all (DISABLED-1), not as live Assets.
+
+### The architectural gap register (shared with the other XFELs)
+
+These are the same deferrals Alvra and Bernina recorded; Cristallina re-confirms them a third time at PSI, now in a vector-magnet diffraction context.
+
+- **One switched Aramis source feeding co-equal stations (TOPO-1).** Now the full triad: Cristallina is the third root Unit on the same source as Alvra and Bernina. Three co-equal Units sharing one upstream source has no home except the `Supply("PhotonBeam")` seam, and the routing state has no model.
+- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The `sf-daq` records a free-running `bsread` stream of per-shot frames; CORA's poll-to-Done acquisition has no representation for it. The Run stays the provenance envelope and the per-shot plane is a referenced `Dataset`.
+- **Beam-synchronous event timing (TIMING-1).** The CTA sequencer and EVR gate acquisition at beam rate (and here also mediate the pump-probe delay, in the absence of a laser device); `TimingController` carries the device but the trigger pattern has no typed home.
+
+### What is deliberately not here yet (modelling, as at the other exercises)
+
+- **New Capabilities / Methods and vendor Models.** Cristallina earns no catalog change; the diffraction and serial-crystallography recipes are carried pending on the [PSI Practices](../psi/index.md). No catalog Model is bound.
+- **The pump-probe laser layer (LASER-1).** Absent from `slic`; not invented.
+- **The vector-magnet field ranges and control handles (MAG-1).** The `Magnet` Family has graduated (Cristallina is a further consumer); only the per-Asset field detail stays pending.
+- **The disabled stages (DISABLED-1).** DM2, the SmarAct / Attocube / PuMa stages, and the cameras are instantiated but commented out of the active config; carried as present-hardware, not live Assets.
+- **The serial-crystallography sample delivery (SAMPLE-1).** Beyond the fast XY stage, the Cristallina-MX delivery is deferred.
+- **The transmission-readback cross-reference (XREF-1).** The front-end attenuator's transmission readbacks alias to `SAROP31-OATT053`; carried `confirm`.
+- **Integration scenarios.** No `test_cristallina_*.py` registers Cristallina Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
+
+## Open questions
+
+*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
+
+Cristallina is modelled from PSI's open [`slic`](https://gitea.psi.ch/slic/cristallina) controls library (on `gitea.psi.ch`, branch `master`), treated as a dry, correct DATA source: the device list with PV prefixes comes from the in-repo `channels/pv_channels.py`, and the diffractometer and sample-environment topology from the `beamline/` and `crq_exp/` driver classes. That gives the device shape and the EPICS PV prefixes at high confidence. It does not give most motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding. This page collects what `slic` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+Unlike Bernina, Cristallina's device facts are in-repo (not externalized), so this is a fuller cut; the residual questions concentrate on the XFEL acquisition paradigm, the novel sample environment, and a few `slic`-specific provenance cautions.
+
+### Scope, topology, and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is Cristallina (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Cristallina closes the Aramis triad and tests a `slic`-mined deployment and a vector-magnet sample environment; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
+| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. With three co-equal stations now modelled, should each be its own root Unit sharing an upstream source, and where does the shared switched source and its three-way routing state live? | One `Cristallina` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
+| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the high-field magnet? | Both enclosures exist with permit signals to be named; `slic` does not carry them. | The Enclosure permit signals and the magnet-safety interlock. |
+| ENC-1 | Blocks-build | Which enclosure does each device sit in? `slic` separates an optics hutch from an experimental hutch but does not encode the access-gated safety meaning. | The shared `SAROP31` optics hutch plus the Cristallina experiment hutch. | The per-device Enclosure assignment. |
+| MAG-1 | Blocks-go-live | The DilSc vector superconducting magnet (to 5.2 T) and its liquid-helium cryogens are a personnel- and quench-safety hazard. How is the hazard gated, and what are the per-axis field ranges and control handles? | The magnet is a `Clearance` hazard (the ID32 precedent), and binds the graduated `Magnet` Family (a further consumer); the per-Asset field detail stays pending. | The magnet-hazard Clearance and the per-Asset magnet field / control detail. |
+
+### Source, optics, and attenuation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the Aramis undulator gap tables and source size? `slic` carries the period (15 mm) and the K-to-energy constants but not the full source curve. | A SASE FEL undulator; per-shot photon energy (5-13 keV) is a DAQ datum, not a standing setpoint. | The `Undulator` source parameters. |
+| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the gas monitor. | The linac machine-state modelling boundary. |
+| ATT-1 | Blocks-go-live | The `aramis_attenuator` driver selects a foil combination for a requested transmission (energy-dependent). Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With Alvra, Bernina, and Cristallina all carrying it, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
+| MONO-1 | Nice-to-have | The mono is a double-channel-cut (DCCM, `ODCC110`), distinct from Bernina's DCM. What are the crystal and axis details, and the pink-vs-mono mode boundary (the mono screen selects out / mono / pink)? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCCM internals and the pink-vs-mono mode model. |
+| XREF-1 | Nice-to-have | The front-end attenuator's transmission readbacks alias to `SAROP31-OATT053`. Is the front-end attenuator (`SARFE10-OATT053`) the same device read through the Cristallina-branch namespace, or two devices? | The `SARFE10-OATT053` front-end attenuator is the modelled device; the `SAROP31` alias is a readback, carried `confirm`. | Whether the attenuator readback alias is one device or two. |
+
+### Endstation: diffractometers and the sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The DM1 (dilution-fridge) and DM2 (pulsed-magnet) platforms compose a goniometer, a 2-theta detector arm, and base / sample translations (DM2 adds swivels). Are they correctly modelled as the graduated `Diffractometer` Assembly, and is DM2 currently live? | Both reuse the `Diffractometer` Assembly (Bernina precedent), no new Family; DM2's PV channels are commented out in `slic`, so it is carried as present-hardware-not-acquired (DISABLED-1). | The Assembly composition and DM2's live status. |
+| DIFF-2 | Nice-to-have | What is the `PartitionRule` shape for the reciprocal-space `PseudoAxis`? | The reciprocal-space `PseudoAxis` carries a partition rule like the synchrotron diffractometers'. | The reciprocal-space partition rule. |
+| LASER-1 | Blocks-go-live | The `slic` source has no pump-probe laser (only the X-ray alignment laser `SAROP31-OLAS147`); pump-probe timing is mediated by the CTA sequencer and EVR. Does Cristallina have a pump-probe optical laser in another controls layer? | No pump-probe-laser Asset is modelled in this cut; the alignment laser is a catalog `Laser`. Whether a pump-probe laser exists elsewhere is carried as this question. | Whether a pump-probe laser exists and where it is controlled. |
+| DISABLED-1 | Nice-to-have | Several `slic` drivers are instantiated but their PV channels are commented out of the active config (DM2, the SmarAct Juraj / mini stages, the Attocube, the PuMa stack, the cameras). Which are live hardware? | Carried as present-hardware-not-acquired; not modelled as live Assets in this cut. | Which disabled stages are current hardware. |
+| ENV-1 | Nice-to-have | The DilSc magnet has an alternative SECoP / Frappy driver (`dilsc.psi.ch:5000`) and the pulsed-magnet uses a server-side pulse-tube synchronization service (`oscillations.psi.ch:8000`). Are these in the operational path? | The live EPICS magnet driver is modelled; the SECoP path and the sync service are server-side and not modelled. | The magnet control path and the pulse-tube sync. |
+
+### Acquisition, timing, diagnostics, and detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. Cristallina is the third PSI sighting. | Whether CORA gains an event-stream acquisition axis. |
+| TIMING-1 | Blocks-go-live | The CTA sequencer (`SAR-CCTA-ESC`) and EVR gate acquisition at beam rate and mediate the pump-probe delay. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
+| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor (PBPG), and the photon single-shot spectrometer (PSSS) modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from Alvra / Bernina / I22; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
+| DET-1 | Blocks-go-live | What are the Cristallina detectors per configuration? `slic` binds a 1.5M Jungfrau (`JF16T03V02`) + a 0.5M I0 (`JF20T01V01`) for Q and an 8M (`JF17T16V01`) for MX; the human-readable labels come from a commented `sf_daq_broker` block. Which is in use, and its geometry? | The detectors reuse `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the active config and geometry are to supply. | The detector models, the per-config wiring, and the labels. |
+| SAMPLE-1 | Nice-to-have | What is the Cristallina-MX sample-delivery shape beyond the fast XY stage, and the `Subject` custody lifecycle? | Sample delivery beyond the fast stage is endstation-specific and deferred; no Family is coined. | The sample-delivery model and the `Subject` custody thread. |
+| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one Alvra and Bernina raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/cristallina/questions.md b/docs/deployments/cristallina/questions.md
deleted file mode 100644
index 4558250da0a..00000000000
--- a/docs/deployments/cristallina/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.*
-
-Cristallina is modelled from PSI's open [`slic`](https://gitea.psi.ch/slic/cristallina) controls library (on `gitea.psi.ch`, branch `master`), treated as a dry, correct DATA source: the device list with PV prefixes comes from the in-repo `channels/pv_channels.py`, and the diffractometer and sample-environment topology from the `beamline/` and `crq_exp/` driver classes. That gives the device shape and the EPICS PV prefixes at high confidence. It does not give most motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding. This page collects what `slic` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-Unlike Bernina, Cristallina's device facts are in-repo (not externalized), so this is a fuller cut; the residual questions concentrate on the XFEL acquisition paradigm, the novel sample environment, and a few `slic`-specific provenance cautions.
-
-## Scope, topology, and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is Cristallina (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: Cristallina closes the Aramis triad and tests a `slic`-mined deployment and a vector-magnet sample environment; it is not on the pilot roadmap. | Whether PSI is a real Site or a modelling fixture. |
-| TOPO-1 | Blocks-build | One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. With three co-equal stations now modelled, should each be its own root Unit sharing an upstream source, and where does the shared switched source and its three-way routing state live? | One `Cristallina` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
-| PSS-1 | Blocks-build | What are the SwissFEL PSS search-and-secure permit signals, and the interlock for the high-field magnet? | Both enclosures exist with permit signals to be named; `slic` does not carry them. | The Enclosure permit signals and the magnet-safety interlock. |
-| ENC-1 | Blocks-build | Which enclosure does each device sit in? `slic` separates an optics hutch from an experimental hutch but does not encode the access-gated safety meaning. | The shared `SAROP31` optics hutch plus the Cristallina experiment hutch. | The per-device Enclosure assignment. |
-| MAG-1 | Blocks-go-live | The DilSc vector superconducting magnet (to 5.2 T) and its liquid-helium cryogens are a personnel- and quench-safety hazard. How is the hazard gated, and what are the per-axis field ranges and control handles? | The magnet is a `Clearance` hazard (the ID32 precedent), and binds the graduated `Magnet` Family (a further consumer); the per-Asset field detail stays pending. | The magnet-hazard Clearance and the per-Asset magnet field / control detail. |
-
-## Source, optics, and attenuation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the Aramis undulator gap tables and source size? `slic` carries the period (15 mm) and the K-to-energy constants but not the full source curve. | A SASE FEL undulator; per-shot photon energy (5-13 keV) is a DAQ datum, not a standing setpoint. | The `Undulator` source parameters. |
-| MACHINE-1 | Nice-to-have | SwissFEL is a linac, not a storage ring. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via the gas monitor. | The linac machine-state modelling boundary. |
-| ATT-1 | Blocks-go-live | The `aramis_attenuator` driver selects a foil combination for a requested transmission (energy-dependent). Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg. With Alvra, Bernina, and Cristallina all carrying it, the rule-of-three is well past its trigger. | Whether the transmission solver is built and where. |
-| MONO-1 | Nice-to-have | The mono is a double-channel-cut (DCCM, `ODCC110`), distinct from Bernina's DCM. What are the crystal and axis details, and the pink-vs-mono mode boundary (the mono screen selects out / mono / pink)? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCCM internals and the pink-vs-mono mode model. |
-| XREF-1 | Nice-to-have | The front-end attenuator's transmission readbacks alias to `SAROP31-OATT053`. Is the front-end attenuator (`SARFE10-OATT053`) the same device read through the Cristallina-branch namespace, or two devices? | The `SARFE10-OATT053` front-end attenuator is the modelled device; the `SAROP31` alias is a readback, carried `confirm`. | Whether the attenuator readback alias is one device or two. |
-
-## Endstation: diffractometers and the sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The DM1 (dilution-fridge) and DM2 (pulsed-magnet) platforms compose a goniometer, a 2-theta detector arm, and base / sample translations (DM2 adds swivels). Are they correctly modelled as the graduated `Diffractometer` Assembly, and is DM2 currently live? | Both reuse the `Diffractometer` Assembly (Bernina precedent), no new Family; DM2's PV channels are commented out in `slic`, so it is carried as present-hardware-not-acquired (DISABLED-1). | The Assembly composition and DM2's live status. |
-| DIFF-2 | Nice-to-have | What is the `PartitionRule` shape for the reciprocal-space `PseudoAxis`? | The reciprocal-space `PseudoAxis` carries a partition rule like the synchrotron diffractometers'. | The reciprocal-space partition rule. |
-| LASER-1 | Blocks-go-live | The `slic` source has no pump-probe laser (only the X-ray alignment laser `SAROP31-OLAS147`); pump-probe timing is mediated by the CTA sequencer and EVR. Does Cristallina have a pump-probe optical laser in another controls layer? | No pump-probe-laser Asset is modelled in this cut; the alignment laser is a catalog `Laser`. Whether a pump-probe laser exists elsewhere is carried as this question. | Whether a pump-probe laser exists and where it is controlled. |
-| DISABLED-1 | Nice-to-have | Several `slic` drivers are instantiated but their PV channels are commented out of the active config (DM2, the SmarAct Juraj / mini stages, the Attocube, the PuMa stack, the cameras). Which are live hardware? | Carried as present-hardware-not-acquired; not modelled as live Assets in this cut. | Which disabled stages are current hardware. |
-| ENV-1 | Nice-to-have | The DilSc magnet has an alternative SECoP / Frappy driver (`dilsc.psi.ch:5000`) and the pulsed-magnet uses a server-side pulse-tube synchronization service (`oscillations.psi.ch:8000`). Are these in the operational path? | The live EPICS magnet driver is modelled; the SECoP path and the sync service are server-side and not modelled. | The magnet control path and the pulse-tube sync. |
-
-## Acquisition, timing, diagnostics, and detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DAQ-1 | Blocks-build | The SwissFEL `sf-daq` records a free-running `bsread` stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. CORA's acquisition is a single-detector poll-to-Done loop with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in the SwissFEL data API, and CORA references a `Dataset`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. Cristallina is the third PSI sighting. | Whether CORA gains an event-stream acquisition axis. |
-| TIMING-1 | Blocks-go-live | The CTA sequencer (`SAR-CCTA-ESC`) and EVR gate acquisition at beam rate and mediate the pump-probe delay. CORA's `TimingController` carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? | `TimingController` for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. | The event-system trigger-pattern parameter model. |
-| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (PBPS), the gas monitor (PBPG), and the photon single-shot spectrometer (PSSS) modelled? They present the Sensor Role. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from Alvra / Bernina / I22; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
-| DET-1 | Blocks-go-live | What are the Cristallina detectors per configuration? `slic` binds a 1.5M Jungfrau (`JF16T03V02`) + a 0.5M I0 (`JF20T01V01`) for Q and an 8M (`JF17T16V01`) for MX; the human-readable labels come from a commented `sf_daq_broker` block. Which is in use, and its geometry? | The detectors reuse `Camera`; per-shot frames flow through the `sf-daq` data plane (DAQ-1); the active config and geometry are to supply. | The detector models, the per-config wiring, and the labels. |
-| SAMPLE-1 | Nice-to-have | What is the Cristallina-MX sample-delivery shape beyond the fast XY stage, and the `Subject` custody lifecycle? | Sample delivery beyond the fast stage is endstation-specific and deferred; no Family is coined. | The sample-delivery model and the `Subject` custody thread. |
-| PULSE-1 | Nice-to-have | The X-ray pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question, the same one Alvra and Bernina raised. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/cristallina/techniques.md b/docs/deployments/cristallina/techniques.md
deleted file mode 100644
index ff4d382e8ae..00000000000
--- a/docs/deployments/cristallina/techniques.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Techniques
-
-*What Cristallina is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
-
-Cristallina runs two technique families, neither of which fits the catalog's tomography Methods, so each is carried pending on the [PSI Practices](../psi/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
-
-## Time-resolved hard X-ray diffraction and scattering (quantum materials)
-
-Cristallina's reason for existing. The Cristallina-Q endstation studies quantum materials: their structural and electronic response is read by diffraction and scattering, shot by shot, in a controlled low-temperature, high-magnetic-field environment. The sample is oriented and the detector positioned by the DM1 dilution-fridge or DM2 pulsed-magnet diffractometer, inside the DilSc dilution refrigerator and its vector superconducting magnet.
-
-- **Spine shape:** a `diffraction` Method binding the diffractometer (a `Goniometer` for the sample circles, a `RotaryStage` 2-theta detector arm, and a reciprocal-space `PseudoAxis`), composed through the graduated `Diffractometer` Assembly (DIFF-1), over a per-shot acquisition, with the sample-environment state (temperature from the LakeShore 372, field from the vector magnet) as conditions. It shares the `diffraction` Method Bernina introduced.
-- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). A time-resolved diffraction run is a free-running shot stream tagged by pulse-ID, not a trajectory of points. The diffractometer is covered by the existing Assembly, and the sample environment by the `TemperatureController` Family and the graduated `Magnet` Family; the acquisition is the gap.
-
-The vector magnet is what distinguishes Cristallina-Q from Bernina's diffraction: the experiment sweeps not just delay and orientation but a three-axis magnetic field, in a dilution-fridge temperature regime. That sample environment is modelled (the LakeShore as `TemperatureController`, the magnet as the graduated `Magnet` Family, a further consumer, MAG-1) and gated by a Clearance hazard, but it adds no new technique-modelling shape beyond the conditions a Run already carries.
-
-## Serial femtosecond crystallography
-
-The Cristallina-MX endstation runs serial crystallography: microcrystals are delivered onto the fast XY sample stage and each X-ray pulse records a single-shot diffraction pattern. It shares the `serial_crystallography` Method LCLS-MFX and Alvra carry.
-
-- **Spine shape:** a `serial_crystallography` Method binding the fast sample stage, the focusing optics, and the 8M Jungfrau, over a free-running per-shot acquisition.
-- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1), the same as for the other XFEL serial-crystallography exercises. The sample delivery beyond the fast stage is endstation-specific and deferred (SAMPLE-1).
-
-## Why neither is in the catalog yet
-
-The catalog's Methods are all tomography-family. An XFEL diffraction / crystallography station shares none of them, and coining XFEL Methods now, before the per-shot acquisition axis they depend on exists (DAQ-1), would be inventing recipes for a spine that cannot yet run them. So each is carried pending, reusing the Method name Bernina or LCLS-MFX named for it. That a third PSI station, on a different controls library (`slic`) and with a novel sample environment (the vector magnet), reaches the same acquisition gaps is the reinforcement Cristallina adds: the gaps are about the XFEL acquisition paradigm, not the technique or the controls house style. See [Model](model.md) for the gap register, the `Diffractometer` Assembly design, and the `Magnet` rule-of-three.
diff --git a/docs/deployments/csx/governance.md b/docs/deployments/csx/governance.md
deleted file mode 100644
index 304f84188cc..00000000000
--- a/docs/deployments/csx/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at CSX, and the trust shape that will gate it. First cut.*
-
-Governance at CSX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-CSX is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. CSX carries the soft X-ray hazard classes (ultra-high vacuum and the cryostat's cryogens at the in-vacuum endstation) that an experiment Clearance would carry; those land with the instruments that bring them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives CSX, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/csx/model.md b/docs/deployments/csx/model.md
deleted file mode 100644
index 8c24c6edf31..00000000000
--- a/docs/deployments/csx/model.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's CSX content lives, the `GratingMonochromator` graduation this deployment earns, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at CSX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the TARDIS hkl `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates
-
-CSX is the **consolidation** deployment for soft X-ray. SIX (NSLS-II 2-ID) introduced `GratingMonochromator` as a loose family at n=1; CSX's VLS-PGM (`XF:23ID1-OP{Mono`, 200-2200 eV) is the **second** independent soft X-ray plane-grating monochromator, which earns the rule-of-three. So `GratingMonochromator` **graduates into the catalog** with this deployment: it becomes a catalog Family that both SIX and CSX bind, with the grating line density and energy range carried as a per-Asset settings difference (the `InsertionDevice` / `Monochromator` precedent), not a Family split. The SIX deployment's references are swept from loose to graduated in the same change. The catalog `Monochromator` (a crystal / multilayer Bragg optic) is deliberately not stretched to cover the grating mono; they are distinct optics. Its naming-r3 review is done.
-
-CSX also **reinforces** an existing abstraction rather than adding one: its TARDIS endstation is an in-vacuum hkl E6C diffractometer whose circles bind the catalog `Goniometer` Family and the composed `Assembly(Diffractometer)`, a third hkl diffractometer after 4-ID and 8-ID (and the first in a soft X-ray, in-vacuum context). No new family is introduced.
-
-## Deliberately not here yet
-
-- **The fine piezo nanopositioner.** CSX carries a piezo nanopositioner for sample / lens fine-positioning; it is deferred (it would fold to `Hexapod` or stay a loose nanopositioner family, an owner call at the point it is modelled).
-
-- **The reciprocal-space solver.** The TARDIS hkl pseudo-axis is modelled as a `PseudoAxis` device; the inverse-kinematics partition rule is `DIFF-2`, deferred (as on 4-ID / 8-ID).
-
-- **The coherent / holography Method.** CSX's defining coherence (the FastCCD coherent-scattering and holography) is carried as a beam-quality enabler and settings on the existing scattering Methods, not coined as its own Method; whether coherent soft X-ray scattering enters the catalog is an owner decision (`TECH-1`).
-
-- **The simulated devices and full asset-tree scenarios.** No `test_csx_*.py` registers the CSX asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/csx/notes.md b/docs/deployments/csx/notes.md
new file mode 100644
index 00000000000..6a08d98887d
--- /dev/null
+++ b/docs/deployments/csx/notes.md
@@ -0,0 +1,120 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of CSX is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. CSX's scattering legs reuse Methods already in the catalog's pending set, so they render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### Resonant soft X-ray scattering
+
+CSX tunes the soft X-ray energy to an absorption edge and measures the scattered intensity through the TARDIS diffractometer, resolving electronic and magnetic order in reciprocal space.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant soft X-ray scattering | `resonant_scattering` | RSXS on the TARDIS E6C; reuses the 4-ID `resonant_scattering` Method, in a soft X-ray regime (a Plan / settings difference) |
+| Soft X-ray diffraction | `diffraction` | coherent soft X-ray diffraction through the TARDIS circles; reuses the 4-ID / 8-ID `diffraction` Method |
+
+Both need the [grating monochromator](source.md) (the incident energy), the [TARDIS diffractometer](sample.md), and the [coherent detectors](detector.md). The arm and sample circles select the momentum transfer.
+
+### Coherence and holography
+
+CSX's defining quality is beam coherence: the FastCCD records coherent-scattering and holography patterns. This is carried as a beam-quality enabler and as settings on the scattering Methods above, not coined as its own Method; whether coherent soft X-ray scattering becomes a distinct catalog Method is an owner-scope decision (`TECH-1`).
+
+### Not modelled yet
+
+The concrete acquisition recipes (energy maps, reciprocal-space scans, coherent / holography exposures) are not written yet; they join as the deployment approaches the point where CORA drives CSX. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at CSX, and the trust shape that will gate it. First cut.*
+
+Governance at CSX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+CSX is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. CSX carries the soft X-ray hazard classes (ultra-high vacuum and the cryostat's cryogens at the in-vacuum endstation) that an experiment Clearance would carry; those land with the instruments that bring them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives CSX, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's CSX content lives, the `GratingMonochromator` graduation this deployment earns, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at CSX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the TARDIS hkl `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates
+
+CSX is the **consolidation** deployment for soft X-ray. SIX (NSLS-II 2-ID) introduced `GratingMonochromator` as a loose family at n=1; CSX's VLS-PGM (`XF:23ID1-OP{Mono`, 200-2200 eV) is the **second** independent soft X-ray plane-grating monochromator, which earns the rule-of-three. So `GratingMonochromator` **graduates into the catalog** with this deployment: it becomes a catalog Family that both SIX and CSX bind, with the grating line density and energy range carried as a per-Asset settings difference (the `InsertionDevice` / `Monochromator` precedent), not a Family split. The SIX deployment's references are swept from loose to graduated in the same change. The catalog `Monochromator` (a crystal / multilayer Bragg optic) is deliberately not stretched to cover the grating mono; they are distinct optics. Its naming-r3 review is done.
+
+CSX also **reinforces** an existing abstraction rather than adding one: its TARDIS endstation is an in-vacuum hkl E6C diffractometer whose circles bind the catalog `Goniometer` Family and the composed `Assembly(Diffractometer)`, a third hkl diffractometer after 4-ID and 8-ID (and the first in a soft X-ray, in-vacuum context). No new family is introduced.
+
+### Deliberately not here yet
+
+- **The fine piezo nanopositioner.** CSX carries a piezo nanopositioner for sample / lens fine-positioning; it is deferred (it would fold to `Hexapod` or stay a loose nanopositioner family, an owner call at the point it is modelled).
+
+- **The reciprocal-space solver.** The TARDIS hkl pseudo-axis is modelled as a `PseudoAxis` device; the inverse-kinematics partition rule is `DIFF-2`, deferred (as on 4-ID / 8-ID).
+
+- **The coherent / holography Method.** CSX's defining coherence (the FastCCD coherent-scattering and holography) is carried as a beam-quality enabler and settings on the existing scattering Methods, not coined as its own Method; whether coherent soft X-ray scattering enters the catalog is an owner decision (`TECH-1`).
+
+- **The simulated devices and full asset-tree scenarios.** No `test_csx_*.py` registers the CSX asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the CSX team to confirm before the model can be trusted.*
+
+CSX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/csx-profile-collection](https://github.com/NSLS2/csx-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/csx1` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the `GratingMonochromator` graduation). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | The 23-ID canted straight: do the two EPUs feed CSX (23-ID-1) plus a sibling branch, and is CSX one root Unit? | One root Unit `CSX` fed by the canted twin-EPU straight (the 32-ID precedent). | The source topology in the [descriptor](index.md). |
+| ENC-1 | Blocks-go-live | Are the PV zones `XF:23IDA` / `XF:23ID1-OP` / `XF:23ID1-ES` separate shielded hutches or beam zones within fewer? | Two enclosures (front-end optics + the 23-ID-1 branch). | The Enclosure grouping. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the csx-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the front-end shutter is `XF:23ID1-PPS{Sh:FE}`. | The Enclosure permit signals. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The two EPUs (`EPU:1`, `EPU:2`): type, period, and the polarization (phase) model. | Two `InsertionDevice` Assets; the phase axis carried as a setting. | The insertion-device specs. |
+| MONO-1 | Blocks-go-live | The VLS-PGM: the grating line densities, the c-value model, and the 200-2200 eV range. | A `GratingMonochromator` Asset (catalog Family) with energy / mirror-pitch / mirror-x / grating-pitch / grating-x axes. | The monochromator model. |
+| OPT-1 | Nice-to-have | The mirrors (M1A front-end hexapod, M3A refocusing): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The branch slits (`Slt:1` / `Slt:2` gap-center, `Slt:3` x/y): the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
+
+### TARDIS endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The TARDIS E6C geometry: confirm the circle roles (theta, delta, gamma, mu) and which is sample versus detector. | A 6-circle hkl E6C diffractometer binding the `Goniometer` Family + the `Assembly(Diffractometer)`. | The circle geometry and the Assembly binding. |
+| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: the hkl E6C inverse-kinematics over this geometry. | A `PseudoAxis` Asset for the reciprocal-space layer. | The pseudo-axis model. |
+| SAMPLE-1 | Nice-to-have | The sample stage, the holography stage, and the cryostat: the axes, the cryo range, and the fine nanopositioner. | A `LinearStage` (sx / say / saz + holography) and a `TemperatureController`. | The sample-environment model. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The coherent detectors (FastCCD, AXIS), the scaler / MCS, and the diode: models, sensors, and channels. | `Camera` Assets, a `FluxMonitor` scaler, and a `GenericProbe` diode. | The detector models and channel map. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the in-vacuum TARDIS, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/csx/questions.md b/docs/deployments/csx/questions.md
deleted file mode 100644
index 77e07fbe470..00000000000
--- a/docs/deployments/csx/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the CSX team to confirm before the model can be trusted.*
-
-CSX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/csx-profile-collection](https://github.com/NSLS2/csx-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/csx1` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the `GratingMonochromator` graduation). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | The 23-ID canted straight: do the two EPUs feed CSX (23-ID-1) plus a sibling branch, and is CSX one root Unit? | One root Unit `CSX` fed by the canted twin-EPU straight (the 32-ID precedent). | The source topology in the [descriptor](index.md). |
-| ENC-1 | Blocks-go-live | Are the PV zones `XF:23IDA` / `XF:23ID1-OP` / `XF:23ID1-ES` separate shielded hutches or beam zones within fewer? | Two enclosures (front-end optics + the 23-ID-1 branch). | The Enclosure grouping. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the csx-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the front-end shutter is `XF:23ID1-PPS{Sh:FE}`. | The Enclosure permit signals. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The two EPUs (`EPU:1`, `EPU:2`): type, period, and the polarization (phase) model. | Two `InsertionDevice` Assets; the phase axis carried as a setting. | The insertion-device specs. |
-| MONO-1 | Blocks-go-live | The VLS-PGM: the grating line densities, the c-value model, and the 200-2200 eV range. | A `GratingMonochromator` Asset (catalog Family) with energy / mirror-pitch / mirror-x / grating-pitch / grating-x axes. | The monochromator model. |
-| OPT-1 | Nice-to-have | The mirrors (M1A front-end hexapod, M3A refocusing): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The branch slits (`Slt:1` / `Slt:2` gap-center, `Slt:3` x/y): the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
-
-## TARDIS endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The TARDIS E6C geometry: confirm the circle roles (theta, delta, gamma, mu) and which is sample versus detector. | A 6-circle hkl E6C diffractometer binding the `Goniometer` Family + the `Assembly(Diffractometer)`. | The circle geometry and the Assembly binding. |
-| DIFF-2 | Blocks-go-live | The reciprocal-space coordination: the hkl E6C inverse-kinematics over this geometry. | A `PseudoAxis` Asset for the reciprocal-space layer. | The pseudo-axis model. |
-| SAMPLE-1 | Nice-to-have | The sample stage, the holography stage, and the cryostat: the axes, the cryo range, and the fine nanopositioner. | A `LinearStage` (sx / say / saz + holography) and a `TemperatureController`. | The sample-environment model. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The coherent detectors (FastCCD, AXIS), the scaler / MCS, and the diode: models, sensors, and channels. | `Camera` Assets, a `FluxMonitor` scaler, and a `GenericProbe` diode. | The detector models and channel map. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the in-vacuum TARDIS, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/csx/techniques.md b/docs/deployments/csx/techniques.md
deleted file mode 100644
index 13a2364a2d4..00000000000
--- a/docs/deployments/csx/techniques.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Techniques
-
-*What the modelled part of CSX is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. CSX's scattering legs reuse Methods already in the catalog's pending set, so they render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## Resonant soft X-ray scattering
-
-CSX tunes the soft X-ray energy to an absorption edge and measures the scattered intensity through the TARDIS diffractometer, resolving electronic and magnetic order in reciprocal space.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant soft X-ray scattering | `resonant_scattering` | RSXS on the TARDIS E6C; reuses the 4-ID `resonant_scattering` Method, in a soft X-ray regime (a Plan / settings difference) |
-| Soft X-ray diffraction | `diffraction` | coherent soft X-ray diffraction through the TARDIS circles; reuses the 4-ID / 8-ID `diffraction` Method |
-
-Both need the [grating monochromator](source.md) (the incident energy), the [TARDIS diffractometer](sample.md), and the [coherent detectors](detector.md). The arm and sample circles select the momentum transfer.
-
-## Coherence and holography
-
-CSX's defining quality is beam coherence: the FastCCD records coherent-scattering and holography patterns. This is carried as a beam-quality enabler and as settings on the scattering Methods above, not coined as its own Method; whether coherent soft X-ray scattering becomes a distinct catalog Method is an owner-scope decision (`TECH-1`).
-
-## Not modelled yet
-
-The concrete acquisition recipes (energy maps, reciprocal-space scans, coherent / holography exposures) are not written yet; they join as the deployment approaches the point where CORA drives CSX. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/esm/governance.md b/docs/deployments/esm/governance.md
deleted file mode 100644
index 9fa6ed5b4ee..00000000000
--- a/docs/deployments/esm/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at ESM, and the trust shape that will gate it. First cut.*
-
-Governance at ESM follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-ESM is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. ESM carries the soft X-ray hazard classes (ultra-high vacuum and the cryostat's cryogens at the ARPES endstation) that an experiment Clearance would carry; those land with the instruments that bring them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ESM, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/esm/model.md b/docs/deployments/esm/model.md
deleted file mode 100644
index 3d7fe0f9b1a..00000000000
--- a/docs/deployments/esm/model.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ESM content lives, the `Manipulator` graduation and `ElectronAnalyzer` this deployment introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ESM |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates
-
-ESM both earns a new abstraction and consolidates two existing ones.
-
-- **`ElectronAnalyzer` (new, since graduated).** The Scienta SES hemispherical electron energy analyzer is the ARPES detector: photon-in, electron-out, recording electron counts over a kinetic-energy by emission-angle window set by the pass energy and lens mode. No photon-detector Family covers an electron spectrometer, so ESM introduced a new `ElectronAnalyzer` Family (presents the Detector Role); it graduated into the catalog once SST (NSLS-II 7-ID HAXPES) earned the second Scienta SES (`ARPES-1`).
-- **`Manipulator` (graduates).** ESM's LT six-axis UHV cryostat manipulator is the **second** UHV sample manipulator after SIX, earning the abstraction at the two-deployment threshold. `Manipulator` graduates into the catalog with this deployment, distinct from `Hexapod` (parallel-kinematic), `Goniometer` (crystal orientation), and a plain `LinearStage` / `RotaryStage`; axis count and cryo range are a per-Asset settings difference. SIX's references are swept loose to graduated in the same change. Its naming-r3 review (done at the SIX sighting, with the watch-item to confirm it is not a `Hexapod` / `Goniometer` synonym) is resolved: a serial UHV stack is a distinct mechanism.
-- **`GratingMonochromator` (reuses).** ESM's PGM is the third soft X-ray plane-grating monochromator after SIX and CSX, so it binds the catalog Family rather than minting one.
-
-## Deliberately not here yet
-
-- **The XPEEM/LEEM branch (`21-ID-2`).** ESM's second endstation is a low-energy electron microscope (LEEM) / photoemission electron microscope (PEEM), an electron-optics imaging instrument distinct from the analyzer. It is deferred to a follow-on as a future loose `ElectronMicroscope` Family (`PEEM-1`); this cut models the ARPES branch (the 32-ID / SRX "one endstation first" precedent).
-
-- **The sample-prep and load-lock transfer.** The sample-prep and analysis-chamber manipulators and the load-lock sample-transfer claw are present in the config but deferred; this cut models the main LT sample manipulator (`SAMPLE-1`).
-
-- **The ARPES Method.** Whether angle-resolved photoemission enters CORA's catalog is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
-
-- **The simulated devices and full asset-tree scenarios.** No `test_esm_*.py` registers the ESM asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/esm/notes.md b/docs/deployments/esm/notes.md
new file mode 100644
index 00000000000..7b4f4c21822
--- /dev/null
+++ b/docs/deployments/esm/notes.md
@@ -0,0 +1,105 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of ESM is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. ESM's technique is angle-resolved photoemission, a photoemission method new to CORA's catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Angle-resolved photoemission
+
+ARPES illuminates the sample with monochromatic soft X-rays and measures the kinetic energy and emission angle of the photoelectrons, mapping the electronic band structure. The measurement is the electron distribution recorded by the hemispherical analyzer over a pass-energy and lens-mode window, at a sample orientation set by the cryostat manipulator.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Angle-resolved photoemission | `angle_resolved_photoemission` | electron energy / angle spectra on the Scienta SES analyzer, at low temperature on the UHV manipulator; Method not yet in catalog |
+
+It needs the [grating monochromator](source.md) (the incident energy), the [UHV cryostat manipulator](sample.md), and the [electron analyzer](detector.md). Polarization is set by the dual EPUs.
+
+### Not modelled yet
+
+The XPEEM/LEEM photoemission-microscopy branch is deferred (a future `ElectronMicroscope` Family; see [Model](#deliberately-not-here-yet)). The concrete acquisition recipes (Fermi-surface maps, energy-distribution curves, the analyzer sweep settings) are not written yet; they join as the deployment approaches the point where CORA drives ESM. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at ESM, and the trust shape that will gate it. First cut.*
+
+Governance at ESM follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+ESM is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. ESM carries the soft X-ray hazard classes (ultra-high vacuum and the cryostat's cryogens at the ARPES endstation) that an experiment Clearance would carry; those land with the instruments that bring them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ESM, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ESM content lives, the `Manipulator` graduation and `ElectronAnalyzer` this deployment introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ESM |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates
+
+ESM both earns a new abstraction and consolidates two existing ones.
+
+- **`ElectronAnalyzer` (new, since graduated).** The Scienta SES hemispherical electron energy analyzer is the ARPES detector: photon-in, electron-out, recording electron counts over a kinetic-energy by emission-angle window set by the pass energy and lens mode. No photon-detector Family covers an electron spectrometer, so ESM introduced a new `ElectronAnalyzer` Family (presents the Detector Role); it graduated into the catalog once SST (NSLS-II 7-ID HAXPES) earned the second Scienta SES (`ARPES-1`).
+- **`Manipulator` (graduates).** ESM's LT six-axis UHV cryostat manipulator is the **second** UHV sample manipulator after SIX, earning the abstraction at the two-deployment threshold. `Manipulator` graduates into the catalog with this deployment, distinct from `Hexapod` (parallel-kinematic), `Goniometer` (crystal orientation), and a plain `LinearStage` / `RotaryStage`; axis count and cryo range are a per-Asset settings difference. SIX's references are swept loose to graduated in the same change. Its naming-r3 review (done at the SIX sighting, with the watch-item to confirm it is not a `Hexapod` / `Goniometer` synonym) is resolved: a serial UHV stack is a distinct mechanism.
+- **`GratingMonochromator` (reuses).** ESM's PGM is the third soft X-ray plane-grating monochromator after SIX and CSX, so it binds the catalog Family rather than minting one.
+
+### Deliberately not here yet
+
+- **The XPEEM/LEEM branch (`21-ID-2`).** ESM's second endstation is a low-energy electron microscope (LEEM) / photoemission electron microscope (PEEM), an electron-optics imaging instrument distinct from the analyzer. It is deferred to a follow-on as a future loose `ElectronMicroscope` Family (`PEEM-1`); this cut models the ARPES branch (the 32-ID / SRX "one endstation first" precedent).
+
+- **The sample-prep and load-lock transfer.** The sample-prep and analysis-chamber manipulators and the load-lock sample-transfer claw are present in the config but deferred; this cut models the main LT sample manipulator (`SAMPLE-1`).
+
+- **The ARPES Method.** Whether angle-resolved photoemission enters CORA's catalog is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
+
+- **The simulated devices and full asset-tree scenarios.** No `test_esm_*.py` registers the ESM asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the ESM team to confirm before the model can be trusted.*
+
+ESM was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/esm-arpes-profile-collection](https://github.com/NSLS2/esm-arpes-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the `Manipulator` graduation and the deferred XPEEM branch). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The two EPUs (EPU57 on G1A, EPU105 on G1B): periods, the polarization (phase) model, and how the pair is coordinated. | Two `InsertionDevice` Assets; the phase axis carried as a setting. | The insertion-device specs. |
+| ENC-1 | Blocks-go-live | Are the PV zones `XF:21IDA/B/C/D` separate shielded hutches or beam zones within fewer? | Four enclosures, one per zone. | The Enclosure grouping. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; shutters are `XF:21ID-PPS{Sh:FE}` / `XF:21IDA-PPS{PSh}` / `XF:21IDC-PPS{PSh:1A/1B}`. | The Enclosure permit signals. |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the esm-arpes-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MONO-1 | Blocks-go-live | The PGM: the grating line densities, the c-value model, and the energy range. | A `GratingMonochromator` Asset (catalog Family) with energy / focus-const / grating-pitch / mirror-pitch / grating-translation axes. | The monochromator model. |
+| OPT-1 | Nice-to-have | The mirrors (M1, M3 hexapod, M4A KB pair, M4B hexapod): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The PGM slits, the M3 slit, and the A/B exit slits: the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
+| DIAG-1 | Nice-to-have | The ESM Diagon (`XF:21IDA-OP{Diag:1`): is it a polarization diagnostic, and what does it report? | One `GenericProbe` Asset (placeholder classification). | The diagnostic classification. |
+
+### ARPES endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ARPES-1 | Blocks-build | The Scienta SES analyzer (`XF21ID1-ES-SES`): the model, the lens modes, the pass-energy and kinetic-energy-window controls, and the acquisition modes. | An `ElectronAnalyzer` Asset (catalog Family) presenting the Detector Role. | The analyzer model and lens / pass-energy controls. |
+| SAMPLE-1 | Blocks-go-live | The LT UHV cryostat manipulator: the live prefix (the config shows a provisional `{PRV` and a commented `{LT:1-Manip:EA5_1`), the six axes, the cryo range, and the sample-prep / load-lock chambers. | A `Manipulator` Asset (x/y/z + Rx/Ry/Rz) plus a `TemperatureController`. | The sample-environment model. |
+| DET-1 | Nice-to-have | The QuadEM flux monitors (qem01-12): which are I0 versus drain-current, and where each sits. | Two representative `FluxMonitor` Assets; the full set summarized. | The flux-monitor map. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the analyzer, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/esm/questions.md b/docs/deployments/esm/questions.md
deleted file mode 100644
index cfdf55b0b38..00000000000
--- a/docs/deployments/esm/questions.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Open questions
-
-*What CORA needs the ESM team to confirm before the model can be trusted.*
-
-ESM was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/esm-arpes-profile-collection](https://github.com/NSLS2/esm-arpes-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the `Manipulator` graduation and the deferred XPEEM branch). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The two EPUs (EPU57 on G1A, EPU105 on G1B): periods, the polarization (phase) model, and how the pair is coordinated. | Two `InsertionDevice` Assets; the phase axis carried as a setting. | The insertion-device specs. |
-| ENC-1 | Blocks-go-live | Are the PV zones `XF:21IDA/B/C/D` separate shielded hutches or beam zones within fewer? | Four enclosures, one per zone. | The Enclosure grouping. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; shutters are `XF:21ID-PPS{Sh:FE}` / `XF:21IDA-PPS{PSh}` / `XF:21IDC-PPS{PSh:1A/1B}`. | The Enclosure permit signals. |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the esm-arpes-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MONO-1 | Blocks-go-live | The PGM: the grating line densities, the c-value model, and the energy range. | A `GratingMonochromator` Asset (catalog Family) with energy / focus-const / grating-pitch / mirror-pitch / grating-translation axes. | The monochromator model. |
-| OPT-1 | Nice-to-have | The mirrors (M1, M3 hexapod, M4A KB pair, M4B hexapod): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The PGM slits, the M3 slit, and the A/B exit slits: the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
-| DIAG-1 | Nice-to-have | The ESM Diagon (`XF:21IDA-OP{Diag:1`): is it a polarization diagnostic, and what does it report? | One `GenericProbe` Asset (placeholder classification). | The diagnostic classification. |
-
-## ARPES endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ARPES-1 | Blocks-build | The Scienta SES analyzer (`XF21ID1-ES-SES`): the model, the lens modes, the pass-energy and kinetic-energy-window controls, and the acquisition modes. | An `ElectronAnalyzer` Asset (catalog Family) presenting the Detector Role. | The analyzer model and lens / pass-energy controls. |
-| SAMPLE-1 | Blocks-go-live | The LT UHV cryostat manipulator: the live prefix (the config shows a provisional `{PRV` and a commented `{LT:1-Manip:EA5_1`), the six axes, the cryo range, and the sample-prep / load-lock chambers. | A `Manipulator` Asset (x/y/z + Rx/Ry/Rz) plus a `TemperatureController`. | The sample-environment model. |
-| DET-1 | Nice-to-have | The QuadEM flux monitors (qem01-12): which are I0 versus drain-current, and where each sits. | Two representative `FluxMonitor` Assets; the full set summarized. | The flux-monitor map. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the analyzer, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/esm/techniques.md b/docs/deployments/esm/techniques.md
deleted file mode 100644
index 62e3158c5c3..00000000000
--- a/docs/deployments/esm/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What the modelled part of ESM is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. ESM's technique is angle-resolved photoemission, a photoemission method new to CORA's catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Angle-resolved photoemission
-
-ARPES illuminates the sample with monochromatic soft X-rays and measures the kinetic energy and emission angle of the photoelectrons, mapping the electronic band structure. The measurement is the electron distribution recorded by the hemispherical analyzer over a pass-energy and lens-mode window, at a sample orientation set by the cryostat manipulator.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Angle-resolved photoemission | `angle_resolved_photoemission` | electron energy / angle spectra on the Scienta SES analyzer, at low temperature on the UHV manipulator; Method not yet in catalog |
-
-It needs the [grating monochromator](source.md) (the incident energy), the [UHV cryostat manipulator](sample.md), and the [electron analyzer](detector.md). Polarization is set by the dual EPUs.
-
-## Not modelled yet
-
-The XPEEM/LEEM photoemission-microscopy branch is deferred (a future `ElectronMicroscope` Family; see [Model](model.md#deliberately-not-here-yet)). The concrete acquisition recipes (Fermi-surface maps, energy-distribution curves, the analyzer sweep settings) are not written yet; they join as the deployment approaches the point where CORA drives ESM. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/faxtor/governance.md b/docs/deployments/faxtor/governance.md
deleted file mode 100644
index 1ce6b529b98..00000000000
--- a/docs/deployments/faxtor/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at FAXTOR, and the trust shape that will gate it. First cut.*
-
-Governance at FAXTOR follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ALBA Site](../alba/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-FAXTOR is CORA's first ALBA deployment, so ALBA is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ALBA Site](../alba/index.md#safety-and-governance), shared across the facility's beamlines, until ALBA staff confirm them (`GOV-1`). FAXTOR is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives FAXTOR, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. ALBA publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ALBA Site](../alba/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives FAXTOR, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/faxtor/model.md b/docs/deployments/faxtor/model.md
deleted file mode 100644
index df7e85def8d..00000000000
--- a/docs/deployments/faxtor/model.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's FAXTOR content lives, the new ALBA Site and Tango / Sardana control house-style it introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at FAXTOR |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes FAXTOR new
-
-FAXTOR is two things at the Site level and nothing new at the vocabulary level. It is CORA's **ninth Site** (ALBA, Barcelona), a re-test of the Site and Federation kernel, and the **second Tango / Sardana / Taurus** control plane CORA models. ALBA is the originating institution of Sardana (and of the Taurus GUI framework and the IcePAP motion controller), so this is the controls house-style's home facility; MAX IV (TomoWISE) was the first consumer CORA modelled. Its science is fast X-ray tomography and radiography on a multipole-wiggler source.
-
-## No new families (the imaging spine reuses the 2-BM / TomoWISE precedent)
-
-FAXTOR coins no new Family. The multipole wiggler binds the catalog `InsertionDevice`; the double multilayer monochromator binds `Monochromator`; the filters bind `Filter` and the slits bind `Slit`; the focusing mirrors bind `Mirror` (deferred, `OPT-1`); the experiment endstation binds `Table`, `RotaryStage`, `LinearStage`, and `Shutter`; the detector binds `Scintillator` and `Camera`; the machine state binds the loose `StorageRing`. Nothing in the catalog changes.
-
-## The Tango / Sardana control plane
-
-FAXTOR is the second Tango / Sardana / Taurus controls house-style in the fleet, after MAX IV TomoWISE. Device IO is a layer of Tango device servers (motors over IcePAP-class controllers, detectors via the Lima framework); Sardana provides the experiment-orchestration layer (a Pool of controllers / motors / measurement groups, plus a MacroServer running scan macros), and Taurus is the operator UI. ALBA publishes no per-beamline device manifest, so CORA does not bind the Tango / Sardana / IcePAP handles here; when bound they would be modelled as opaque edge strings over the `ControlPort`, the way the MX3 and ID32 heterogeneous-control precedents do (`CTRL-1`). The fast continuous-rotation tomography acquisition runs through Sardana macros; that orchestration is the seam CORA's edge replaces, conducting over Tango / IcePAP rather than replacing Sardana. The Lima detector file-writing to the ALBA data store is plumbing CORA observes, not data it owns.
-
-## Deliberately not here yet
-
-- **The control handles (`CTRL-1`).** No public per-beamline Tango / Sardana / IcePAP manifest exists; the handles are carried pending, not invented.
-- **The detector model (`DET-1`).** The fast camera and scintillator are bound to `Camera` and `Scintillator` but their models are unpublished, carried fully pending.
-- **The exact optics detail (`MONO-1`, `FILT-1`, `OPT-1`, `OPT-2`).** The DMM coating and energy partition, the filter set, the mirrors, and the slit blade map are carried confirm-pending.
-- **The endstation stage stack (`SAMPLE-1`, `TRIG-1`).** The rotary, positioning, table, and shutter are named; their axis sets, models, and the trigger scheme are pending.
-- **Radiography as a Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the 7-BM `radiography` slug. Fast tomography reuses the catalog Methods directly.
-- **The simulated devices and full asset-tree scenarios.** No `test_faxtor_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/faxtor/notes.md b/docs/deployments/faxtor/notes.md
new file mode 100644
index 00000000000..16c63d7f5ec
--- /dev/null
+++ b/docs/deployments/faxtor/notes.md
@@ -0,0 +1,126 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of FAXTOR is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../alba/index.md#the-techniques-adapted-here) is how a facility adapts it. FAXTOR is a fast-imaging beamline: its tomography techniques reuse Methods CORA's catalog already carries, and its radiography is carried pending until it enters scope (`TECH-1`).
+
+### Fast tomography and radiography
+
+FAXTOR sets the X-ray energy with the multipole wiggler and the double multilayer monochromator (8-50 keV mono) or the filter set (30-70 keV filtered white beam), then rotates the sample on the experiment endstation while the scintillator and fast camera record projections. Continuous-rotation acquisition reaches up to 20 Hz, at 0.5-10 um pixel size, with absorption, propagation-phase, and grating-based contrast.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Tomography | [`tomography`](../../catalog/methods.md) | absorption and propagation-phase micro-CT on the [experiment endstation](sample.md), the [rotary stage](sample.md) stepped against the [scintillator + camera](detector.md); reuses the catalog tomography Method (the 2-BM pilot) |
+| Continuous-rotation tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | fast fly-scan tomography up to 20 Hz, the [rotary stage](sample.md) in continuous rotation as the trigger master (`TRIG-1`); reuses the catalog continuous-rotation Method |
+| Radiography | `radiography` | time-resolved single-projection radiography; reuses the 7-BM `radiography` slug, no portable Method in the catalog yet; pending (`TECH-1`) |
+
+Tomography needs the [incident energy](source.md) set by the [monochromator or filters](source.md), the [rotary stage and sample positioning](sample.md), and the [scintillator + fast camera](detector.md). Radiography needs the same beam and detector without the rotation sweep.
+
+### A new Site on familiar vocabulary
+
+FAXTOR is the fleet's fast-imaging beamline at ALBA, and it ties into the tomography lineage CORA already models: the same imaging device anatomy as the 2-BM pilot and the MAX IV TomoWISE design (a wiggler or undulator source, a multilayer monochromator, a rotary-stage endstation, and an indirect scintillator + camera detector). It reuses the `tomography` and `continuous_rotation_tomography` Methods directly; only radiography is carried pending, and none forces a new device family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the fly-scan tomography sequences and their counting times, the flat / dark sequencing, the phase-contrast and grating-based setups) are not written yet; they join as the deployment approaches the point where CORA drives FAXTOR. Whether radiography enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at FAXTOR, and the trust shape that will gate it. First cut.*
+
+Governance at FAXTOR follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ALBA Site](../alba/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+FAXTOR is CORA's first ALBA deployment, so ALBA is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ALBA Site](../alba/index.md#safety-and-governance), shared across the facility's beamlines, until ALBA staff confirm them (`GOV-1`). FAXTOR is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives FAXTOR, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. ALBA publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ALBA Site](../alba/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives FAXTOR, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's FAXTOR content lives, the new ALBA Site and Tango / Sardana control house-style it introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at FAXTOR |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes FAXTOR new
+
+FAXTOR is two things at the Site level and nothing new at the vocabulary level. It is CORA's **ninth Site** (ALBA, Barcelona), a re-test of the Site and Federation kernel, and the **second Tango / Sardana / Taurus** control plane CORA models. ALBA is the originating institution of Sardana (and of the Taurus GUI framework and the IcePAP motion controller), so this is the controls house-style's home facility; MAX IV (TomoWISE) was the first consumer CORA modelled. Its science is fast X-ray tomography and radiography on a multipole-wiggler source.
+
+### No new families (the imaging spine reuses the 2-BM / TomoWISE precedent)
+
+FAXTOR coins no new Family. The multipole wiggler binds the catalog `InsertionDevice`; the double multilayer monochromator binds `Monochromator`; the filters bind `Filter` and the slits bind `Slit`; the focusing mirrors bind `Mirror` (deferred, `OPT-1`); the experiment endstation binds `Table`, `RotaryStage`, `LinearStage`, and `Shutter`; the detector binds `Scintillator` and `Camera`; the machine state binds the loose `StorageRing`. Nothing in the catalog changes.
+
+### The Tango / Sardana control plane
+
+FAXTOR is the second Tango / Sardana / Taurus controls house-style in the fleet, after MAX IV TomoWISE. Device IO is a layer of Tango device servers (motors over IcePAP-class controllers, detectors via the Lima framework); Sardana provides the experiment-orchestration layer (a Pool of controllers / motors / measurement groups, plus a MacroServer running scan macros), and Taurus is the operator UI. ALBA publishes no per-beamline device manifest, so CORA does not bind the Tango / Sardana / IcePAP handles here; when bound they would be modelled as opaque edge strings over the `ControlPort`, the way the MX3 and ID32 heterogeneous-control precedents do (`CTRL-1`). The fast continuous-rotation tomography acquisition runs through Sardana macros; that orchestration is the seam CORA's edge replaces, conducting over Tango / IcePAP rather than replacing Sardana. The Lima detector file-writing to the ALBA data store is plumbing CORA observes, not data it owns.
+
+### Deliberately not here yet
+
+- **The control handles (`CTRL-1`).** No public per-beamline Tango / Sardana / IcePAP manifest exists; the handles are carried pending, not invented.
+- **The detector model (`DET-1`).** The fast camera and scintillator are bound to `Camera` and `Scintillator` but their models are unpublished, carried fully pending.
+- **The exact optics detail (`MONO-1`, `FILT-1`, `OPT-1`, `OPT-2`).** The DMM coating and energy partition, the filter set, the mirrors, and the slit blade map are carried confirm-pending.
+- **The endstation stage stack (`SAMPLE-1`, `TRIG-1`).** The rotary, positioning, table, and shutter are named; their axis sets, models, and the trigger scheme are pending.
+- **Radiography as a Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the 7-BM `radiography` slug. Fast tomography reuses the catalog Methods directly.
+- **The simulated devices and full asset-tree scenarios.** No `test_faxtor_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the FAXTOR team to confirm before the model can be trusted.*
+
+FAXTOR was reverse-engineered from ALBA's public facility pages ([cells.es/en/beamlines/bl31-faxtor](https://www.cells.es/en/beamlines/bl31-faxtor)) and a verified research brief, not from a live connection. ALBA publishes no per-beamline device manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. This is CORA's first ALBA Site and its second Tango / Sardana / Taurus controls house-style after MAX IV. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics hutch feeding one experiment hutch, or a different layout? | A `faxtor-optics` zone and a `faxtor-experiment` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The multipole-wiggler period, pole count, and field. | A multipole-wiggler source; period and field pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The ALBA storage-ring state FAXTOR reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The double multilayer monochromator coating, d-spacing, and the monochromatic / filtered-white energy partition. | A DMM bound to `Monochromator`; 8-50 keV mono, 30-70 keV filtered white. | The monochromator and energy modelling. |
+| FILT-1 | Nice-to-have | The filtered-white-beam filter materials and thicknesses. | A filter set bound to `Filter`. | The filter Asset detail. |
+| OPT-1 | Nice-to-have | The focusing / harmonic-rejection mirrors (presence, coatings, handles). | Mirrors bound to `Mirror`; absent from public sources, deferred. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The experiment-endstation stage stack: the rotary, the sample positioning, the table degrees of freedom, and the fast shutter. | A `RotaryStage`, `LinearStage`, `Table`, and `Shutter`; axis sets and models pending. | The sample-stage modelling. |
+| TRIG-1 | Nice-to-have | The triggering / synchronization scheme for continuous-rotation tomography. | The rotary stage is the master clock feeding the camera trigger. | The trigger wiring. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The fast imaging detector: the camera sensor, frame rate, and model, and the scintillator material and thickness. | A `Scintillator` plus a `Camera` supporting up to 20 Hz tomography; model not published, carried pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango / Sardana / IcePAP device handles per FAXTOR device (absent from any public manifest). | The handles are unbound, carried pending; the control plane is ALBA Tango / Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The ALBA personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling-water / beam supplies. | Photon beam, cooling water, and vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ALBA operator pool and safety-review structure (site-level). | Carried pending on the ALBA Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does radiography enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the 7-BM `radiography` slug; fast tomography reuses the catalog tomography Methods. | The technique Capabilities. |
diff --git a/docs/deployments/faxtor/questions.md b/docs/deployments/faxtor/questions.md
deleted file mode 100644
index ad90028b8ab..00000000000
--- a/docs/deployments/faxtor/questions.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Open questions
-
-*What CORA needs the FAXTOR team to confirm before the model can be trusted.*
-
-FAXTOR was reverse-engineered from ALBA's public facility pages ([cells.es/en/beamlines/bl31-faxtor](https://www.cells.es/en/beamlines/bl31-faxtor)) and a verified research brief, not from a live connection. ALBA publishes no per-beamline device manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. This is CORA's first ALBA Site and its second Tango / Sardana / Taurus controls house-style after MAX IV. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics hutch feeding one experiment hutch, or a different layout? | A `faxtor-optics` zone and a `faxtor-experiment` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The multipole-wiggler period, pole count, and field. | A multipole-wiggler source; period and field pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The ALBA storage-ring state FAXTOR reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The double multilayer monochromator coating, d-spacing, and the monochromatic / filtered-white energy partition. | A DMM bound to `Monochromator`; 8-50 keV mono, 30-70 keV filtered white. | The monochromator and energy modelling. |
-| FILT-1 | Nice-to-have | The filtered-white-beam filter materials and thicknesses. | A filter set bound to `Filter`. | The filter Asset detail. |
-| OPT-1 | Nice-to-have | The focusing / harmonic-rejection mirrors (presence, coatings, handles). | Mirrors bound to `Mirror`; absent from public sources, deferred. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The experiment-endstation stage stack: the rotary, the sample positioning, the table degrees of freedom, and the fast shutter. | A `RotaryStage`, `LinearStage`, `Table`, and `Shutter`; axis sets and models pending. | The sample-stage modelling. |
-| TRIG-1 | Nice-to-have | The triggering / synchronization scheme for continuous-rotation tomography. | The rotary stage is the master clock feeding the camera trigger. | The trigger wiring. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The fast imaging detector: the camera sensor, frame rate, and model, and the scintillator material and thickness. | A `Scintillator` plus a `Camera` supporting up to 20 Hz tomography; model not published, carried pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango / Sardana / IcePAP device handles per FAXTOR device (absent from any public manifest). | The handles are unbound, carried pending; the control plane is ALBA Tango / Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The ALBA personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling-water / beam supplies. | Photon beam, cooling water, and vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ALBA operator pool and safety-review structure (site-level). | Carried pending on the ALBA Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does radiography enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the 7-BM `radiography` slug; fast tomography reuses the catalog tomography Methods. | The technique Capabilities. |
diff --git a/docs/deployments/faxtor/techniques.md b/docs/deployments/faxtor/techniques.md
deleted file mode 100644
index f11f9669799..00000000000
--- a/docs/deployments/faxtor/techniques.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Techniques
-
-*What the modelled part of FAXTOR is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../alba/index.md#the-techniques-adapted-here) is how a facility adapts it. FAXTOR is a fast-imaging beamline: its tomography techniques reuse Methods CORA's catalog already carries, and its radiography is carried pending until it enters scope (`TECH-1`).
-
-## Fast tomography and radiography
-
-FAXTOR sets the X-ray energy with the multipole wiggler and the double multilayer monochromator (8-50 keV mono) or the filter set (30-70 keV filtered white beam), then rotates the sample on the experiment endstation while the scintillator and fast camera record projections. Continuous-rotation acquisition reaches up to 20 Hz, at 0.5-10 um pixel size, with absorption, propagation-phase, and grating-based contrast.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Tomography | [`tomography`](../../catalog/methods.md) | absorption and propagation-phase micro-CT on the [experiment endstation](sample.md), the [rotary stage](sample.md) stepped against the [scintillator + camera](detector.md); reuses the catalog tomography Method (the 2-BM pilot) |
-| Continuous-rotation tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | fast fly-scan tomography up to 20 Hz, the [rotary stage](sample.md) in continuous rotation as the trigger master (`TRIG-1`); reuses the catalog continuous-rotation Method |
-| Radiography | `radiography` | time-resolved single-projection radiography; reuses the 7-BM `radiography` slug, no portable Method in the catalog yet; pending (`TECH-1`) |
-
-Tomography needs the [incident energy](source.md) set by the [monochromator or filters](source.md), the [rotary stage and sample positioning](sample.md), and the [scintillator + fast camera](detector.md). Radiography needs the same beam and detector without the rotation sweep.
-
-## A new Site on familiar vocabulary
-
-FAXTOR is the fleet's fast-imaging beamline at ALBA, and it ties into the tomography lineage CORA already models: the same imaging device anatomy as the 2-BM pilot and the MAX IV TomoWISE design (a wiggler or undulator source, a multilayer monochromator, a rotary-stage endstation, and an indirect scintillator + camera detector). It reuses the `tomography` and `continuous_rotation_tomography` Methods directly; only radiography is carried pending, and none forces a new device family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the fly-scan tomography sequences and their counting times, the flat / dark sequencing, the phase-contrast and grating-based setups) are not written yet; they join as the deployment approaches the point where CORA drives FAXTOR. Whether radiography enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/fmx/governance.md b/docs/deployments/fmx/governance.md
deleted file mode 100644
index 280a2e19610..00000000000
--- a/docs/deployments/fmx/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at FMX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An FMX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, move the goniometer, start a rotation data collection or a grid scan, drive the robot, override a caution, or commit a beam-centre calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer (the LSDC Governor). The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## The autonomous loop under custody
-
-FMX's defining governance wrinkle is the unattended robot sample-exchange loop. CORA's Campaign, Trust, and Subject shapes are where that resolves: the robot loading a crystal is a command the trust boundary gates, and the crystal is a `Subject` whose custody (Received to mounted-on-goniometer to measured to Returned / Stored) is the record of record. The autonomous loop is gated by a `Clearance` issued after a safety review, exactly the i03 pattern. An autonomous Agent driving the load-centre-collect-unmount cycle would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; the autonomous-loop lifecycle is deferred (ROBOT-1).
diff --git a/docs/deployments/fmx/model.md b/docs/deployments/fmx/model.md
deleted file mode 100644
index e1070482110..00000000000
--- a/docs/deployments/fmx/model.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's FMX content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at FMX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (17-ID-A optics, 17-ID-C experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Subject (the crystal custody thread) | [Governance](governance.md#the-autonomous-loop-under-custody) (deferred, ROBOT-1) |
-| Procedure, Recipe, Caution, Supply, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates: nothing (and that is the finding)
-
-FMX is a clean **pure-reuse** deployment. As CORA's second MX beamline (after i03), its finding is that the MX vocabulary i03 earned generalizes to a second, independent facility with no new modelling: the graduated `Goniometer` (the single-omega micro-goniometer), the `Camera` (the Eiger), the graduated `Transfocator` (the CRL), the `Monochromator`, the `Mirror` (HFM + KB), the `Filter` (the BCU / RI attenuators), the `BeamStop`, the `FluxMonitor`, the catalog `Backlight` (graduated across the MX / imaging fleet), and the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux) all bind unchanged. The robot is one Positioner-presenting Asset, not a new Family (the i03 / 19-BM precedent). The one small modelling step beyond i03 is binding the Mercury fluorescence detector to the catalog `EnergyDispersiveSpectrometer` (i03 deferred its fluorescence detector); no new Family is coined.
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring i03 and the other NSLS-II beamlines. Left out on purpose:
-
-- **No catalog change.** FMX graduates nothing and coins nothing. The three MX Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) stay pending: FMX is their second consumer (after i03), which strengthens but does not force coining (Methods have no mechanical promotion, the `energy_scan` deferral discipline; TECH-1). The `Backlight` (i03 + i24 + FMX) has graduated to the catalog across the MX / imaging fleet (DET-1).
-- **The robot is not a Family.** The sample-changing robot is one Positioner-presenting Asset, gated by a Clearance, loading a `Subject`, vendor in a bound Model; not a new SampleChanger Family (the i03 / 19-BM precedent, adversarially verified there; ROBOT-1).
-- **The autonomous loop and the Subject custody thread.** The unattended exchange loop is a Procedure over the spine threaded through the `Subject` aggregate; it is the genuinely non-obvious MX modelling, deferred with i03 (ROBOT-1).
-- **Sample cryo-cooling.** The cold-gas cryostream is not exposed in the profile collection (an annealer / thaw-air actuator is), so it is deferred (CRYO-1); it would bind `TemperatureController` (the i03 cryostream precedent) when its PV is supplied.
-- **The fixed-target serial mode.** The chip-scanner serial-crystallography raster is named but not modelled; it would reuse the `serial_crystallography` Method (i24 / LCLS-MFX), deferred (SERIAL-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/fmx/notes.md b/docs/deployments/fmx/notes.md
new file mode 100644
index 00000000000..dddc33f5b6d
--- /dev/null
+++ b/docs/deployments/fmx/notes.md
@@ -0,0 +1,110 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at FMX: macromolecular crystallography, each a [Catalog](../../catalog/methods.md) Method. FMX is CORA's second MX beamline (after Diamond i03) and follows the same Method-deferral discipline.*
+
+FMX's science is protein crystallography: rotate a cryo-cooled crystal in a focused microbeam and read the diffraction on the Eiger, locate crystals with fast grid scans, and exchange samples with a robot. These are the MX Methods i03 brought to CORA; FMX is their second consumer. The Methods below render unlinked and stay pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Rotation (oscillation) data collection | monochromatic, microfocused | `AreaDetector` (Eiger, Detector Role) | the i03 `mx_data_collection` Method binding Goniometer + Eiger + vector + Zebra, pending; 2nd consumer (TECH-1) |
+| Grid scan / sample location | monochromatic, microfocused | `AreaDetector` + `SampleCamera` | the i03 `grid_scan` Method over the Zebra-triggered goniometer raster, pending; 2nd consumer (TECH-1) |
+| Autonomous sample exchange | n/a | n/a | the i03 `sample_exchange` Method: a Procedure over the spine + a Subject custody thread, pending; 2nd consumer (ROBOT-1) |
+| Anomalous element ID (fluorescence) | monochromatic, energy-swept | `FluorescenceDetector` (Mercury, Sensor) | the edge scan picks the energy for SAD / MAD; reuses the energy axis (DET-1) |
+| Fixed-target serial (chip) | monochromatic, microfocused | `AreaDetector` | the chip-scanner raster; reuses the `serial_crystallography` Method (i24 / LCLS-MFX), deferred (SERIAL-1) |
+
+### Why the Methods stay pending
+
+FMX reuses the three MX Methods Diamond i03 left pending. Unlike a loose device *Family* (which a second sighting promotes on a mechanical rule-of-three, as ISS did for the emission spectrometer), a pending *Method* has no automatic promotion: it is coined by deliberate decision when a conduct-path needs it, the same discipline that keeps `energy_scan` deferred even across several consumers. FMX makes each of `mx_data_collection`, `grid_scan`, and `sample_exchange` a two-consumer Method (i03 + FMX), which strengthens the eventual case to coin them but does not force it in a descriptor scaffold (TECH-1). The device Roles already exist (the graduated `Goniometer` presents Positioner, the Eiger presents Detector), so what is pending is the recipe, not a device shape.
+
+The autonomous sample-exchange loop is the genuinely non-obvious modelling: the unattended sequence (load pin, centre, collect, unmount, next) is a Procedure over the spine, threaded through the `Subject` custody lifecycle (Received to mounted to measured to Returned) and gated by a Clearance issued after a safety review. The robot itself is just a Positioner Asset; the workflow is the modelling (ROBOT-1). The per-experiment recipes (oscillation ranges, exposure, grid parameters, the exchange sequence) are calibration the deployment must supply.
+
+## Governance
+
+*Who may act at FMX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An FMX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, move the goniometer, start a rotation data collection or a grid scan, drive the robot, override a caution, or commit a beam-centre calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer (the LSDC Governor). The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### The autonomous loop under custody
+
+FMX's defining governance wrinkle is the unattended robot sample-exchange loop. CORA's Campaign, Trust, and Subject shapes are where that resolves: the robot loading a crystal is a command the trust boundary gates, and the crystal is a `Subject` whose custody (Received to mounted-on-goniometer to measured to Returned / Stored) is the record of record. The autonomous loop is gated by a `Clearance` issued after a safety review, exactly the i03 pattern. An autonomous Agent driving the load-centre-collect-unmount cycle would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; the autonomous-loop lifecycle is deferred (ROBOT-1).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's FMX content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at FMX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (17-ID-A optics, 17-ID-C experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Subject (the crystal custody thread) | [Governance](#the-autonomous-loop-under-custody) (deferred, ROBOT-1) |
+| Procedure, Recipe, Caution, Supply, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates: nothing (and that is the finding)
+
+FMX is a clean **pure-reuse** deployment. As CORA's second MX beamline (after i03), its finding is that the MX vocabulary i03 earned generalizes to a second, independent facility with no new modelling: the graduated `Goniometer` (the single-omega micro-goniometer), the `Camera` (the Eiger), the graduated `Transfocator` (the CRL), the `Monochromator`, the `Mirror` (HFM + KB), the `Filter` (the BCU / RI attenuators), the `BeamStop`, the `FluxMonitor`, the catalog `Backlight` (graduated across the MX / imaging fleet), and the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux) all bind unchanged. The robot is one Positioner-presenting Asset, not a new Family (the i03 / 19-BM precedent). The one small modelling step beyond i03 is binding the Mercury fluorescence detector to the catalog `EnergyDispersiveSpectrometer` (i03 deferred its fluorescence detector); no new Family is coined.
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring i03 and the other NSLS-II beamlines. Left out on purpose:
+
+- **No catalog change.** FMX graduates nothing and coins nothing. The three MX Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) stay pending: FMX is their second consumer (after i03), which strengthens but does not force coining (Methods have no mechanical promotion, the `energy_scan` deferral discipline; TECH-1). The `Backlight` (i03 + i24 + FMX) has graduated to the catalog across the MX / imaging fleet (DET-1).
+- **The robot is not a Family.** The sample-changing robot is one Positioner-presenting Asset, gated by a Clearance, loading a `Subject`, vendor in a bound Model; not a new SampleChanger Family (the i03 / 19-BM precedent, adversarially verified there; ROBOT-1).
+- **The autonomous loop and the Subject custody thread.** The unattended exchange loop is a Procedure over the spine threaded through the `Subject` aggregate; it is the genuinely non-obvious MX modelling, deferred with i03 (ROBOT-1).
+- **Sample cryo-cooling.** The cold-gas cryostream is not exposed in the profile collection (an annealer / thaw-air actuator is), so it is deferred (CRYO-1); it would bind `TemperatureController` (the i03 cryostream precedent) when its PV is supplied.
+- **The fixed-target serial mode.** The chip-scanner serial-crystallography raster is named but not modelled; it would reuse the `serial_crystallography` Method (i24 / LCLS-MFX), deferred (SERIAL-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the FMX team to confirm. This model is reverse-engineered from public open source (the `NSLS2/fmx-profile-collection` bluesky / ophyd startup files; the MX acquisition logic lives in the `lsdc` / `mxtools` libraries): the EPICS PVs are read from the `startup/*.py` device classes, but the goniometer / robot / detector vendor identities, the crystal cut, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The IVU21 undulator period, gap range, and gap-to-energy curve. The device (`SR:C17-ID:G1{IVU21:2}`) is in source; the parameters are not. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
+| TOPO-1 | Nice-to-have | FMX (17-ID-2) shares the IVU21 undulator and the 17-ID straight with AMX (17-ID-1). Is the straight canted (two beams), and is one root Unit per branch the right model? | One root Unit feeding the 17-ID-2 branch (the CSX / 32-ID canted precedent); AMX is the sibling branch. | The sector topology and the AMX relationship. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:17ID-PPS:FAMX{Sh:FE}`, `XF:17IDA-PPS:FMX{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The HDCM crystal cut, d-spacing, and energy range. The monochromator (`Mono:DCM`) and its axes are in source. | One Monochromator Asset, crystal settings blank. | The Monochromator settings. |
+| KB-1 | Nice-to-have | The HFM and KB mirror coatings, the bimorph calibration, and the CRL transfocator lens count and focal configuration. The mirrors (`Mir:HFM`, `Mir:KBH/KBV`) and the CRL (`CRL:`) are in source. | The mirror / CRL internals are per-Asset settings on the existing Mirror / Transfocator Families. | The focusing-optic settings. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The goniometer axis decomposition (single omega + GX / GY / GZ centring + PY / PZ pin + PI fine) and the centre-of-rotation calibration. The stack (`Gon:1`) is in source. | A `Goniometer` Asset (catalog Family, graduated on the i03 Smargon); per-axis decomposition to confirm. | The goniometer model. |
+| ROBOT-1 | Blocks-go-live | The sample-changing robot model, the dewar / puck layout, the exchange workflow, and the Subject custody lifecycle. The Governor state machine (`Gov:Robot`) and the dewar interlock (`DewarSwitch`) are in source. | One Positioner-presenting `Robot` Asset (not a new Family); the autonomous loop is a Procedure + a Subject custody thread, gated by a Clearance. | The robot model and the autonomous-loop modelling. |
+| DET-1 | Blocks-go-live | The Eiger model and beam centre, and the Mercury fluorescence detector element count and ROI map. The Eiger (`Det:Eig16M`) and the Mercury (`Det:Mer`) are in source. | An Eiger 16M (`Camera`) and a Mercury (`EnergyDispersiveSpectrometer`); model / ROIs to confirm. | The detector roster. |
+| DIAG-1 | Nice-to-have | The beam-position channel map (the Prosilica BPM cameras, the sector XBPM); the `PositionMonitor` Family is graduated (catalog, presenting `Sensor`), only the per-Asset channel map stays pending. | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The PositionMonitor bindings. |
+| CRYO-1 | Nice-to-have | The sample cryo-cooling (cold-gas cryostream) and the annealer / thaw-air actuator. The annealer (`Wago:`) is in source; the cryostream IOC is not. | Sample cooling deferred; the annealer named, the cryostream a `TemperatureController` when its PV is supplied. | The sample-environment Assets. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the PowerBrick / PPMAC vector controller `Gon:1-Vec` / `MC17:Sender`, the Zebra `Zeb:3`, and the EPICS motor records). | Families bound (MotionController, TimingController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the MX Methods (rotation `mx_data_collection`, `grid_scan`, `sample_exchange`) enter CORA's catalog, or stay pending? FMX is the second consumer after i03. | The three Methods reused pending (no mechanical promotion for Methods; the energy_scan deferral discipline); no new Method coined. | The MX Method scope. |
+| SERIAL-1 | Nice-to-have | The fixed-target chip-scanner serial-crystallography mode (the Oxford chip raster, a PPMAC on-the-fly motion). Is it modelled, and does it reuse the `serial_crystallography` Method (i24 / LCLS-MFX)? | Deferred; FMX's primary mode is rotation MX, the chip-scanner mode is named here. | The serial-mode Assets and Method. |
diff --git a/docs/deployments/fmx/questions.md b/docs/deployments/fmx/questions.md
deleted file mode 100644
index 43a9e5c6907..00000000000
--- a/docs/deployments/fmx/questions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Open questions
-
-*What CORA needs the FMX team to confirm. This model is reverse-engineered from public open source (the `NSLS2/fmx-profile-collection` bluesky / ophyd startup files; the MX acquisition logic lives in the `lsdc` / `mxtools` libraries): the EPICS PVs are read from the `startup/*.py` device classes, but the goniometer / robot / detector vendor identities, the crystal cut, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The IVU21 undulator period, gap range, and gap-to-energy curve. The device (`SR:C17-ID:G1{IVU21:2}`) is in source; the parameters are not. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
-| TOPO-1 | Nice-to-have | FMX (17-ID-2) shares the IVU21 undulator and the 17-ID straight with AMX (17-ID-1). Is the straight canted (two beams), and is one root Unit per branch the right model? | One root Unit feeding the 17-ID-2 branch (the CSX / 32-ID canted precedent); AMX is the sibling branch. | The sector topology and the AMX relationship. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:17ID-PPS:FAMX{Sh:FE}`, `XF:17IDA-PPS:FMX{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The HDCM crystal cut, d-spacing, and energy range. The monochromator (`Mono:DCM`) and its axes are in source. | One Monochromator Asset, crystal settings blank. | The Monochromator settings. |
-| KB-1 | Nice-to-have | The HFM and KB mirror coatings, the bimorph calibration, and the CRL transfocator lens count and focal configuration. The mirrors (`Mir:HFM`, `Mir:KBH/KBV`) and the CRL (`CRL:`) are in source. | The mirror / CRL internals are per-Asset settings on the existing Mirror / Transfocator Families. | The focusing-optic settings. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The goniometer axis decomposition (single omega + GX / GY / GZ centring + PY / PZ pin + PI fine) and the centre-of-rotation calibration. The stack (`Gon:1`) is in source. | A `Goniometer` Asset (catalog Family, graduated on the i03 Smargon); per-axis decomposition to confirm. | The goniometer model. |
-| ROBOT-1 | Blocks-go-live | The sample-changing robot model, the dewar / puck layout, the exchange workflow, and the Subject custody lifecycle. The Governor state machine (`Gov:Robot`) and the dewar interlock (`DewarSwitch`) are in source. | One Positioner-presenting `Robot` Asset (not a new Family); the autonomous loop is a Procedure + a Subject custody thread, gated by a Clearance. | The robot model and the autonomous-loop modelling. |
-| DET-1 | Blocks-go-live | The Eiger model and beam centre, and the Mercury fluorescence detector element count and ROI map. The Eiger (`Det:Eig16M`) and the Mercury (`Det:Mer`) are in source. | An Eiger 16M (`Camera`) and a Mercury (`EnergyDispersiveSpectrometer`); model / ROIs to confirm. | The detector roster. |
-| DIAG-1 | Nice-to-have | The beam-position channel map (the Prosilica BPM cameras, the sector XBPM); the `PositionMonitor` Family is graduated (catalog, presenting `Sensor`), only the per-Asset channel map stays pending. | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The PositionMonitor bindings. |
-| CRYO-1 | Nice-to-have | The sample cryo-cooling (cold-gas cryostream) and the annealer / thaw-air actuator. The annealer (`Wago:`) is in source; the cryostream IOC is not. | Sample cooling deferred; the annealer named, the cryostream a `TemperatureController` when its PV is supplied. | The sample-environment Assets. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the PowerBrick / PPMAC vector controller `Gon:1-Vec` / `MC17:Sender`, the Zebra `Zeb:3`, and the EPICS motor records). | Families bound (MotionController, TimingController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the MX Methods (rotation `mx_data_collection`, `grid_scan`, `sample_exchange`) enter CORA's catalog, or stay pending? FMX is the second consumer after i03. | The three Methods reused pending (no mechanical promotion for Methods; the energy_scan deferral discipline); no new Method coined. | The MX Method scope. |
-| SERIAL-1 | Nice-to-have | The fixed-target chip-scanner serial-crystallography mode (the Oxford chip raster, a PPMAC on-the-fly motion). Is it modelled, and does it reuse the `serial_crystallography` Method (i24 / LCLS-MFX)? | Deferred; FMX's primary mode is rotation MX, the chip-scanner mode is named here. | The serial-mode Assets and Method. |
diff --git a/docs/deployments/fmx/techniques.md b/docs/deployments/fmx/techniques.md
deleted file mode 100644
index 92172313633..00000000000
--- a/docs/deployments/fmx/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What CORA would run at FMX: macromolecular crystallography, each a [Catalog](../../catalog/methods.md) Method. FMX is CORA's second MX beamline (after Diamond i03) and follows the same Method-deferral discipline.*
-
-FMX's science is protein crystallography: rotate a cryo-cooled crystal in a focused microbeam and read the diffraction on the Eiger, locate crystals with fast grid scans, and exchange samples with a robot. These are the MX Methods i03 brought to CORA; FMX is their second consumer. The Methods below render unlinked and stay pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Rotation (oscillation) data collection | monochromatic, microfocused | `AreaDetector` (Eiger, Detector Role) | the i03 `mx_data_collection` Method binding Goniometer + Eiger + vector + Zebra, pending; 2nd consumer (TECH-1) |
-| Grid scan / sample location | monochromatic, microfocused | `AreaDetector` + `SampleCamera` | the i03 `grid_scan` Method over the Zebra-triggered goniometer raster, pending; 2nd consumer (TECH-1) |
-| Autonomous sample exchange | n/a | n/a | the i03 `sample_exchange` Method: a Procedure over the spine + a Subject custody thread, pending; 2nd consumer (ROBOT-1) |
-| Anomalous element ID (fluorescence) | monochromatic, energy-swept | `FluorescenceDetector` (Mercury, Sensor) | the edge scan picks the energy for SAD / MAD; reuses the energy axis (DET-1) |
-| Fixed-target serial (chip) | monochromatic, microfocused | `AreaDetector` | the chip-scanner raster; reuses the `serial_crystallography` Method (i24 / LCLS-MFX), deferred (SERIAL-1) |
-
-## Why the Methods stay pending
-
-FMX reuses the three MX Methods Diamond i03 left pending. Unlike a loose device *Family* (which a second sighting promotes on a mechanical rule-of-three, as ISS did for the emission spectrometer), a pending *Method* has no automatic promotion: it is coined by deliberate decision when a conduct-path needs it, the same discipline that keeps `energy_scan` deferred even across several consumers. FMX makes each of `mx_data_collection`, `grid_scan`, and `sample_exchange` a two-consumer Method (i03 + FMX), which strengthens the eventual case to coin them but does not force it in a descriptor scaffold (TECH-1). The device Roles already exist (the graduated `Goniometer` presents Positioner, the Eiger presents Detector), so what is pending is the recipe, not a device shape.
-
-The autonomous sample-exchange loop is the genuinely non-obvious modelling: the unattended sequence (load pin, centre, collect, unmount, next) is a Procedure over the spine, threaded through the `Subject` custody lifecycle (Received to mounted to measured to Returned) and gated by a Clearance issued after a safety review. The robot itself is just a Positioner Asset; the workflow is the modelling (ROBOT-1). The per-experiment recipes (oscillation ranges, exposure, grid parameters, the exchange sequence) are calibration the deployment must supply.
diff --git a/docs/deployments/fxi/governance.md b/docs/deployments/fxi/governance.md
deleted file mode 100644
index 00357ffa880..00000000000
--- a/docs/deployments/fxi/governance.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Governance
-
-*Who may act at FXI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not yet known (GOV-1), so the principals below are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An FXI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The concrete people and their role assignments are pending staff confirmation (GOV-1).
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a run, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer.
-
-Two facts from the facility flow into this design:
-
-- Proposal custody. An NSLS-II beamtime is scoped to a proposal and cycle. CORA uses that proposal/cycle as the Campaign and the custody key for who is entitled to act during a beamtime; it confirms entitlement against the facility's proposal identity but applies its own per-Actor authority on top.
-- The floor already has a coarse, group-level command-authority layer at the controls level. CORA does not adopt it: CORA's per-Actor Trust model supersedes it with finer, auditable authority.
-
-No autonomous or adaptive agent Actor is declared for FXI yet. If one were added (an alignment or experiment-steering agent), it would be a facility principal scoped at the Site, governed by the same Trust boundary, and each proposed move would be a [Decision](../../architecture/modules/decision/index.md) (the inference-recorder path for any LLM-backed agent).
diff --git a/docs/deployments/fxi/model.md b/docs/deployments/fxi/model.md
deleted file mode 100644
index 897453cb5dc..00000000000
--- a/docs/deployments/fxi/model.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's FXI content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at FXI |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (XEng) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) (18-IDA optics, 18-IDB endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), reverse-engineered from the profile collection. Left out on purpose:
-
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
-- **`BertrandLens` catalog graduation.** A loose family at its only sighting (OPTIC-3); graduates at a second deployment.
diff --git a/docs/deployments/fxi/questions.md b/docs/deployments/fxi/notes.md
similarity index 53%
rename from docs/deployments/fxi/questions.md
rename to docs/deployments/fxi/notes.md
index b998e340666..0b83ce3d9e1 100644
--- a/docs/deployments/fxi/questions.md
+++ b/docs/deployments/fxi/notes.md
@@ -1,10 +1,88 @@
-# Open questions
+# Notes
+
+## Techniques
+
+*What CORA would run at FXI: the Capabilities and portable [Catalog](../../catalog/methods.md) Methods CORA brings, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). The function view survives equipment swaps.*
+
+FXI is a full-field transmission X-ray microscope that does fly and step tomography, mosaic tomography, radiography, and XANES / spectro-tomography. These are the same techniques the 2-BM pilot exercised, so CORA expresses each as a Catalog Method it already carries: a second tomography deployment proves the Methods are portable across facilities. (The "demonstrated by" column names the floor plan that shows FXI runs the technique today; CORA replaces that orchestration with its Conductor, see [Controls](controls.md).)
+
+### Imaging
+
+| CORA does | Catalog Method | Demonstrated by (floor) |
+| --- | --- | --- |
+| Continuous-rotation fly tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | position-triggered fly scan |
+| Step tomography | [`tomography`](../../catalog/methods.md) | stop-and-shoot projections |
+| Mosaic tomography | [`mosaic_tomography`](../../catalog/methods.md) | tiled fields for large samples |
+| Radiography | [`tomography`](../../catalog/methods.md) | single-angle projection series (carried under the tomography family pending a dedicated Method) |
+| Flat / dark acquisition | [`flat_field`](../../catalog/methods.md), [`dark_field`](../../catalog/methods.md) | reference-frame capture per scan |
+
+### Spectroscopy
+
+| CORA does | Catalog Method | Demonstrated by (floor) |
+| --- | --- | --- |
+| XANES imaging / spectro-tomography | [`tomography`](../../catalog/methods.md) + [`beamline_energy_change`](../../catalog/methods.md) | energy-resolved imaging across an edge |
+| Energy change | [`beamline_energy_change`](../../catalog/methods.md) | the coupled energy move that co-moves the zone plate, condenser, and detector to hold magnification constant |
+
+### Supporting operations
+
+| CORA does | Catalog Method | Demonstrated by (floor) |
+| --- | --- | --- |
+| Rotation-center finding | [`center_alignment`](../../catalog/methods.md) | center search during reconstruction |
+| Calibration-position recording | [`focus_alignment`](../../catalog/methods.md) | building the energy lookup table |
+
+Reconstruction (the tomographic recon, ring removal, rotation-center search) is CORA's compute leg, conducted over the ComputePort rather than as a beamline Method; see [Controls](controls.md).
+
+## Governance
+
+*Who may act at FXI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not yet known (GOV-1), so the principals below are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An FXI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The concrete people and their role assignments are pending staff confirmation (GOV-1).
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a run, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer.
+
+Two facts from the facility flow into this design:
+
+- Proposal custody. An NSLS-II beamtime is scoped to a proposal and cycle. CORA uses that proposal/cycle as the Campaign and the custody key for who is entitled to act during a beamtime; it confirms entitlement against the facility's proposal identity but applies its own per-Actor authority on top.
+- The floor already has a coarse, group-level command-authority layer at the controls level. CORA does not adopt it: CORA's per-Actor Trust model supersedes it with finer, auditable authority.
+
+No autonomous or adaptive agent Actor is declared for FXI yet. If one were added (an alignment or experiment-steering agent), it would be a facility principal scoped at the Site, governed by the same Trust boundary, and each proposed move would be a [Decision](../../architecture/modules/decision/index.md) (the inference-recorder path for any LLM-backed agent).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's FXI content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at FXI |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (XEng) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) (18-IDA optics, 18-IDB endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), reverse-engineered from the profile collection. Left out on purpose:
+
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+- **`BertrandLens` catalog graduation.** A loose family at its only sighting (OPTIC-3); graduates at a second deployment.
+
+## Open questions
 
 *What CORA needs the FXI team to confirm before the model can be trusted.*
 
 This model is reverse-engineered from public NSLS-II open source (the bluesky profile collection [`NSLS2/fxi-profile-collection`](https://github.com/NSLS2/fxi-profile-collection) and the shared `NSLS2/nslsii` package), so this page is long by design: the EPICS PVs are read straight from the profile collection, but vendor identities, controller boxes, physical positions, and the safety layer are not in it. Each row is a fact the beamline team or an IOC `st.cmd` file owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before CORA controls or observes the hardware), and `Nice-to-have`.
 
-## Source and safety
+### Source and safety
 
 | ID | Priority | Question | CORA assumes | Resolves |
 | --- | --- | --- | --- | --- |
@@ -13,7 +91,7 @@ This model is reverse-engineered from public NSLS-II open source (the bluesky pr
 | ENC-1 | Nice-to-have | Is the `XF:18ID1-ES` namespace (where the Kinetix camera lives) a distinct endstation area, or part of 18-IDB? | Two enclosures (18-IDA optics, 18-IDB experiment); 18ID1-ES folded into 18-IDB. | The Enclosure set and roles. |
 | LAYOUT-1 | Nice-to-have | What are the device z positions along the beam? The profile collection carries no layout or z reference. | No z values are recorded; the device order is the source/sample/detection grouping only. | Device z positions. |
 
-## Optics
+### Optics
 
 | ID | Priority | Question | CORA assumes | Resolves |
 | --- | --- | --- | --- | --- |
@@ -24,7 +102,7 @@ This model is reverse-engineered from public NSLS-II open source (the bluesky pr
 | OPTIC-4 | Nice-to-have | Confirm the zone-plate values: NanoTools, 244 um diameter, 30 nm outer zone width. These are code constants, not staff-verified. | The code-constant values, carried `confirm`. | The ZonePlate settings. |
 | FILT-1 | Nice-to-have | What are the materials and thicknesses of the eight pneumatic filter foils (relays on a Moxa ioLogik E1211)? | Eight foils, materials unknown. | The Filter foil settings. |
 
-## Sample and detector
+### Sample and detector
 
 | ID | Priority | Question | CORA assumes | Resolves |
 | --- | --- | --- | --- | --- |
@@ -37,14 +115,14 @@ This model is reverse-engineered from public NSLS-II open source (the bluesky pr
 | DIAG-1 | Nice-to-have | What are the ion-chamber channel PV suffixes (`ic1..ic4`, i404 quad electrometer)? | Read-only intensity probes, suffixes blank. | The IonChamber bindings. |
 | ENV-1 | Nice-to-have | Is the Lakeshore 336 sample-environment temperature controller installed? It is disabled in source (`motor_lakeshore = []`). | Not modeled as a live device. | The sample-environment controller. |
 
-## Controls and data
+### Controls and data
 
 | ID | Priority | Question | CORA assumes | Resolves |
 | --- | --- | --- | --- | --- |
 | DRIVE-1 | Blocks-go-live | What are the motion-controller boxes behind the EpicsMotors (model, protocol, axis count, serial, firmware, IP), and which IOC drives each device group? Confirmed not in public open source: FXI has no IOC-config repo, and its per-beamline IOC inventory (Ansible `nsls2.ioc_deploy` device roles + a `<bl>-epics-containers` repo) is ops-private. Needs FXI staff or inventory access. | Families only; box identities unknown. | The MotionController Models and the Drive identities. |
 | ZEBRA-1 | Nice-to-have | Are there two position-trigger boxes? One is instantiated; a second is referenced in the public config. What is each wired to? | One trigger box, reading the rotary as the master encoder. | The TimingController set. |
 
-## Governance
+### Governance
 
 | ID | Priority | Question | CORA assumes | Resolves |
 | --- | --- | --- | --- | --- |
diff --git a/docs/deployments/fxi/techniques.md b/docs/deployments/fxi/techniques.md
deleted file mode 100644
index 91ced6ff5b5..00000000000
--- a/docs/deployments/fxi/techniques.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Techniques
-
-*What CORA would run at FXI: the Capabilities and portable [Catalog](../../catalog/methods.md) Methods CORA brings, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). The function view survives equipment swaps.*
-
-FXI is a full-field transmission X-ray microscope that does fly and step tomography, mosaic tomography, radiography, and XANES / spectro-tomography. These are the same techniques the 2-BM pilot exercised, so CORA expresses each as a Catalog Method it already carries: a second tomography deployment proves the Methods are portable across facilities. (The "demonstrated by" column names the floor plan that shows FXI runs the technique today; CORA replaces that orchestration with its Conductor, see [Controls](controls.md).)
-
-## Imaging
-
-| CORA does | Catalog Method | Demonstrated by (floor) |
-| --- | --- | --- |
-| Continuous-rotation fly tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | position-triggered fly scan |
-| Step tomography | [`tomography`](../../catalog/methods.md) | stop-and-shoot projections |
-| Mosaic tomography | [`mosaic_tomography`](../../catalog/methods.md) | tiled fields for large samples |
-| Radiography | [`tomography`](../../catalog/methods.md) | single-angle projection series (carried under the tomography family pending a dedicated Method) |
-| Flat / dark acquisition | [`flat_field`](../../catalog/methods.md), [`dark_field`](../../catalog/methods.md) | reference-frame capture per scan |
-
-## Spectroscopy
-
-| CORA does | Catalog Method | Demonstrated by (floor) |
-| --- | --- | --- |
-| XANES imaging / spectro-tomography | [`tomography`](../../catalog/methods.md) + [`beamline_energy_change`](../../catalog/methods.md) | energy-resolved imaging across an edge |
-| Energy change | [`beamline_energy_change`](../../catalog/methods.md) | the coupled energy move that co-moves the zone plate, condenser, and detector to hold magnification constant |
-
-## Supporting operations
-
-| CORA does | Catalog Method | Demonstrated by (floor) |
-| --- | --- | --- |
-| Rotation-center finding | [`center_alignment`](../../catalog/methods.md) | center search during reconstruction |
-| Calibration-position recording | [`focus_alignment`](../../catalog/methods.md) | building the energy lookup table |
-
-Reconstruction (the tomographic recon, ring removal, rotation-center search) is CORA's compute leg, conducted over the ComputePort rather than as a beamline Method; see [Controls](controls.md).
diff --git a/docs/deployments/hex/governance.md b/docs/deployments/hex/governance.md
deleted file mode 100644
index 7b9ebe87317..00000000000
--- a/docs/deployments/hex/governance.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Governance
-
-*Who will act at HEX, and the trust shape that will gate it. First cut.*
-
-Governance at HEX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-HEX is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
-
-## A distinct allocation policy
-
-HEX has one governance fact the other NSLS-II beamlines do not: a share of its beamtime is reserved for proposals aligned with New York clean-energy and energy-storage goals. Public sources describe a portion of beamtime set aside for such proposals, evaluated by a dedicated proposal-evaluation committee on weighted criteria (technical merit, New York commercial relevance, economic development, and personnel), with the remainder allocated through the standard NSLS-II proposal review and all proposals administered through the facility proposal system. This is a real, distinct trust-shape input: an allocation Policy that gates which experiments run, layered on top of the facility-wide safety and access tiers.
-
-CORA records this as a Policy-level fact, not a new bounded context or descriptor. The exact reservation fraction and the committee's scoring split are carried as a world-fact (`GOV-1`) and are modelled when CORA drives the beamline, not instantiated now. The allocation Policy binds to the NSLS-II operator and review roles carried pending at the Site.
-
-## The safety boundary
-
-The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-HEX adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
-
-| Hazard class | Where it lands | Tracking |
-| --- | --- | --- |
-| High-energy hard X-ray beam (white to 250 keV, monochromatic to 200 keV) | the [optics](index.md) and [endstation](index.md) enclosures (`hex-foe`, `hex-endstation`) | (`PSS-1`, `SCW-1`) |
-| The superconducting wiggler source | the [Source](source.md) walk (cryogen-free, no liquid-helium hazard) | (`SCW-1`) |
-| Heavy-sample handling (up to 500 kg) | the [Sample](sample.md) tower | (`STAGE-1`) |
-| User-brought in-situ / operando environments | the [Sample](sample.md) endstation | (`INSITU-1`) |
-
-The high-energy beam is the interlocked hazard, and at these photon energies the shielding burden is heavier than the fleet's lower-energy beamlines; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The superconducting wiggler is cryogen-free, so no liquid-helium supply hazard is carried (`SCW-1`). The heavy-sample handling and the user-brought in-situ environments are operational hazards carried with the equipment that brings them (`STAGE-1`, `INSITU-1`); none is invented, each is recorded against its question.
-
-## When the shape lands
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives HEX, following the [2-BM governance](../2-bm/governance.md) shape. Because HEX shares the NSLS-II EPICS and ophyd floor with its siblings, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Conduit binds the command surfaces; the Policies bind to the NSLS-II operator roles carried pending at the Site, with the NYSERDA-aligned allocation Policy layered on top (`GOV-1`).
diff --git a/docs/deployments/hex/model.md b/docs/deployments/hex/model.md
deleted file mode 100644
index d711d2c8d1f..00000000000
--- a/docs/deployments/hex/model.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's HEX content lives, how it models the multi-technique endstation and the heavy sample tower, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at HEX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes HEX new
-
-The honest answer is: not much on any single technique, and three real things on structure. HEX measures engineering-materials and energy-storage samples by high-energy imaging / tomography, energy-dispersive diffraction (EDXD), and angle-dispersive / powder diffraction (ADXD). The imaging overlaps the fleet heavily (the 2-BM pilot, the NSLS-II FXI), and the diffraction reuses the pending energy-dispersive (7-BM) and powder (i11) Methods. That side reuses the existing `Camera` / `Scintillator` / `RotaryStage` / `LinearStage` / `EnergyDispersiveSpectrometer` / `InsertionDevice` / `Monochromator` / `Filter` vocabulary and contributes reinforcement, not novelty.
-
-HEX's three genuinely distinct contributions are:
-
-- **Multi-technique in one experiment.** All three techniques run in the single F-hutch endstation during one experiment, with detectors and optics moved into the beam remotely. CORA models this as multiple Methods over one endstation, the technique switch a positioning leg over the `ControlPort`, not a new Capability (`TECH-1`).
-- **Very large and heavy engineering samples.** The 500 kg removable sample tower is a heavy reconfigurable fixture, not a precision goniometer. It reuses `Table` + `RotaryStage` + `LinearStage` with capacity and the configuration set as settings (`STAGE-1`).
-- **A high-energy hard X-ray source.** The superconducting wiggler (4.3 T, 70 mm period) reaching 200 keV monochromatic is a first for the fleet. It binds the existing `InsertionDevice` Family, with the field and energy reach as source specs (`SCW-1`).
-
-## No new families
-
-HEX coins no new Family and changes nothing in the catalog.
-
-- **The superconducting wiggler binds `InsertionDevice`** (the undulator precedent at the NSLS-II siblings). The beam mode (white 30 to 250 keV versus monochromatic 30 to 200 keV) is selected by inserting or retracting the monochromator first crystal, so it is a setting on the optic, not a second source (`MONO-2`).
-- **The optics reuse:** the low-energy filters bind `Filter`; the bent-Laue monochromator binds `Monochromator` (a Bragg optic, not the soft X-ray `GratingMonochromator`); the incident energy is a `PseudoAxis` over it; the front-end slits bind `Slit`.
-- **The sample side reuses:** the tomographic rotation binds `RotaryStage`; the sample translations bind `LinearStage`; the 500 kg removable tower binds `Table`.
-- **The detection side reuses:** the Kinetix sCMOS and Phantom Veo cameras and the PerkinElmer flat panel bind `Camera`; the imaging scintillator-lens table binds `Scintillator`; the detector / optics positioning binds `LinearStage`; the GeRM germanium strip detector binds the existing `EnergyDispersiveSpectrometer` Family (below).
-
-## The GeRM strip detector reuses an earned family
-
-The one place HEX looks like it might force a new abstraction is its energy-dispersive detector, the GeRM germanium strip detector that produces a per-channel energy spectrum rather than a 2D frame. That shape is already in the catalog: the `EnergyDispersiveSpectrometer` Family was earned by the APS 2-ID fluorescence detector and the 7-BM germanium energy-dispersive-diffraction detector, and its definition presents the `Sensor` Role (a scalar or short-vector Reading per point) and explicitly spans the silicon-drift and germanium variants. HEX's GeRM detector is the **third consumer** of that Family, with channel count and energy resolution per-Asset settings. So EDXD on HEX is a reuse, not a graduation, and no catalog or loose-family change is forced (`DET-2`).
-
-## How the multi-technique switch is modelled (no new capability)
-
-The F-hutch offers imaging / tomography, EDXD, and ADXD in one experiment. CORA models the switch between them as a **positioning action over existing devices**, not a new Capability or device:
-
-- each technique has its detector already on the [detection](detector.md) side (the Kinetix cameras, the PerkinElmer flat panel, the GeRM strip detector);
-- a `LinearStage` (`DetectorStage`) moves the chosen detector or optic into the beam;
-- CORA conducts that positioning over the `ControlPort`, then runs the technique's Method.
-
-So the "multi-technique endstation" is a Practice-level sequence, not a fused mega-instrument. The stress it puts on the model, that a single endstation hosts several one-technique acquisitions selected by positioning, is resolved by treating technique selection as a conducted positioning leg ahead of acquisition (`TECH-1`). No new family is coined for the switch.
-
-## Deliberately not here yet
-
-- **The B / C / D / E hutch contents (`ENC-1`, `LAYOUT-1`).** HEX is designed for six enclosures (A = FOE, B, C, D, E, F). All six are declared in the descriptor, forward-looking, but only the operational FOE (`hex-foe`) and F-hutch (`hex-endstation`) carry devices; B (not erected) and C / D / E (future-upgrade shells) are declared as device-free enclosures and carry no Assets in this cut. The descriptor validates that every device's enclosure ref is declared but allows an unreferenced enclosure, so the shells are honest forward-looking placeholders, not invented contents. The satellite-building identity and the per-hutch positions are carried as world-facts (`SAT-1`, `LAYOUT-1`).
-- **The monochromatic focusing optic (`FOCUS-1`).** The beamline page lists focusing for the monochromatic beam as "being commissioned." It is not yet modelled as a device; what optic it is and its target spot are carried as a world-fact.
-- **In-situ sample environments (`INSITU-1`).** HEX's science is operando battery and engineering-materials work, but no specific rig (load frame, furnace, cryostat, battery cycler) is source-confirmed as installed; the endstation is "capable of housing" user-brought environments. Per earn-the-abstraction, no in-situ rig is modelled as an Asset in this cut. If a specific rig is confirmed installed and a second fleet beamline brings one, that is the trigger to consider a sample-environment Family.
-- **The heavy-sample stage as a distinct family (`STAGE-1`).** The 500 kg removable tower stresses the assumption that a sample-orientation Asset is small and goniometer-like. CORA holds the line: capacity and the configuration set (configs A to D) are settings on a reused `Table` + `RotaryStage` + `LinearStage`, not a new `HeavyStage` Family. A second fleet beamline with a heavy removable tower would be the rule-of-three trigger.
-- **The diffraction Methods.** Whether energy-dispersive diffraction, radiography, and powder diffraction enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. EDXD and radiography are shared with 7-BM and powder diffraction with i11 (`TECH-1`).
-- **Pair-distribution-function and 3DXRD.** Public sources do not list PDF (that is NSLS-II 28-ID / [XPD](../xpd/index.md)) or three-dimensional X-ray diffraction for HEX, so neither is modelled or assumed (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_hex_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/hex/notes.md b/docs/deployments/hex/notes.md
new file mode 100644
index 00000000000..270560b819c
--- /dev/null
+++ b/docs/deployments/hex/notes.md
@@ -0,0 +1,191 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of HEX is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. HEX measures engineering-materials and energy-storage samples three ways, all in the single operational endstation and all at high X-ray energy: X-ray imaging and tomography, energy-dispersive X-ray diffraction (EDXD), and angle-dispersive / powder diffraction (ADXD). One of those, tomography, is a Method CORA already holds; the rest render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings them into the catalog.
+
+HEX is mostly reinforcement of imaging and high-energy diffraction the fleet already speaks. Read this page for the one thing that is structurally distinct: all three techniques run in the same experiment, with detectors and optics moved into the beam remotely.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray tomography and CT | `tomography` | high-energy white-beam and monochromatic tomography (continuous fly-rotation, `tomo_flyscan`) on the [Kinetix sCMOS cameras](detector.md); reuses the graduated Method (shared with [2-BM](../2-bm/techniques.md) and [FXI](../fxi/notes.md#techniques)) |
+| Time-resolved radiography | `radiography` | 2D high-speed / in-situ radiography on the [Phantom Veo](detector.md); shares the Method APS [7-BM](../7-bm/notes.md#techniques) left pending (`TECH-1`) |
+| Energy-dispersive diffraction (EDXD) | `energy_dispersive_diffraction` | spatially-resolved EDXD on the [GeRM germanium strip detector](detector.md); shares the Method 7-BM left pending, HEX the second consumer (`TECH-1`) |
+| Angle-dispersive / powder diffraction (ADXD) | `powder_diffraction` | monochromatic area-detector diffraction on the [PerkinElmer flat panel](detector.md); shares the Method Diamond [i11](../i11/notes.md#techniques) left pending, HEX the second consumer (`TECH-1`) |
+
+All four techniques need the [incident-beam chain](source.md) (the superconducting wiggler, the low-energy filters, and the monochromator for the monochromatic modes), the [sample stack](sample.md) (the 500 kg sample tower, the tomographic rotation and translations), and the [endstation detectors](detector.md). The white beam serves high-speed imaging and EDXD; the monochromatic beam serves tomography at a chosen energy and angle-dispersive diffraction.
+
+### The imaging and diffraction is reinforcement, not novelty
+
+Tomography, radiography, and high-energy diffraction overlap the fleet. Tomography is the operational pilot's defining technique ([2-BM](../2-bm/techniques.md)) and is graduated in the catalog; the [FXI](../fxi/notes.md#techniques) full-field microscope is a second tomography sibling. Energy-dispersive diffraction is the pending APS [7-BM](../7-bm/notes.md#techniques) white-beam Method, and angle-dispersive / powder diffraction is the pending Diamond [i11](../i11/notes.md#techniques) Method. HEX reuses the same `Camera` / `Scintillator` / `RotaryStage` / `LinearStage` / `EnergyDispersiveSpectrometer` vocabulary, coins no new Family, and adds a second consumer to each pending diffraction Method.
+
+So the technique side of HEX earns no new abstraction. It reinforces, at a high-energy beamline, the case that energy-dispersive and powder diffraction belong in the catalog (`TECH-1`), the same earn-the-abstraction discipline 7-BM and i11 already follow. The device Roles exist (the cameras and the flat panel present Detector, the GeRM strip detector presents Sensor), so what stays pending is the science Capability, not a device shape. Because those Capabilities are not yet in the catalog, the matching Site Practices (`HEX_radiography_practice`, `HEX_energy_dispersive_diffraction_practice`, `HEX_powder_diffraction_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does. `HEX_tomography_practice` names the graduated `tomography` Method and renders linked.
+
+### Multi-technique in one experiment, the distinct contribution
+
+The structurally distinct thing about HEX is not any one technique; it is that imaging / tomography, EDXD, and ADXD are all available in the single F-hutch endstation during the same experiment, with detectors and optics moved into place remotely per technique. A high-energy beamline lets a user follow a working battery or a loaded engineering component and switch, within one mounting, between a tomographic view of the microstructure, an energy-dispersive map of internal strain and phase, and an angle-dispersive powder pattern.
+
+CORA models this as **multiple Methods over one endstation**, not a new Capability. The switch itself is a positioning action: a [detector / optics stage](detector.md) moves the chosen detector into the beam. That positioning binds the catalog `LinearStage` and is conducted over the `ControlPort` (see [Controls](controls.md)); it is a Practice-level sequence, not a new technique. The one-technique-per-acquisition assumption is what this stresses, and the resolution is that a Run selects its technique by positioning, then acquires (`TECH-1`).
+
+| Technique in the experiment | Detector | Family |
+| --- | --- | --- |
+| imaging / tomography | [Kinetix sCMOS](detector.md) + scintillator-lens | `Camera` + `Scintillator` |
+| time-resolved radiography | [Phantom Veo](detector.md) | `Camera` |
+| energy-dispersive diffraction (EDXD) | [GeRM strip detector](detector.md) | `EnergyDispersiveSpectrometer` |
+| angle-dispersive diffraction (ADXD) | [PerkinElmer flat panel](detector.md) | `Camera` |
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet. For tomography that is the fly-rotation step model, the dark / flat sequence (`tomo_dark_flat`), and the vertical stitch (`tomo_y_scan_loop`); the reconstruction (flat-field correction, ring / stripe removal) is `ComputePort` work, not a beamline Method. For diffraction it is the EDXD gauge-volume definition and the angle-dispersive integration that turns 2D frames into one-dimensional patterns. These join as the deployment approaches the point where CORA drives HEX.
+
+Whether any of these techniques enters CORA's catalog is an owner-scope decision on [Model](#model): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. HEX adds a second consumer to the pending `energy_dispersive_diffraction`, `radiography`, and `powder_diffraction` Methods, which strengthens the case for cataloging them but leaves that an owner decision (`TECH-1`). See [Open questions](#open-questions) for the world-facts to confirm first, including whether pair-distribution-function (PDF) or three-dimensional X-ray diffraction (3DXRD) are offered, which public sources do not list for HEX (`TECH-1`).
+
+## Governance
+
+*Who will act at HEX, and the trust shape that will gate it. First cut.*
+
+Governance at HEX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+HEX is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
+
+### A distinct allocation policy
+
+HEX has one governance fact the other NSLS-II beamlines do not: a share of its beamtime is reserved for proposals aligned with New York clean-energy and energy-storage goals. Public sources describe a portion of beamtime set aside for such proposals, evaluated by a dedicated proposal-evaluation committee on weighted criteria (technical merit, New York commercial relevance, economic development, and personnel), with the remainder allocated through the standard NSLS-II proposal review and all proposals administered through the facility proposal system. This is a real, distinct trust-shape input: an allocation Policy that gates which experiments run, layered on top of the facility-wide safety and access tiers.
+
+CORA records this as a Policy-level fact, not a new bounded context or descriptor. The exact reservation fraction and the committee's scoring split are carried as a world-fact (`GOV-1`) and are modelled when CORA drives the beamline, not instantiated now. The allocation Policy binds to the NSLS-II operator and review roles carried pending at the Site.
+
+### The safety boundary
+
+The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+HEX adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
+
+| Hazard class | Where it lands | Tracking |
+| --- | --- | --- |
+| High-energy hard X-ray beam (white to 250 keV, monochromatic to 200 keV) | the [optics](index.md) and [endstation](index.md) enclosures (`hex-foe`, `hex-endstation`) | (`PSS-1`, `SCW-1`) |
+| The superconducting wiggler source | the [Source](source.md) walk (cryogen-free, no liquid-helium hazard) | (`SCW-1`) |
+| Heavy-sample handling (up to 500 kg) | the [Sample](sample.md) tower | (`STAGE-1`) |
+| User-brought in-situ / operando environments | the [Sample](sample.md) endstation | (`INSITU-1`) |
+
+The high-energy beam is the interlocked hazard, and at these photon energies the shielding burden is heavier than the fleet's lower-energy beamlines; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The superconducting wiggler is cryogen-free, so no liquid-helium supply hazard is carried (`SCW-1`). The heavy-sample handling and the user-brought in-situ environments are operational hazards carried with the equipment that brings them (`STAGE-1`, `INSITU-1`); none is invented, each is recorded against its question.
+
+### When the shape lands
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives HEX, following the [2-BM governance](../2-bm/governance.md) shape. Because HEX shares the NSLS-II EPICS and ophyd floor with its siblings, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Conduit binds the command surfaces; the Policies bind to the NSLS-II operator roles carried pending at the Site, with the NYSERDA-aligned allocation Policy layered on top (`GOV-1`).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's HEX content lives, how it models the multi-technique endstation and the heavy sample tower, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at HEX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes HEX new
+
+The honest answer is: not much on any single technique, and three real things on structure. HEX measures engineering-materials and energy-storage samples by high-energy imaging / tomography, energy-dispersive diffraction (EDXD), and angle-dispersive / powder diffraction (ADXD). The imaging overlaps the fleet heavily (the 2-BM pilot, the NSLS-II FXI), and the diffraction reuses the pending energy-dispersive (7-BM) and powder (i11) Methods. That side reuses the existing `Camera` / `Scintillator` / `RotaryStage` / `LinearStage` / `EnergyDispersiveSpectrometer` / `InsertionDevice` / `Monochromator` / `Filter` vocabulary and contributes reinforcement, not novelty.
+
+HEX's three genuinely distinct contributions are:
+
+- **Multi-technique in one experiment.** All three techniques run in the single F-hutch endstation during one experiment, with detectors and optics moved into the beam remotely. CORA models this as multiple Methods over one endstation, the technique switch a positioning leg over the `ControlPort`, not a new Capability (`TECH-1`).
+- **Very large and heavy engineering samples.** The 500 kg removable sample tower is a heavy reconfigurable fixture, not a precision goniometer. It reuses `Table` + `RotaryStage` + `LinearStage` with capacity and the configuration set as settings (`STAGE-1`).
+- **A high-energy hard X-ray source.** The superconducting wiggler (4.3 T, 70 mm period) reaching 200 keV monochromatic is a first for the fleet. It binds the existing `InsertionDevice` Family, with the field and energy reach as source specs (`SCW-1`).
+
+### No new families
+
+HEX coins no new Family and changes nothing in the catalog.
+
+- **The superconducting wiggler binds `InsertionDevice`** (the undulator precedent at the NSLS-II siblings). The beam mode (white 30 to 250 keV versus monochromatic 30 to 200 keV) is selected by inserting or retracting the monochromator first crystal, so it is a setting on the optic, not a second source (`MONO-2`).
+- **The optics reuse:** the low-energy filters bind `Filter`; the bent-Laue monochromator binds `Monochromator` (a Bragg optic, not the soft X-ray `GratingMonochromator`); the incident energy is a `PseudoAxis` over it; the front-end slits bind `Slit`.
+- **The sample side reuses:** the tomographic rotation binds `RotaryStage`; the sample translations bind `LinearStage`; the 500 kg removable tower binds `Table`.
+- **The detection side reuses:** the Kinetix sCMOS and Phantom Veo cameras and the PerkinElmer flat panel bind `Camera`; the imaging scintillator-lens table binds `Scintillator`; the detector / optics positioning binds `LinearStage`; the GeRM germanium strip detector binds the existing `EnergyDispersiveSpectrometer` Family (below).
+
+### The GeRM strip detector reuses an earned family
+
+The one place HEX looks like it might force a new abstraction is its energy-dispersive detector, the GeRM germanium strip detector that produces a per-channel energy spectrum rather than a 2D frame. That shape is already in the catalog: the `EnergyDispersiveSpectrometer` Family was earned by the APS 2-ID fluorescence detector and the 7-BM germanium energy-dispersive-diffraction detector, and its definition presents the `Sensor` Role (a scalar or short-vector Reading per point) and explicitly spans the silicon-drift and germanium variants. HEX's GeRM detector is the **third consumer** of that Family, with channel count and energy resolution per-Asset settings. So EDXD on HEX is a reuse, not a graduation, and no catalog or loose-family change is forced (`DET-2`).
+
+### How the multi-technique switch is modelled (no new capability)
+
+The F-hutch offers imaging / tomography, EDXD, and ADXD in one experiment. CORA models the switch between them as a **positioning action over existing devices**, not a new Capability or device:
+
+- each technique has its detector already on the [detection](detector.md) side (the Kinetix cameras, the PerkinElmer flat panel, the GeRM strip detector);
+- a `LinearStage` (`DetectorStage`) moves the chosen detector or optic into the beam;
+- CORA conducts that positioning over the `ControlPort`, then runs the technique's Method.
+
+So the "multi-technique endstation" is a Practice-level sequence, not a fused mega-instrument. The stress it puts on the model, that a single endstation hosts several one-technique acquisitions selected by positioning, is resolved by treating technique selection as a conducted positioning leg ahead of acquisition (`TECH-1`). No new family is coined for the switch.
+
+### Deliberately not here yet
+
+- **The B / C / D / E hutch contents (`ENC-1`, `LAYOUT-1`).** HEX is designed for six enclosures (A = FOE, B, C, D, E, F). All six are declared in the descriptor, forward-looking, but only the operational FOE (`hex-foe`) and F-hutch (`hex-endstation`) carry devices; B (not erected) and C / D / E (future-upgrade shells) are declared as device-free enclosures and carry no Assets in this cut. The descriptor validates that every device's enclosure ref is declared but allows an unreferenced enclosure, so the shells are honest forward-looking placeholders, not invented contents. The satellite-building identity and the per-hutch positions are carried as world-facts (`SAT-1`, `LAYOUT-1`).
+- **The monochromatic focusing optic (`FOCUS-1`).** The beamline page lists focusing for the monochromatic beam as "being commissioned." It is not yet modelled as a device; what optic it is and its target spot are carried as a world-fact.
+- **In-situ sample environments (`INSITU-1`).** HEX's science is operando battery and engineering-materials work, but no specific rig (load frame, furnace, cryostat, battery cycler) is source-confirmed as installed; the endstation is "capable of housing" user-brought environments. Per earn-the-abstraction, no in-situ rig is modelled as an Asset in this cut. If a specific rig is confirmed installed and a second fleet beamline brings one, that is the trigger to consider a sample-environment Family.
+- **The heavy-sample stage as a distinct family (`STAGE-1`).** The 500 kg removable tower stresses the assumption that a sample-orientation Asset is small and goniometer-like. CORA holds the line: capacity and the configuration set (configs A to D) are settings on a reused `Table` + `RotaryStage` + `LinearStage`, not a new `HeavyStage` Family. A second fleet beamline with a heavy removable tower would be the rule-of-three trigger.
+- **The diffraction Methods.** Whether energy-dispersive diffraction, radiography, and powder diffraction enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. EDXD and radiography are shared with 7-BM and powder diffraction with i11 (`TECH-1`).
+- **Pair-distribution-function and 3DXRD.** Public sources do not list PDF (that is NSLS-II 28-ID / [XPD](../xpd/index.md)) or three-dimensional X-ray diffraction for HEX, so neither is modelled or assumed (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_hex_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the HEX team to confirm before the model can be trusted.*
+
+HEX was reverse-engineered from public sources (the BNL beamline page, the [beamline 27-ID wiki](https://wiki-nsls2.bnl.gov/beamline27ID), and the beamline's bluesky profile collection [NSLS2/hex-profile-collection](https://github.com/NSLS2/hex-profile-collection) and [NSLS2/hextools](https://github.com/NSLS2/hextools)), so the control handles on the [device pages](index.md) are read from public config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the six designed enclosures A (FOE), B, C, D, E, F, with only A and F presently relevant to operations (B not erected; C / D / E future-upgrade shells)? | All six declared; `hex-foe` and `hex-endstation` carry devices, B to E are device-free forward-looking shells. | The Enclosure grouping and the future-hutch contents. |
+| SAT-1 | Nice-to-have | Is the satellite building housing the F-hutch the same as Bldg. 742 or a separate numbered structure adjacent to it? | The F-hutch is a distinct enclosure adjacent to Bldg. 742, bound to the NSLS-II Site. | The endstation Enclosure detail. |
+| LAYOUT-1 | Nice-to-have | The source-to-F-hutch distance (about 100 m) and whether an exact per-hutch z-position table exists. | About 100 m source to endstation; no per-hutch z table carried. | The beam-path geometry. |
+| BRANCH-1 | Nice-to-have | Do the inboard and outboard front-end branches carry any installed optics, or are they bare provisions for the future hutches? | Provisions only; only the center branch carries devices. | The front-end slit modelling. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state HEX reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| SCW-1 | Nice-to-have | The superconducting wiggler pole count and critical photon energy (only the 4.3 T field, 70 mm period, 1.2 m length, cell-27 straight are published). | An `InsertionDevice` Asset; field, period, and length carried as specs; pole count and critical energy pending. | The source Asset detail. |
+| MONO-1 | Blocks-go-live | The monochromator crystal material and geometry (is it Si(111) bent Laue?), the crystal count, and the d-spacing. | A single bent-Laue first crystal on a vertical translation, binding `Monochromator`; the incident energy a `PseudoAxis` over it. | The monochromator and incident-energy Assets. |
+| MONO-2 | Blocks-build | The upper monochromatic energy: 150 keV (the wiki) or 200 keV (peer-reviewed, "first NSLS-II beamline to reach 200 keV mono")? | 30 to 200 keV monochromatic, 30 to 250 keV white. | The energy-axis range bound. |
+| FILT-1 | Nice-to-have | The FOE low-energy filter materials and thicknesses per branch (center SiC 3 / 6 / 9 / 12 mm; outboard / inboard Cu plus SiC) and the 35 mm pitch. | Beam-hardening filters bound to `Filter`; materials and thicknesses as listed on the commissioning wiki. | The filter Asset detail. |
+| FOCUS-1 | Nice-to-have | What focusing optic is being commissioned for the monochromatic beam, and the target focused spot. | Focusing not yet a device; carried deferred. | The focusing-optic Asset. |
+
+### Sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The modular sample-tower configurations (A to D), the 500 kg capacity, and which axes are motorized (the tomographic rotation and the translations). | One reconfigurable tower (`Table`, 500 kg, configs A to D) plus a `RotaryStage` rotation and `LinearStage` translations; capacity and config set as settings. | The sample-stage modelling. |
+| INSITU-1 | Blocks-go-live | Which in-situ rigs are actually installed or available at the endstation (load frames, furnaces, cryostats, battery cyclers)? | None installed; the endstation is "capable of housing" user-brought environments, so no in-situ rig is modelled. | The sample-environment modelling; the CORA family decision is on [Model](#deliberately-not-here-yet). |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The PerkinElmer area-detector model (XRD1621?), its pixel count, and that it is the angle-dispersive / powder-diffraction (ADXD) detector. | A PerkinElmer XRD1621 flat panel binding `Camera`, inferred to be the ADXD detector. | The area-detector modelling. |
+| DET-2 | Blocks-go-live | The GeRM germanium strip detector channel count, energy resolution, and the EDXD gauge-volume dimensions. | A GeRM strip detector binding the existing `EnergyDispersiveSpectrometer` Family; specs pending. | The energy-dispersive-detector modelling. |
+| DET-3 | Nice-to-have | Which Kinetix camera is the tomography default, and the scintillator / lens magnification options behind the "2 & 4 mm", "20 & 40 mm", and "Dual cam" imaging-table positions. | `kinetix1` is the default; the scintillator-lens table binds `Scintillator`; the Phantom Veo is the high-speed camera. | The imaging-camera and scintillator modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and what are the FOE-optics PVs (absent from it)? | The endstation detector handles are from the profile collection and carried confirm; the FOE-optics PVs are pending. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the FOE optics) and the cooling supply. | Photon beam, cooling water, and vacuum on the FOE optics; the cryogen-free wiggler draws no liquid helium. | The Supply observations. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level), and the NYSERDA-aligned beamtime-reservation fraction and the proposal-evaluation committee's scoring split. | Carried pending on the NSLS-II Site; the NYSERDA allocation Policy layered on top, fraction and scoring pending. | The governance principals and allocation Policy. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Is the operational technique set exactly imaging / tomography, radiography, EDXD, and powder / ADXD, with all three diffraction-and-imaging modes available in the one endstation, and are PDF and 3DXRD not offered? | Those techniques only; multi-technique in one endstation via detector / optics positioning; no PDF, no 3DXRD. | The technique Capabilities and the multi-technique modelling. |
diff --git a/docs/deployments/hex/questions.md b/docs/deployments/hex/questions.md
deleted file mode 100644
index 08f7e0ce1e7..00000000000
--- a/docs/deployments/hex/questions.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Open questions
-
-*What CORA needs the HEX team to confirm before the model can be trusted.*
-
-HEX was reverse-engineered from public sources (the BNL beamline page, the [beamline 27-ID wiki](https://wiki-nsls2.bnl.gov/beamline27ID), and the beamline's bluesky profile collection [NSLS2/hex-profile-collection](https://github.com/NSLS2/hex-profile-collection) and [NSLS2/hextools](https://github.com/NSLS2/hextools)), so the control handles on the [device pages](index.md) are read from public config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the six designed enclosures A (FOE), B, C, D, E, F, with only A and F presently relevant to operations (B not erected; C / D / E future-upgrade shells)? | All six declared; `hex-foe` and `hex-endstation` carry devices, B to E are device-free forward-looking shells. | The Enclosure grouping and the future-hutch contents. |
-| SAT-1 | Nice-to-have | Is the satellite building housing the F-hutch the same as Bldg. 742 or a separate numbered structure adjacent to it? | The F-hutch is a distinct enclosure adjacent to Bldg. 742, bound to the NSLS-II Site. | The endstation Enclosure detail. |
-| LAYOUT-1 | Nice-to-have | The source-to-F-hutch distance (about 100 m) and whether an exact per-hutch z-position table exists. | About 100 m source to endstation; no per-hutch z table carried. | The beam-path geometry. |
-| BRANCH-1 | Nice-to-have | Do the inboard and outboard front-end branches carry any installed optics, or are they bare provisions for the future hutches? | Provisions only; only the center branch carries devices. | The front-end slit modelling. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state HEX reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| SCW-1 | Nice-to-have | The superconducting wiggler pole count and critical photon energy (only the 4.3 T field, 70 mm period, 1.2 m length, cell-27 straight are published). | An `InsertionDevice` Asset; field, period, and length carried as specs; pole count and critical energy pending. | The source Asset detail. |
-| MONO-1 | Blocks-go-live | The monochromator crystal material and geometry (is it Si(111) bent Laue?), the crystal count, and the d-spacing. | A single bent-Laue first crystal on a vertical translation, binding `Monochromator`; the incident energy a `PseudoAxis` over it. | The monochromator and incident-energy Assets. |
-| MONO-2 | Blocks-build | The upper monochromatic energy: 150 keV (the wiki) or 200 keV (peer-reviewed, "first NSLS-II beamline to reach 200 keV mono")? | 30 to 200 keV monochromatic, 30 to 250 keV white. | The energy-axis range bound. |
-| FILT-1 | Nice-to-have | The FOE low-energy filter materials and thicknesses per branch (center SiC 3 / 6 / 9 / 12 mm; outboard / inboard Cu plus SiC) and the 35 mm pitch. | Beam-hardening filters bound to `Filter`; materials and thicknesses as listed on the commissioning wiki. | The filter Asset detail. |
-| FOCUS-1 | Nice-to-have | What focusing optic is being commissioned for the monochromatic beam, and the target focused spot. | Focusing not yet a device; carried deferred. | The focusing-optic Asset. |
-
-## Sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The modular sample-tower configurations (A to D), the 500 kg capacity, and which axes are motorized (the tomographic rotation and the translations). | One reconfigurable tower (`Table`, 500 kg, configs A to D) plus a `RotaryStage` rotation and `LinearStage` translations; capacity and config set as settings. | The sample-stage modelling. |
-| INSITU-1 | Blocks-go-live | Which in-situ rigs are actually installed or available at the endstation (load frames, furnaces, cryostats, battery cyclers)? | None installed; the endstation is "capable of housing" user-brought environments, so no in-situ rig is modelled. | The sample-environment modelling; the CORA family decision is on [Model](model.md#deliberately-not-here-yet). |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The PerkinElmer area-detector model (XRD1621?), its pixel count, and that it is the angle-dispersive / powder-diffraction (ADXD) detector. | A PerkinElmer XRD1621 flat panel binding `Camera`, inferred to be the ADXD detector. | The area-detector modelling. |
-| DET-2 | Blocks-go-live | The GeRM germanium strip detector channel count, energy resolution, and the EDXD gauge-volume dimensions. | A GeRM strip detector binding the existing `EnergyDispersiveSpectrometer` Family; specs pending. | The energy-dispersive-detector modelling. |
-| DET-3 | Nice-to-have | Which Kinetix camera is the tomography default, and the scintillator / lens magnification options behind the "2 & 4 mm", "20 & 40 mm", and "Dual cam" imaging-table positions. | `kinetix1` is the default; the scintillator-lens table binds `Scintillator`; the Phantom Veo is the high-speed camera. | The imaging-camera and scintillator modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and what are the FOE-optics PVs (absent from it)? | The endstation detector handles are from the profile collection and carried confirm; the FOE-optics PVs are pending. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the FOE optics) and the cooling supply. | Photon beam, cooling water, and vacuum on the FOE optics; the cryogen-free wiggler draws no liquid helium. | The Supply observations. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level), and the NYSERDA-aligned beamtime-reservation fraction and the proposal-evaluation committee's scoring split. | Carried pending on the NSLS-II Site; the NYSERDA allocation Policy layered on top, fraction and scoring pending. | The governance principals and allocation Policy. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Is the operational technique set exactly imaging / tomography, radiography, EDXD, and powder / ADXD, with all three diffraction-and-imaging modes available in the one endstation, and are PDF and 3DXRD not offered? | Those techniques only; multi-technique in one endstation via detector / optics positioning; no PDF, no 3DXRD. | The technique Capabilities and the multi-technique modelling. |
diff --git a/docs/deployments/hex/techniques.md b/docs/deployments/hex/techniques.md
deleted file mode 100644
index 57bf7125366..00000000000
--- a/docs/deployments/hex/techniques.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Techniques
-
-*What the modelled part of HEX is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. HEX measures engineering-materials and energy-storage samples three ways, all in the single operational endstation and all at high X-ray energy: X-ray imaging and tomography, energy-dispersive X-ray diffraction (EDXD), and angle-dispersive / powder diffraction (ADXD). One of those, tomography, is a Method CORA already holds; the rest render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings them into the catalog.
-
-HEX is mostly reinforcement of imaging and high-energy diffraction the fleet already speaks. Read this page for the one thing that is structurally distinct: all three techniques run in the same experiment, with detectors and optics moved into the beam remotely.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray tomography and CT | `tomography` | high-energy white-beam and monochromatic tomography (continuous fly-rotation, `tomo_flyscan`) on the [Kinetix sCMOS cameras](detector.md); reuses the graduated Method (shared with [2-BM](../2-bm/techniques.md) and [FXI](../fxi/techniques.md)) |
-| Time-resolved radiography | `radiography` | 2D high-speed / in-situ radiography on the [Phantom Veo](detector.md); shares the Method APS [7-BM](../7-bm/techniques.md) left pending (`TECH-1`) |
-| Energy-dispersive diffraction (EDXD) | `energy_dispersive_diffraction` | spatially-resolved EDXD on the [GeRM germanium strip detector](detector.md); shares the Method 7-BM left pending, HEX the second consumer (`TECH-1`) |
-| Angle-dispersive / powder diffraction (ADXD) | `powder_diffraction` | monochromatic area-detector diffraction on the [PerkinElmer flat panel](detector.md); shares the Method Diamond [i11](../i11/techniques.md) left pending, HEX the second consumer (`TECH-1`) |
-
-All four techniques need the [incident-beam chain](source.md) (the superconducting wiggler, the low-energy filters, and the monochromator for the monochromatic modes), the [sample stack](sample.md) (the 500 kg sample tower, the tomographic rotation and translations), and the [endstation detectors](detector.md). The white beam serves high-speed imaging and EDXD; the monochromatic beam serves tomography at a chosen energy and angle-dispersive diffraction.
-
-## The imaging and diffraction is reinforcement, not novelty
-
-Tomography, radiography, and high-energy diffraction overlap the fleet. Tomography is the operational pilot's defining technique ([2-BM](../2-bm/techniques.md)) and is graduated in the catalog; the [FXI](../fxi/techniques.md) full-field microscope is a second tomography sibling. Energy-dispersive diffraction is the pending APS [7-BM](../7-bm/techniques.md) white-beam Method, and angle-dispersive / powder diffraction is the pending Diamond [i11](../i11/techniques.md) Method. HEX reuses the same `Camera` / `Scintillator` / `RotaryStage` / `LinearStage` / `EnergyDispersiveSpectrometer` vocabulary, coins no new Family, and adds a second consumer to each pending diffraction Method.
-
-So the technique side of HEX earns no new abstraction. It reinforces, at a high-energy beamline, the case that energy-dispersive and powder diffraction belong in the catalog (`TECH-1`), the same earn-the-abstraction discipline 7-BM and i11 already follow. The device Roles exist (the cameras and the flat panel present Detector, the GeRM strip detector presents Sensor), so what stays pending is the science Capability, not a device shape. Because those Capabilities are not yet in the catalog, the matching Site Practices (`HEX_radiography_practice`, `HEX_energy_dispersive_diffraction_practice`, `HEX_powder_diffraction_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does. `HEX_tomography_practice` names the graduated `tomography` Method and renders linked.
-
-## Multi-technique in one experiment, the distinct contribution
-
-The structurally distinct thing about HEX is not any one technique; it is that imaging / tomography, EDXD, and ADXD are all available in the single F-hutch endstation during the same experiment, with detectors and optics moved into place remotely per technique. A high-energy beamline lets a user follow a working battery or a loaded engineering component and switch, within one mounting, between a tomographic view of the microstructure, an energy-dispersive map of internal strain and phase, and an angle-dispersive powder pattern.
-
-CORA models this as **multiple Methods over one endstation**, not a new Capability. The switch itself is a positioning action: a [detector / optics stage](detector.md) moves the chosen detector into the beam. That positioning binds the catalog `LinearStage` and is conducted over the `ControlPort` (see [Controls](controls.md)); it is a Practice-level sequence, not a new technique. The one-technique-per-acquisition assumption is what this stresses, and the resolution is that a Run selects its technique by positioning, then acquires (`TECH-1`).
-
-| Technique in the experiment | Detector | Family |
-| --- | --- | --- |
-| imaging / tomography | [Kinetix sCMOS](detector.md) + scintillator-lens | `Camera` + `Scintillator` |
-| time-resolved radiography | [Phantom Veo](detector.md) | `Camera` |
-| energy-dispersive diffraction (EDXD) | [GeRM strip detector](detector.md) | `EnergyDispersiveSpectrometer` |
-| angle-dispersive diffraction (ADXD) | [PerkinElmer flat panel](detector.md) | `Camera` |
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet. For tomography that is the fly-rotation step model, the dark / flat sequence (`tomo_dark_flat`), and the vertical stitch (`tomo_y_scan_loop`); the reconstruction (flat-field correction, ring / stripe removal) is `ComputePort` work, not a beamline Method. For diffraction it is the EDXD gauge-volume definition and the angle-dispersive integration that turns 2D frames into one-dimensional patterns. These join as the deployment approaches the point where CORA drives HEX.
-
-Whether any of these techniques enters CORA's catalog is an owner-scope decision on [Model](model.md): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. HEX adds a second consumer to the pending `energy_dispersive_diffraction`, `radiography`, and `powder_diffraction` Methods, which strengthens the case for cataloging them but leaves that an owner decision (`TECH-1`). See [Open questions](questions.md) for the world-facts to confirm first, including whether pair-distribution-function (PDF) or three-dimensional X-ray diffraction (3DXRD) are offered, which public sources do not list for HEX (`TECH-1`).
diff --git a/docs/deployments/hxn/governance.md b/docs/deployments/hxn/governance.md
deleted file mode 100644
index b5b558efdb5..00000000000
--- a/docs/deployments/hxn/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at HXN and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An HXN beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a run, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody; CORA confirms entitlement against the facility's proposal identity but applies its own per-Actor authority on top.
-
-## Agents and the scanning loop
-
-HXN's scanning workflows (auto-alignment, adaptive mapping) are where an autonomous or adaptive Agent would naturally act: proposing the next scan region or correction inside the conduct loop. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each proposed move would be a [Decision](../../architecture/modules/decision/index.md) (the inference-recorder path for any LLM-backed agent). None is declared for HXN yet.
diff --git a/docs/deployments/hxn/model.md b/docs/deployments/hxn/model.md
deleted file mode 100644
index 4d6904f00f4..00000000000
--- a/docs/deployments/hxn/model.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's HXN content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at HXN |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) (3-ID-A optics, 3-ID-C endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring 32-ID and 7-BM. Left out on purpose:
-
-- **The scanning / ptychography Capabilities.** Coined when a real conduct-path consumes a raster, not at scaffold time (see [Techniques](techniques.md)). HXN is the first scanning-probe deployment, so this is the live earn-the-abstraction question, deferred deliberately.
-- **`MultilayerLaueLens` catalog graduation.** A loose family at its first sighting (OPTIC-3); graduates at a second MLL beamline.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/hxn/notes.md b/docs/deployments/hxn/notes.md
new file mode 100644
index 00000000000..b94f4ebab6e
--- /dev/null
+++ b/docs/deployments/hxn/notes.md
@@ -0,0 +1,101 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at HXN: the Capabilities and portable [Catalog](../../catalog/methods.md) Methods, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here).*
+
+HXN does scanning nano-XRF mapping, ptychography, nano-tomography, and spectro-tomography, all variants of one act: raster the sample through the focus and read the per-point detectors. The big modeling question HXN raises is whether scanning and ptychography are new Capabilities or fit existing ones; this scaffold **defers** coining them, following the Diamond i03/i22 and 32-ID precedent (no new Capability coined for a design-phase reverse-engineered deployment until a real conduct-path consumes it).
+
+| HXN technique | CORA expression | Earn-the-abstraction call |
+| --- | --- | --- |
+| Scanning XRF mapping | Method under `acquisition` (a raster of per-point spectra) | **Defer** coining a `scanning` Capability; trigger = first raster conduct-path, or a 2nd scanning beamline |
+| Ptychography | the same raster with a `Camera` in the detector slot + offline reconstruction | **Defer**; ptychography is not its own Capability. The reconstruction is a `ComputePort` leg, not a beamline Method |
+| Nano-tomography | [`tomography`](../../catalog/methods.md) | reuse; raster x rotation, the same family as 2-BM/FXI tomography |
+| Spectro-tomography | compose `tomography` + energy change | reuse; do not coin `spectro_tomography` |
+| XANES / energy change | [`beamline_energy_change`](../../catalog/methods.md) | reuse; but the HXN energy change co-moves the zone-plate refocus per element (ENERGY-1), a richer move than FXI's mono-only change |
+| Alignment | [`alignment`](../../catalog/methods.md) | reuse (line-center, knife-edge, center-of-mass) |
+
+The central new shape, **scanning-probe acquisition with multi-modal per-point detection**, is the strongest in-kind argument the catalog has seen for a `scanning` Capability (the raster *is* the measurement, not a frame at a fixed pose). It is held open deliberately, not because it is weak, but because the discipline is to coin a Capability when a conduct-path forces it, not at scaffold time. See [Controls](controls.md) for how CORA's conducting engine would run the raster over the ControlPort and the ptychographic reconstruction over the ComputePort.
+
+## Governance
+
+*Who may act at HXN and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An HXN beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a run, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody; CORA confirms entitlement against the facility's proposal identity but applies its own per-Actor authority on top.
+
+### Agents and the scanning loop
+
+HXN's scanning workflows (auto-alignment, adaptive mapping) are where an autonomous or adaptive Agent would naturally act: proposing the next scan region or correction inside the conduct loop. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each proposed move would be a [Decision](../../architecture/modules/decision/index.md) (the inference-recorder path for any LLM-backed agent). None is declared for HXN yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's HXN content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at HXN |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) (3-ID-A optics, 3-ID-C endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring 32-ID and 7-BM. Left out on purpose:
+
+- **The scanning / ptychography Capabilities.** Coined when a real conduct-path consumes a raster, not at scaffold time (see [Techniques](#techniques)). HXN is the first scanning-probe deployment, so this is the live earn-the-abstraction question, deferred deliberately.
+- **`MultilayerLaueLens` catalog graduation.** A loose family at its first sighting (OPTIC-3); graduates at a second MLL beamline.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the HXN team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/hxn-profile-collection`](https://github.com/NSLS2/hxn-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector roster are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build` (changes the model structure), `Blocks-go-live` (needed before CORA controls or observes the hardware), `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | IVU20 undulator period, gap range, and harmonic usage. The device (`SR:C3-ID:G1{IVU20:1}`) is confirmed; parameters are not in source. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs per hutch. Only the photon shutter `XF:03IDB-PPS{PSh}` is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | Is the `XF:03IDB` intermediate zone (secondary-source aperture, slow shutter) a distinct enclosure, or part of the endstation? HXN spans three PV zones (3-ID-A/B/C). | Two enclosures (3-ID-A optics, 3-ID-C experiment); 3-ID-B folded. | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | DCM crystal cut and energy range. | A double-crystal monochromator; cut/range blank. | The Monochromator settings. |
+| OPTIC-1 | Blocks-go-live | Are the zone plate and the multilayer Laue lens both permanently installed and operator-selected, or is one decommissioned? Both appear in source. | Both modelled, switchable. | The focusing-optic roster. |
+| OPTIC-2 | Nice-to-have | Zone-plate parameters (outer-zone width, diameter, material). | A ZonePlate Asset, parameters blank. | The ZonePlate settings. |
+| OPTIC-3 | Nice-to-have | Should `MultilayerLaueLens` become a catalog Family? HXN is its only sighting (a 1D crossed-pair lens, distinct from the circular ZonePlate). | A loose family name that renders as text; not yet graduated. | Catalog Family graduation (Federation-scoped). |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The tomographic rotary (`sth`, on an ANC350) hardware, encoder resolution, and max speed. | A RotaryStage, specs blank. | The SampleRotary settings. |
+| STAGE-2 | Nice-to-have | Does the SmarAct Smarpod 6-DOF pod fit the `Hexapod` Family (single coordinated parallel-kinematics move)? | Modelled as a Hexapod. | The SamplePod Family fit. |
+| DET-1 | Blocks-go-live | The Xspress3 fluorescence detector: vendor (Quantum Detectors?), element count, energy resolution. Source shows 4 channels (C1-C4) plus a second unit. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; specs blank. | The detector Model and element count. |
+| CAM-1 | Blocks-go-live | Which pixel detectors are physically installed and active? Source has Merlin (x2), Eiger 1M, and Dexela; some classes are duplicated (`USE_RASMI`-gated). | Merlin1, Eiger1, Dexela1 modelled as Cameras; dormant duplicates excluded. | The detector roster and the per-scan detector slot. |
+| DIAG-1 | Nice-to-have | The scaler / ion-chamber flux channel map (which channel is I0 for ptycho normalization). | Read-only flux counters, channel map blank. | The FluxCounter bindings. |
+
+### Controls and techniques
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, serials, and IPs. HXN exposes the controller PVs (Power PMAC `Ppmac:1` + `MC:2-8`; Attocube `ANC350:1-8`), which FXI did not, but vendor/firmware detail is still not in source. | Families bound (MotionController), models named where evident (PMAC, Attocube), specifics blank. | The MotionController Models and Drive identities. |
+| ZEBRA-1 | Nice-to-have | Is `nanoZebra` (`Zeb:3`) the live trigger master, and is the PandABox (`67-nano-panda`, currently partly commented) the go-forward box? | One live Zebra; PandA deferred. | The TimingController set. |
+| ENERGY-1 | Nice-to-have | Does an energy change co-move the zone-plate refocus per element edge, and is that table operator-data or a CORA Calibration? | Energy axis drives the monochromator; the optic co-move is noted, not modelled. | The energy-change Method shape. |
diff --git a/docs/deployments/hxn/questions.md b/docs/deployments/hxn/questions.md
deleted file mode 100644
index 6994788661e..00000000000
--- a/docs/deployments/hxn/questions.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Open questions
-
-*What CORA needs the HXN team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/hxn-profile-collection`](https://github.com/NSLS2/hxn-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector roster are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build` (changes the model structure), `Blocks-go-live` (needed before CORA controls or observes the hardware), `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | IVU20 undulator period, gap range, and harmonic usage. The device (`SR:C3-ID:G1{IVU20:1}`) is confirmed; parameters are not in source. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs per hutch. Only the photon shutter `XF:03IDB-PPS{PSh}` is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | Is the `XF:03IDB` intermediate zone (secondary-source aperture, slow shutter) a distinct enclosure, or part of the endstation? HXN spans three PV zones (3-ID-A/B/C). | Two enclosures (3-ID-A optics, 3-ID-C experiment); 3-ID-B folded. | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | DCM crystal cut and energy range. | A double-crystal monochromator; cut/range blank. | The Monochromator settings. |
-| OPTIC-1 | Blocks-go-live | Are the zone plate and the multilayer Laue lens both permanently installed and operator-selected, or is one decommissioned? Both appear in source. | Both modelled, switchable. | The focusing-optic roster. |
-| OPTIC-2 | Nice-to-have | Zone-plate parameters (outer-zone width, diameter, material). | A ZonePlate Asset, parameters blank. | The ZonePlate settings. |
-| OPTIC-3 | Nice-to-have | Should `MultilayerLaueLens` become a catalog Family? HXN is its only sighting (a 1D crossed-pair lens, distinct from the circular ZonePlate). | A loose family name that renders as text; not yet graduated. | Catalog Family graduation (Federation-scoped). |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The tomographic rotary (`sth`, on an ANC350) hardware, encoder resolution, and max speed. | A RotaryStage, specs blank. | The SampleRotary settings. |
-| STAGE-2 | Nice-to-have | Does the SmarAct Smarpod 6-DOF pod fit the `Hexapod` Family (single coordinated parallel-kinematics move)? | Modelled as a Hexapod. | The SamplePod Family fit. |
-| DET-1 | Blocks-go-live | The Xspress3 fluorescence detector: vendor (Quantum Detectors?), element count, energy resolution. Source shows 4 channels (C1-C4) plus a second unit. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; specs blank. | The detector Model and element count. |
-| CAM-1 | Blocks-go-live | Which pixel detectors are physically installed and active? Source has Merlin (x2), Eiger 1M, and Dexela; some classes are duplicated (`USE_RASMI`-gated). | Merlin1, Eiger1, Dexela1 modelled as Cameras; dormant duplicates excluded. | The detector roster and the per-scan detector slot. |
-| DIAG-1 | Nice-to-have | The scaler / ion-chamber flux channel map (which channel is I0 for ptycho normalization). | Read-only flux counters, channel map blank. | The FluxCounter bindings. |
-
-## Controls and techniques
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, serials, and IPs. HXN exposes the controller PVs (Power PMAC `Ppmac:1` + `MC:2-8`; Attocube `ANC350:1-8`), which FXI did not, but vendor/firmware detail is still not in source. | Families bound (MotionController), models named where evident (PMAC, Attocube), specifics blank. | The MotionController Models and Drive identities. |
-| ZEBRA-1 | Nice-to-have | Is `nanoZebra` (`Zeb:3`) the live trigger master, and is the PandABox (`67-nano-panda`, currently partly commented) the go-forward box? | One live Zebra; PandA deferred. | The TimingController set. |
-| ENERGY-1 | Nice-to-have | Does an energy change co-move the zone-plate refocus per element edge, and is that table operator-data or a CORA Calibration? | Energy axis drives the monochromator; the optic co-move is noted, not modelled. | The energy-change Method shape. |
diff --git a/docs/deployments/hxn/techniques.md b/docs/deployments/hxn/techniques.md
deleted file mode 100644
index 68e3ef75c7e..00000000000
--- a/docs/deployments/hxn/techniques.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Techniques
-
-*What CORA would run at HXN: the Capabilities and portable [Catalog](../../catalog/methods.md) Methods, bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here).*
-
-HXN does scanning nano-XRF mapping, ptychography, nano-tomography, and spectro-tomography, all variants of one act: raster the sample through the focus and read the per-point detectors. The big modeling question HXN raises is whether scanning and ptychography are new Capabilities or fit existing ones; this scaffold **defers** coining them, following the Diamond i03/i22 and 32-ID precedent (no new Capability coined for a design-phase reverse-engineered deployment until a real conduct-path consumes it).
-
-| HXN technique | CORA expression | Earn-the-abstraction call |
-| --- | --- | --- |
-| Scanning XRF mapping | Method under `acquisition` (a raster of per-point spectra) | **Defer** coining a `scanning` Capability; trigger = first raster conduct-path, or a 2nd scanning beamline |
-| Ptychography | the same raster with a `Camera` in the detector slot + offline reconstruction | **Defer**; ptychography is not its own Capability. The reconstruction is a `ComputePort` leg, not a beamline Method |
-| Nano-tomography | [`tomography`](../../catalog/methods.md) | reuse; raster x rotation, the same family as 2-BM/FXI tomography |
-| Spectro-tomography | compose `tomography` + energy change | reuse; do not coin `spectro_tomography` |
-| XANES / energy change | [`beamline_energy_change`](../../catalog/methods.md) | reuse; but the HXN energy change co-moves the zone-plate refocus per element (ENERGY-1), a richer move than FXI's mono-only change |
-| Alignment | [`alignment`](../../catalog/methods.md) | reuse (line-center, knife-edge, center-of-mass) |
-
-The central new shape, **scanning-probe acquisition with multi-modal per-point detection**, is the strongest in-kind argument the catalog has seen for a `scanning` Capability (the raster *is* the measurement, not a frame at a fixed pose). It is held open deliberately, not because it is weak, but because the discipline is to coin a Capability when a conduct-path forces it, not at scaffold time. See [Controls](controls.md) for how CORA's conducting engine would run the raster over the ControlPort and the ptychographic reconstruction over the ComputePort.
diff --git a/docs/deployments/i-tomcat/governance.md b/docs/deployments/i-tomcat/governance.md
deleted file mode 100644
index 3e9e3995c93..00000000000
--- a/docs/deployments/i-tomcat/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who would act at I-TOMCAT, and the trust shape that would gate it. Modelling exercise.*
-
-Governance at I-TOMCAT follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [PSI Site](../psi/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-I-TOMCAT is a modelling exercise, so this shape is not yet instantiated. The PSI operator and safety-review structure is not public and is carried pending on the [PSI site page](../psi/index.md#safety-and-governance); CORA does not invent a PSI operator pool or review chain ahead of confirmation.
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the PSI Site, not on the beamline, and the beamline links up to them rather than restating them. The PSI personnel-safety-system form and interlock names are an open question (PSS-1 on [Open questions](questions.md)).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, would land if the deployment firms toward a real connection, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i-tomcat/model.md b/docs/deployments/i-tomcat/model.md
deleted file mode 100644
index 12eb232edb2..00000000000
--- a/docs/deployments/i-tomcat/model.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I-TOMCAT content lives, the SLS 2.0 control-stack seam this exercise draws, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I-TOMCAT |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The seam: what CORA would replace vs drive through
-
-I-TOMCAT is the fleet's view of an SLS 2.0 beamline, so the control-stack boundary matters more than usual. SLS is an EPICS facility with the BEC (Beamline and Experiment Control) scan layer over ophyd introduced for SLS 2.0.
-
-| Layer | SLS tool | CORA seam |
-| --- | --- | --- |
-| Control (floor) | EPICS IOCs | **drive through** (never replaced; the floor CORA actuates and observes) |
-| Scan / orchestration (edge) | BEC over ophyd | **replace** (CORA's edge replaces BEC's scan/experiment steering; the BEC-shares-ophyd nuance keeps a drive-through reading open, SEAM-1) |
-| Detector / capture | the camera streaming + HDF5 writer chain | **drive through / observe** (specialized capture CORA observes) |
-| Data-of-record | SciCat + the Ra/SLURM Fiji reconstruction pipeline | **replace / invert source-of-truth** (CORA owns its own Dataset; SciCat is a fact a future integration reads, not CORA's record) |
-
-This is the standard CORA lens (EPICS is the floor, the facility's scan/data software is named only to draw the boundary). The single most consequential call, BEC replace vs drive-through, is carried as SEAM-1 on [Open questions](questions.md) because BEC adopts the same ophyd device model CORA's edge would.
-
-## What is deliberately not here yet
-
-- **Integration scenarios.** No `test_i_tomcat_*.py` registers I-TOMCAT Assets into the event store. Scenario code is where Assets become real, and hard-registering a modelling-exercise beamline with unconfirmed facts would commit speculative structure. It lands if the deployment firms toward a real connection.
-- **Vendor Models.** No catalog Model is bound. The "(target)" models in the descriptor are [open questions](questions.md), not bindings, because they are read from public pages and not staff-confirmed.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA has not connected to would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i-tomcat/notes.md b/docs/deployments/i-tomcat/notes.md
new file mode 100644
index 00000000000..2e7e54daa3d
--- /dev/null
+++ b/docs/deployments/i-tomcat/notes.md
@@ -0,0 +1,114 @@
+# Notes
+
+## Techniques
+
+*What I-TOMCAT is designed to do, as intent. Modelling exercise.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../psi/index.md#the-techniques-adapted-here) is how a facility adapts it. The PSI Practices that bind these are carried pending on the [PSI site page](../psi/index.md#the-techniques-adapted-here) until PSI staff confirm them. The function view survives the eventual equipment choices, which is why it can be written from the public pages before the controls are wired.
+
+I-TOMCAT is a hard X-ray tomographic-microscopy beamline. Its techniques are the tomography-family Methods the catalog already carries, the same ones the APS [2-BM](../2-bm/index.md) pilot earned:
+
+| Technique | Catalog Method | What it is for |
+| --- | --- | --- |
+| Standard microtomography | [`tomography`](../../catalog/methods.md) | absorption-contrast 3D imaging on the U15 undulator, monochromatic 8-30 keV |
+| Propagation-based phase contrast | [`tomography`](../../catalog/methods.md) | edge-enhanced imaging of weakly-absorbing samples (a propagation distance, not a separate fixture) |
+| Fast / dynamic 4D tomography | [`streaming_tomography`](../../catalog/methods.md) | continuous high-speed acquisition via the GigaFRoST streaming camera, for in-situ dynamics |
+
+A few points of intent shape the model:
+
+- **The GigaFRoST camera is the dynamic-tomography enabler.** The PSI in-house continuous-streaming camera (up to 1255 fps full-frame, ~8 GB/s, up to ~33,875 Hz on a reduced ROI) is what distinguishes I-TOMCAT's fast and dynamic 4D tomography from a standard CT beamline. It maps to the catalog `streaming_tomography` Method, not a new one.
+- **Phase contrast is a propagation distance, not a separate station.** Propagation-based phase-contrast imaging runs on the same endstation by moving the detector back from the sample; it is an acquisition mode over one set of optics, modelled under `tomography`, mirroring the 2-BM decision.
+- **Grating interferometry is out of scope.** The legacy TOMCAT offered it only occasionally; it is not modelled here and is not one of the SLS Practices until staff confirm it is offered on the rebuilt beamline (TECH-1).
+
+The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join if the deployment firms toward a real connection. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who would act at I-TOMCAT, and the trust shape that would gate it. Modelling exercise.*
+
+Governance at I-TOMCAT follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [PSI Site](../psi/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+I-TOMCAT is a modelling exercise, so this shape is not yet instantiated. The PSI operator and safety-review structure is not public and is carried pending on the [PSI site page](../psi/index.md#safety-and-governance); CORA does not invent a PSI operator pool or review chain ahead of confirmation.
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the PSI Site, not on the beamline, and the beamline links up to them rather than restating them. The PSI personnel-safety-system form and interlock names are an open question (PSS-1 on [Open questions](#open-questions)).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, would land if the deployment firms toward a real connection, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I-TOMCAT content lives, the SLS 2.0 control-stack seam this exercise draws, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I-TOMCAT |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The seam: what CORA would replace vs drive through
+
+I-TOMCAT is the fleet's view of an SLS 2.0 beamline, so the control-stack boundary matters more than usual. SLS is an EPICS facility with the BEC (Beamline and Experiment Control) scan layer over ophyd introduced for SLS 2.0.
+
+| Layer | SLS tool | CORA seam |
+| --- | --- | --- |
+| Control (floor) | EPICS IOCs | **drive through** (never replaced; the floor CORA actuates and observes) |
+| Scan / orchestration (edge) | BEC over ophyd | **replace** (CORA's edge replaces BEC's scan/experiment steering; the BEC-shares-ophyd nuance keeps a drive-through reading open, SEAM-1) |
+| Detector / capture | the camera streaming + HDF5 writer chain | **drive through / observe** (specialized capture CORA observes) |
+| Data-of-record | SciCat + the Ra/SLURM Fiji reconstruction pipeline | **replace / invert source-of-truth** (CORA owns its own Dataset; SciCat is a fact a future integration reads, not CORA's record) |
+
+This is the standard CORA lens (EPICS is the floor, the facility's scan/data software is named only to draw the boundary). The single most consequential call, BEC replace vs drive-through, is carried as SEAM-1 on [Open questions](#open-questions) because BEC adopts the same ophyd device model CORA's edge would.
+
+### What is deliberately not here yet
+
+- **Integration scenarios.** No `test_i_tomcat_*.py` registers I-TOMCAT Assets into the event store. Scenario code is where Assets become real, and hard-registering a modelling-exercise beamline with unconfirmed facts would commit speculative structure. It lands if the deployment firms toward a real connection.
+- **Vendor Models.** No catalog Model is bound. The "(target)" models in the descriptor are [open questions](#open-questions), not bindings, because they are read from public pages and not staff-confirmed.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA has not connected to would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the I-TOMCAT team to confirm before the model can be trusted.*
+
+I-TOMCAT is a modelling exercise modelled from PSI's public pages and the SLS 2.0 design reports, so this page is long by design: almost every value on the [device pages](index.md) is read from a public page, not a staff-confirmed fact, and some are legacy TOMCAT specs whose validity for the rebuilt beamline is itself uncertain. Each row below is a fact the beamline team or a design report owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | What are the EPICS PV prefix scheme and the BEC ophyd device handles for each I-TOMCAT device? | The PV scheme is not public and the BEC plugin is internal; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
+| SEAM-1 | Blocks-build | Does CORA's edge replace BEC's scan/experiment orchestration, or drive through it at the ophyd/`bec_messages` boundary? | CORA's edge replaces BEC's scan steering, conducting over EPICS; the shared ophyd device model keeps a drive-through reading open. | The control-stack seam boundary. |
+| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for the optics and experiment hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
+| ENC-1 | Blocks-go-live | Is `X02SA` genuinely the rebuilt I-TOMCAT, and what is the optics/experiment hutch grouping? | `X02SA` is I-TOMCAT (corroborated by the `/sls/x02sa/` raw-data path); two hutches, optics shared with S-TOMCAT. | The enclosure model and sector binding. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | What are the U15 undulator period and gap range, and when does the HTSU10 source upgrade land? | A U15 undulator now, HTSU10 in 2027; period/gap to be named. | The InsertionDevice settings. |
+| MACHINE-1 | Nice-to-have | What are the SLS 2.0 storage-ring state handles (current, fill) CORA observes? | Observe-only ring state, handles to be named. | The StorageRing observation handles. |
+| MONO-1 | Blocks-go-live | Do the legacy DCMM optics (multilayer stripes, Si(111), energy range) still describe the rebuilt beamline? | The legacy fixed-exit DCMM, 8-50 keV (8-30 recommended), carried until confirmed. | The Monochromator / Window / Filter specs. |
+| OPT-1 | Nice-to-have | What are the focusing / harmonic-rejection mirror coatings and handles? They are not on the public pages. | A focusing mirror exists but is deferred (not invented) until named. | The Mirror model. |
+| OPT-2 | Nice-to-have | What is the beam-defining slit blade-axis map and the handles? | Beam-defining slits ahead of the endstation; axis map to be named. | The Slit model. |
+
+### Endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | Is the rotation stage the Aerotech ABRX150, and are its specs (~1500 deg/s) final? | The "(target)" ABRX150, used as the trigger master clock. | The rotary stage Model binding. |
+| SAMPLE-1 | Blocks-go-live | What are the sample positioning axis set, the slip-ring channel count, and the fast-shutter model? | A centring stage, a continuous-rotation slip ring, and a dose-limiting fast shutter; details to be named. | The sample-stage models. |
+| TRIG-1 | Blocks-go-live | Does the air-bearing rotary TTL feed the camera triggers directly, or is a conditioner needed? | Direct rotary-master triggering; may evolve once camera trigger requirements firm. | The trigger / sync chain. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Which camera models are installed (the pco.edge family, pco.dimax, and the PSI GigaFRoST)? | Three cameras at the stated design-target sensors/speeds; models unbound. | The camera Model bindings. |
+| DET-2 | Blocks-go-live | What is the microscope optics model, and does it compose the cross-facility `Microscope` Assembly the way 2-BM does? | A `Housing` with `Objective` + `Scintillator` constituents, 1x-40x; Assembly composition deferred. | The microscope Model and Assembly composition. |
+
+### Techniques
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Which tomography Practices does the rebuilt beamline offer (e.g. is grating interferometry offered)? | Standard + phase-contrast + dynamic 4D tomography; grating interferometry out of scope. | The SLS Practices that bind the catalog Methods. |
diff --git a/docs/deployments/i-tomcat/questions.md b/docs/deployments/i-tomcat/questions.md
deleted file mode 100644
index 0272630cfaf..00000000000
--- a/docs/deployments/i-tomcat/questions.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Open questions
-
-*What CORA needs the I-TOMCAT team to confirm before the model can be trusted.*
-
-I-TOMCAT is a modelling exercise modelled from PSI's public pages and the SLS 2.0 design reports, so this page is long by design: almost every value on the [device pages](index.md) is read from a public page, not a staff-confirmed fact, and some are legacy TOMCAT specs whose validity for the rebuilt beamline is itself uncertain. Each row below is a fact the beamline team or a design report owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | What are the EPICS PV prefix scheme and the BEC ophyd device handles for each I-TOMCAT device? | The PV scheme is not public and the BEC plugin is internal; CORA leaves each device handle empty. | Wiring each Asset to a real control handle. |
-| SEAM-1 | Blocks-build | Does CORA's edge replace BEC's scan/experiment orchestration, or drive through it at the ophyd/`bec_messages` boundary? | CORA's edge replaces BEC's scan steering, conducting over EPICS; the shared ophyd device model keeps a drive-through reading open. | The control-stack seam boundary. |
-| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for the optics and experiment hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
-| ENC-1 | Blocks-go-live | Is `X02SA` genuinely the rebuilt I-TOMCAT, and what is the optics/experiment hutch grouping? | `X02SA` is I-TOMCAT (corroborated by the `/sls/x02sa/` raw-data path); two hutches, optics shared with S-TOMCAT. | The enclosure model and sector binding. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | What are the U15 undulator period and gap range, and when does the HTSU10 source upgrade land? | A U15 undulator now, HTSU10 in 2027; period/gap to be named. | The InsertionDevice settings. |
-| MACHINE-1 | Nice-to-have | What are the SLS 2.0 storage-ring state handles (current, fill) CORA observes? | Observe-only ring state, handles to be named. | The StorageRing observation handles. |
-| MONO-1 | Blocks-go-live | Do the legacy DCMM optics (multilayer stripes, Si(111), energy range) still describe the rebuilt beamline? | The legacy fixed-exit DCMM, 8-50 keV (8-30 recommended), carried until confirmed. | The Monochromator / Window / Filter specs. |
-| OPT-1 | Nice-to-have | What are the focusing / harmonic-rejection mirror coatings and handles? They are not on the public pages. | A focusing mirror exists but is deferred (not invented) until named. | The Mirror model. |
-| OPT-2 | Nice-to-have | What is the beam-defining slit blade-axis map and the handles? | Beam-defining slits ahead of the endstation; axis map to be named. | The Slit model. |
-
-## Endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | Is the rotation stage the Aerotech ABRX150, and are its specs (~1500 deg/s) final? | The "(target)" ABRX150, used as the trigger master clock. | The rotary stage Model binding. |
-| SAMPLE-1 | Blocks-go-live | What are the sample positioning axis set, the slip-ring channel count, and the fast-shutter model? | A centring stage, a continuous-rotation slip ring, and a dose-limiting fast shutter; details to be named. | The sample-stage models. |
-| TRIG-1 | Blocks-go-live | Does the air-bearing rotary TTL feed the camera triggers directly, or is a conditioner needed? | Direct rotary-master triggering; may evolve once camera trigger requirements firm. | The trigger / sync chain. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Which camera models are installed (the pco.edge family, pco.dimax, and the PSI GigaFRoST)? | Three cameras at the stated design-target sensors/speeds; models unbound. | The camera Model bindings. |
-| DET-2 | Blocks-go-live | What is the microscope optics model, and does it compose the cross-facility `Microscope` Assembly the way 2-BM does? | A `Housing` with `Objective` + `Scintillator` constituents, 1x-40x; Assembly composition deferred. | The microscope Model and Assembly composition. |
-
-## Techniques
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Which tomography Practices does the rebuilt beamline offer (e.g. is grating interferometry offered)? | Standard + phase-contrast + dynamic 4D tomography; grating interferometry out of scope. | The SLS Practices that bind the catalog Methods. |
diff --git a/docs/deployments/i-tomcat/techniques.md b/docs/deployments/i-tomcat/techniques.md
deleted file mode 100644
index c89eb4efa9e..00000000000
--- a/docs/deployments/i-tomcat/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What I-TOMCAT is designed to do, as intent. Modelling exercise.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../psi/index.md#the-techniques-adapted-here) is how a facility adapts it. The PSI Practices that bind these are carried pending on the [PSI site page](../psi/index.md#the-techniques-adapted-here) until PSI staff confirm them. The function view survives the eventual equipment choices, which is why it can be written from the public pages before the controls are wired.
-
-I-TOMCAT is a hard X-ray tomographic-microscopy beamline. Its techniques are the tomography-family Methods the catalog already carries, the same ones the APS [2-BM](../2-bm/index.md) pilot earned:
-
-| Technique | Catalog Method | What it is for |
-| --- | --- | --- |
-| Standard microtomography | [`tomography`](../../catalog/methods.md) | absorption-contrast 3D imaging on the U15 undulator, monochromatic 8-30 keV |
-| Propagation-based phase contrast | [`tomography`](../../catalog/methods.md) | edge-enhanced imaging of weakly-absorbing samples (a propagation distance, not a separate fixture) |
-| Fast / dynamic 4D tomography | [`streaming_tomography`](../../catalog/methods.md) | continuous high-speed acquisition via the GigaFRoST streaming camera, for in-situ dynamics |
-
-A few points of intent shape the model:
-
-- **The GigaFRoST camera is the dynamic-tomography enabler.** The PSI in-house continuous-streaming camera (up to 1255 fps full-frame, ~8 GB/s, up to ~33,875 Hz on a reduced ROI) is what distinguishes I-TOMCAT's fast and dynamic 4D tomography from a standard CT beamline. It maps to the catalog `streaming_tomography` Method, not a new one.
-- **Phase contrast is a propagation distance, not a separate station.** Propagation-based phase-contrast imaging runs on the same endstation by moving the detector back from the sample; it is an acquisition mode over one set of optics, modelled under `tomography`, mirroring the 2-BM decision.
-- **Grating interferometry is out of scope.** The legacy TOMCAT offered it only occasionally; it is not modelled here and is not one of the SLS Practices until staff confirm it is offered on the rebuilt beamline (TECH-1).
-
-The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join if the deployment firms toward a real connection. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/i03/governance.md b/docs/deployments/i03/governance.md
deleted file mode 100644
index 2d2b3dbc16c..00000000000
--- a/docs/deployments/i03/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who would act at I03, and the trust shape that would gate it. Design-phase.*
-
-Governance at I03 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-I03 is the second beamline at the Diamond Site (after I22), so it reuses the Diamond facility envelope rather than creating a new one: the Diamond operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I03 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md). This is the same reuse pattern 7-BM follows at APS, the opposite of the new-Site work I22 did.
-
-Because I03 is a modelling exercise, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them. The Diamond PSS clearance is carried pending because its form names are not confirmed (PSS-1).
-
-One governance shape is sharper at I03 than at the other deployments: **autonomous sample handling**. The sample-changing robot would run unattended, so its operation must be gated. Following the 19-BM precedent (ROBOT-1), CORA models this as a Clearance that must be Active before the robot may load, issued after a separate safety review of the changer. The robot is one Positioner-presenting Asset; the autonomy is governed by the Clearance, and the sample it carries is tracked as a `Subject` through a custody lifecycle, not as part of the device. None of that is built yet; the seam is reserved, not invented (ROBOT-1).
-
-The off-roadmap question SCOPE-1 applies here as at I22: whether Diamond becomes a real CORA Site is unanswered. The concrete Zone, Conduit, and Policy instances, the operator pool, and the robot Clearance would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i03/model.md b/docs/deployments/i03/model.md
deleted file mode 100644
index 80d8fb59176..00000000000
--- a/docs/deployments/i03/model.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I03 content lives, the one catalog Family it graduates (`Goniometer`), and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I03 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The one catalog change: graduating Goniometer
-
-I03 is the first Diamond deployment to earn a new catalog Family. The catalog had carried `Goniometer` as pending (documented, not yet defined). I03's `Smargon` is CORA's first canonical six-axis MX goniometer (omega / chi / phi rotation plus x / y / z sample-centring, with centre-of-rotation control), so it is the deployment that graduates Goniometer from pending to a defined Family. The Family stays a bare role-noun; chi-vs-kappa and axis-count variants are per-Asset settings or a bound Model, not Family splits. The per-axis decomposition and centre-of-rotation calibration are carried pending (GONIO-1).
-
-## What is deliberately not here yet
-
-- **New Capabilities / Methods and vendor Models.** I03 graduates Goniometer (an already-pending Family with a canonical instance) but earns no new Capabilities or Methods in this scaffold; the MX recipes are carried pending. No catalog Model is bound.
-- **The robot as a Family.** An adversarial new-kind review refuted a `SampleChanger` Family: the robot is one Positioner-presenting Asset (the 19-BM / 32-ID position), with the sample a `Subject` and autonomy a Clearance. The robot's shape is deferred to ROBOT-1, not minted.
-- **Integration scenarios.** No `test_i03_*.py` registers I03 Assets. Hard-registering a design-phase, off-roadmap beamline would commit speculative structure.
-- **The endstation Assembly.** The goniometer + aperture-scatterguard + backlight + cryostream are carried flat; an MX-endstation Assembly (the 2-BM SampleTower analogue) is promoted only when a feature must act on the whole (ASSEMBLY-1).
-- **Operations and experiment views.** A runbook for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i03/notes.md b/docs/deployments/i03/notes.md
new file mode 100644
index 00000000000..9e61588cc9d
--- /dev/null
+++ b/docs/deployments/i03/notes.md
@@ -0,0 +1,118 @@
+# Notes
+
+## Techniques
+
+*What I03 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I03 is the first macromolecular-crystallography (MX) beamline CORA has looked at, so its techniques are new Methods over the spine. Which enter scope is an open question (TECH-1); the function view below survives the eventual vocabulary choices.
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Rotation (oscillation) data collection | monochromatic, focused | `Eiger` (Detector Role) | new Method binding Goniometer + Eiger + SampleShutter, pending (TECH-1) |
+| Grid scan / sample location | monochromatic, focused | `Eiger` + `OAV` | new Method over the Zebra/PandA fast grid scan, pending (TRIG-1, TECH-1) |
+| Autonomous sample exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
+| Fluorescence / anomalous element ID | monochromatic | `FluorescenceDetector` (Sensor) | deferred until the detector is modelled (DET-1) |
+
+A few points of intent shape the model:
+
+- **MX data collection is a new Method, not a new Capability shape.** A rotation data collection sweeps the goniometer omega while the Eiger captures frames, gated by the fast sample shutter. The device Roles already exist (the graduated Goniometer presents Positioner, the Eiger presents Detector); what is new is the recipe binding them. The catalog tomography Methods do not fit (they bind RotaryStage + Camera + Scintillator, not Goniometer + Eiger), so MX earns its own Methods (TECH-1).
+- **The autonomous loop is a Procedure plus Subject custody, not a device.** The unattended exchange (load pin, thaw, centre, collect, unmount, next) is the genuinely new and non-obvious part of MX automation. CORA expresses it as an orchestrated Procedure over the spine, threaded through the `Subject` aggregate (custody Received to mounted-on-goniometer to measured to Returned / Stored) and gated by a Clearance issued after a safety review. The robot itself is just a Positioner; the workflow is the modelling (ROBOT-1).
+- **Energy change is a Method, not the dodal composite.** dodal couples the undulator and DCM through the `UndulatorDCM` composite, which owns no motors and is being retired upstream. CORA dissolves it into an `energy_change` Method binding the undulator gap and the DCM energy with the lookup-table perp/offset compensation (ENERGY-1).
+- **Grid scan is a Method, not a device.** dodal exposes the fast grid scan only as devices (`ZebraFastGridScan`, `PandAFastGridScan`); CORA models the scan as a Method over the goniometer + detector driven by the timing hardware, not as an Asset (TRIG-1).
+
+The concrete recipes (oscillation ranges, exposure, grid parameters, the exchange sequence) are calibration the deployment must supply. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who would act at I03, and the trust shape that would gate it. Design-phase.*
+
+Governance at I03 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+I03 is the second beamline at the Diamond Site (after I22), so it reuses the Diamond facility envelope rather than creating a new one: the Diamond operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I03 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md). This is the same reuse pattern 7-BM follows at APS, the opposite of the new-Site work I22 did.
+
+Because I03 is a modelling exercise, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them. The Diamond PSS clearance is carried pending because its form names are not confirmed (PSS-1).
+
+One governance shape is sharper at I03 than at the other deployments: **autonomous sample handling**. The sample-changing robot would run unattended, so its operation must be gated. Following the 19-BM precedent (ROBOT-1), CORA models this as a Clearance that must be Active before the robot may load, issued after a separate safety review of the changer. The robot is one Positioner-presenting Asset; the autonomy is governed by the Clearance, and the sample it carries is tracked as a `Subject` through a custody lifecycle, not as part of the device. None of that is built yet; the seam is reserved, not invented (ROBOT-1).
+
+The off-roadmap question SCOPE-1 applies here as at I22: whether Diamond becomes a real CORA Site is unanswered. The concrete Zone, Conduit, and Policy instances, the operator pool, and the robot Clearance would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I03 content lives, the one catalog Family it graduates (`Goniometer`), and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I03 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The one catalog change: graduating Goniometer
+
+I03 is the first Diamond deployment to earn a new catalog Family. The catalog had carried `Goniometer` as pending (documented, not yet defined). I03's `Smargon` is CORA's first canonical six-axis MX goniometer (omega / chi / phi rotation plus x / y / z sample-centring, with centre-of-rotation control), so it is the deployment that graduates Goniometer from pending to a defined Family. The Family stays a bare role-noun; chi-vs-kappa and axis-count variants are per-Asset settings or a bound Model, not Family splits. The per-axis decomposition and centre-of-rotation calibration are carried pending (GONIO-1).
+
+### What is deliberately not here yet
+
+- **New Capabilities / Methods and vendor Models.** I03 graduates Goniometer (an already-pending Family with a canonical instance) but earns no new Capabilities or Methods in this scaffold; the MX recipes are carried pending. No catalog Model is bound.
+- **The robot as a Family.** An adversarial new-kind review refuted a `SampleChanger` Family: the robot is one Positioner-presenting Asset (the 19-BM / 32-ID position), with the sample a `Subject` and autonomy a Clearance. The robot's shape is deferred to ROBOT-1, not minted.
+- **Integration scenarios.** No `test_i03_*.py` registers I03 Assets. Hard-registering a design-phase, off-roadmap beamline would commit speculative structure.
+- **The endstation Assembly.** The goniometer + aperture-scatterguard + backlight + cryostream are carried flat; an MX-endstation Assembly (the 2-BM SampleTower analogue) is promoted only when a feature must act on the whole (ASSEMBLY-1).
+- **Operations and experiment views.** A runbook for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the I03 team (and Diamond's documentation) to confirm before the model can be trusted.*
+
+I03 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles at high confidence; it does not give the calibrated numbers, the hutch / PSS safety structure, the passive beam-path tier, or the Capability / Method binding. This page collects what dodal cannot supply. Each row is a fact the beamline team (or a Diamond drawing / the published I03 beamline paper) owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+As at I22, the EPICS PV prefix for every device is already recorded in the descriptor (the dodal dry fact), so wiring handles is not a question here. The questions are the layers above that, concentrated on the two new MX shapes: the goniometer and the autonomous sample-exchange robot.
+
+### Scope and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is I03 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: I03 graduates the Goniometer Family and stresses autonomous sample handling; it is not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
+| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the optics and experiment hutches? | Both hutches exist with permit signals to be named; dodal does not carry them. | The Enclosure permit signals. |
+| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones (OP, MO, EA, DI), not the access-gated hutch or its safety meaning. | The standard Diamond MX optics + experiment hutch split. | The per-device Enclosure assignment. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the undulator energy range, period, minimum gap, harmonic, and gap-to-energy curve? dodal carries only the lookup-table path and harmonic ~3. | An undulator source with the dodal harmonic; energy range and curve are calibration to supply. | The `Undulator` parameters and the beamline energy range. |
+| ENERGY-1 | Nice-to-have | dodal couples the undulator and DCM (the UndulatorDCM composite, itself being retired upstream). Should CORA model energy change as one Method binding the undulator gap + DCM energy + perp/offset compensation? | Yes: an `energy_change` Method over the two real Assets, not a device; the composite dissolves. | The energy-change seam shape. |
+| OPT-1 | Nice-to-have | What are the mirror coating stripes and bimorph (22-channel) calibration, and the DCM crystal cut, d-spacing, and thermal model? dodal exposes the axes, the Si crystal, and the channel/temperature counts, not the calibrated settings. | The optic internals are per-Asset settings or a bound Model on the existing `Mirror` / `Monochromator` Families. | Which optic internals are modelled and where. |
+| MACHINE-1 | Nice-to-have | How should the machine-level storage-ring state be modelled: a loose `StorageRing` source, an observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
+
+### Diagnostics and feedback
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIAG-1 | Blocks-go-live | The beam-position (QBPM) and flux (Flux, IPin) monitors bind the graduated Sensor Families; what beam-center calibration do they need? | The existing Sensor Role: beam position via the graduated `PositionMonitor` catalog Family (distinct from `FluxMonitor` by measuring position rather than flux), flux via the graduated `FluxMonitor` catalog Family (rule-of-three i22/i03/i15-1); beam-center is calibration to supply. | The beam-center calibration for the diagnostics. |
+| FEEDBACK-1 | Nice-to-have | Is the XBPM feedback loop a modelled CORA construct, or floor (an EPICS control loop CORA observes but does not own)? | Floor: the feedback loop is not a CORA Asset; carried with its modelling deferred. | Whether the feedback loop is modelled or stays on the floor. |
+
+### Sample and the autonomous loop
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | What are the Smargon axis details (omega / chi / phi + x / y / z, centre-of-rotation control, wrapped omega), and is the chi axis a mini-kappa? The Goniometer Family is graduated; the per-axis decomposition and CoR calibration are pending. | One `Goniometer` Asset with per-axis children; chi-vs-kappa and axis-count are settings, not Family splits; CoR is a calibration. | The goniometer per-axis Assets and CoR calibration. |
+| ROBOT-1 | Blocks-go-live | What is the sample-changing robot, how is autonomous loading gated, and what is the Subject custody lifecycle (dewar / puck / pin queue)? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance that must be Active, vendor in a bound Model (the 19-BM ROBOT-1 shape); not a new Family. | The robot Asset, its Clearance gate, the Subject custody thread, and the autonomous loop. |
+| ENV-1 | Blocks-go-live | Must CORA command the sample-environment setpoints (the cryostream temperature, the thawer), or only read them back? | The settable-actuator shape is now settled: both bind the graduated `TemperatureController` Family (presents `Regulator`, requires `Settable`). What is open is whether CORA commands the setpoints. | The command-vs-read decision. |
+| ASSEMBLY-1 | Nice-to-have | Should the goniometer + aperture-scatterguard + backlight + cryostream compose an MX-endstation Assembly (the analogue of 2-BM's SampleTower), and is the cryostream inside it or co-located? | Carried flat in this scaffold; an Assembly is promoted only when a feature must act on the whole. | The endstation `parent_id` grouping. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | What are the Eiger threshold energy and beam-center, the detector-translation axis ranges, and how is the retractable fluorescence detector (and the sample backlight) modelled? | The Eiger reuses `Camera`; the fluorescence detector presents Sensor (loose); the backlight binds the catalog `Backlight` Family; calibration to supply. | The detector calibration and the loose fluorescence modelling. |
+
+### Techniques, triggering, identity
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Which MX Capabilities and Methods are in scope (rotation data collection binding Goniometer + Eiger + Shutter; grid scan; OAV pin-tip centring), and are they new Capabilities or Methods under existing ones? | New Methods over the spine, carried pending on the [Diamond Practices](../diamond/index.md); the catalog tomography Methods do not fit MX as-is. | Which Capabilities and Methods the catalog earns. |
+| TRIG-1 | Nice-to-have | How do the Zebra and PandABox bind to the goniometer, detector, and shutter, and is the fast grid scan a Method (not a device)? dodal exposes grid scan only as devices. | One or two `TimingController` devices carry the scheme; the fast grid scan is a Method / Plan, not a device. | The triggering binding and the grid-scan modelling. |
+| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags) for the devices? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i03/questions.md b/docs/deployments/i03/questions.md
deleted file mode 100644
index 17d12c63488..00000000000
--- a/docs/deployments/i03/questions.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Open questions
-
-*What CORA needs the I03 team (and Diamond's documentation) to confirm before the model can be trusted.*
-
-I03 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles at high confidence; it does not give the calibrated numbers, the hutch / PSS safety structure, the passive beam-path tier, or the Capability / Method binding. This page collects what dodal cannot supply. Each row is a fact the beamline team (or a Diamond drawing / the published I03 beamline paper) owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-As at I22, the EPICS PV prefix for every device is already recorded in the descriptor (the dodal dry fact), so wiring handles is not a question here. The questions are the layers above that, concentrated on the two new MX shapes: the goniometer and the autonomous sample-exchange robot.
-
-## Scope and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is I03 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: I03 graduates the Goniometer Family and stresses autonomous sample handling; it is not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
-| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the optics and experiment hutches? | Both hutches exist with permit signals to be named; dodal does not carry them. | The Enclosure permit signals. |
-| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones (OP, MO, EA, DI), not the access-gated hutch or its safety meaning. | The standard Diamond MX optics + experiment hutch split. | The per-device Enclosure assignment. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the undulator energy range, period, minimum gap, harmonic, and gap-to-energy curve? dodal carries only the lookup-table path and harmonic ~3. | An undulator source with the dodal harmonic; energy range and curve are calibration to supply. | The `Undulator` parameters and the beamline energy range. |
-| ENERGY-1 | Nice-to-have | dodal couples the undulator and DCM (the UndulatorDCM composite, itself being retired upstream). Should CORA model energy change as one Method binding the undulator gap + DCM energy + perp/offset compensation? | Yes: an `energy_change` Method over the two real Assets, not a device; the composite dissolves. | The energy-change seam shape. |
-| OPT-1 | Nice-to-have | What are the mirror coating stripes and bimorph (22-channel) calibration, and the DCM crystal cut, d-spacing, and thermal model? dodal exposes the axes, the Si crystal, and the channel/temperature counts, not the calibrated settings. | The optic internals are per-Asset settings or a bound Model on the existing `Mirror` / `Monochromator` Families. | Which optic internals are modelled and where. |
-| MACHINE-1 | Nice-to-have | How should the machine-level storage-ring state be modelled: a loose `StorageRing` source, an observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
-
-## Diagnostics and feedback
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIAG-1 | Blocks-go-live | The beam-position (QBPM) and flux (Flux, IPin) monitors bind the graduated Sensor Families; what beam-center calibration do they need? | The existing Sensor Role: beam position via the graduated `PositionMonitor` catalog Family (distinct from `FluxMonitor` by measuring position rather than flux), flux via the graduated `FluxMonitor` catalog Family (rule-of-three i22/i03/i15-1); beam-center is calibration to supply. | The beam-center calibration for the diagnostics. |
-| FEEDBACK-1 | Nice-to-have | Is the XBPM feedback loop a modelled CORA construct, or floor (an EPICS control loop CORA observes but does not own)? | Floor: the feedback loop is not a CORA Asset; carried with its modelling deferred. | Whether the feedback loop is modelled or stays on the floor. |
-
-## Sample and the autonomous loop
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | What are the Smargon axis details (omega / chi / phi + x / y / z, centre-of-rotation control, wrapped omega), and is the chi axis a mini-kappa? The Goniometer Family is graduated; the per-axis decomposition and CoR calibration are pending. | One `Goniometer` Asset with per-axis children; chi-vs-kappa and axis-count are settings, not Family splits; CoR is a calibration. | The goniometer per-axis Assets and CoR calibration. |
-| ROBOT-1 | Blocks-go-live | What is the sample-changing robot, how is autonomous loading gated, and what is the Subject custody lifecycle (dewar / puck / pin queue)? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance that must be Active, vendor in a bound Model (the 19-BM ROBOT-1 shape); not a new Family. | The robot Asset, its Clearance gate, the Subject custody thread, and the autonomous loop. |
-| ENV-1 | Blocks-go-live | Must CORA command the sample-environment setpoints (the cryostream temperature, the thawer), or only read them back? | The settable-actuator shape is now settled: both bind the graduated `TemperatureController` Family (presents `Regulator`, requires `Settable`). What is open is whether CORA commands the setpoints. | The command-vs-read decision. |
-| ASSEMBLY-1 | Nice-to-have | Should the goniometer + aperture-scatterguard + backlight + cryostream compose an MX-endstation Assembly (the analogue of 2-BM's SampleTower), and is the cryostream inside it or co-located? | Carried flat in this scaffold; an Assembly is promoted only when a feature must act on the whole. | The endstation `parent_id` grouping. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | What are the Eiger threshold energy and beam-center, the detector-translation axis ranges, and how is the retractable fluorescence detector (and the sample backlight) modelled? | The Eiger reuses `Camera`; the fluorescence detector presents Sensor (loose); the backlight binds the catalog `Backlight` Family; calibration to supply. | The detector calibration and the loose fluorescence modelling. |
-
-## Techniques, triggering, identity
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Which MX Capabilities and Methods are in scope (rotation data collection binding Goniometer + Eiger + Shutter; grid scan; OAV pin-tip centring), and are they new Capabilities or Methods under existing ones? | New Methods over the spine, carried pending on the [Diamond Practices](../diamond/index.md); the catalog tomography Methods do not fit MX as-is. | Which Capabilities and Methods the catalog earns. |
-| TRIG-1 | Nice-to-have | How do the Zebra and PandABox bind to the goniometer, detector, and shutter, and is the fast grid scan a Method (not a device)? dodal exposes grid scan only as devices. | One or two `TimingController` devices carry the scheme; the fast grid scan is a Method / Plan, not a device. | The triggering binding and the grid-scan modelling. |
-| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags) for the devices? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i03/techniques.md b/docs/deployments/i03/techniques.md
deleted file mode 100644
index ebea02ae1f2..00000000000
--- a/docs/deployments/i03/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What I03 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I03 is the first macromolecular-crystallography (MX) beamline CORA has looked at, so its techniques are new Methods over the spine. Which enter scope is an open question (TECH-1); the function view below survives the eventual vocabulary choices.
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Rotation (oscillation) data collection | monochromatic, focused | `Eiger` (Detector Role) | new Method binding Goniometer + Eiger + SampleShutter, pending (TECH-1) |
-| Grid scan / sample location | monochromatic, focused | `Eiger` + `OAV` | new Method over the Zebra/PandA fast grid scan, pending (TRIG-1, TECH-1) |
-| Autonomous sample exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
-| Fluorescence / anomalous element ID | monochromatic | `FluorescenceDetector` (Sensor) | deferred until the detector is modelled (DET-1) |
-
-A few points of intent shape the model:
-
-- **MX data collection is a new Method, not a new Capability shape.** A rotation data collection sweeps the goniometer omega while the Eiger captures frames, gated by the fast sample shutter. The device Roles already exist (the graduated Goniometer presents Positioner, the Eiger presents Detector); what is new is the recipe binding them. The catalog tomography Methods do not fit (they bind RotaryStage + Camera + Scintillator, not Goniometer + Eiger), so MX earns its own Methods (TECH-1).
-- **The autonomous loop is a Procedure plus Subject custody, not a device.** The unattended exchange (load pin, thaw, centre, collect, unmount, next) is the genuinely new and non-obvious part of MX automation. CORA expresses it as an orchestrated Procedure over the spine, threaded through the `Subject` aggregate (custody Received to mounted-on-goniometer to measured to Returned / Stored) and gated by a Clearance issued after a safety review. The robot itself is just a Positioner; the workflow is the modelling (ROBOT-1).
-- **Energy change is a Method, not the dodal composite.** dodal couples the undulator and DCM through the `UndulatorDCM` composite, which owns no motors and is being retired upstream. CORA dissolves it into an `energy_change` Method binding the undulator gap and the DCM energy with the lookup-table perp/offset compensation (ENERGY-1).
-- **Grid scan is a Method, not a device.** dodal exposes the fast grid scan only as devices (`ZebraFastGridScan`, `PandAFastGridScan`); CORA models the scan as a Method over the goniometer + detector driven by the timing hardware, not as an Asset (TRIG-1).
-
-The concrete recipes (oscillation ranges, exposure, grid parameters, the exchange sequence) are calibration the deployment must supply. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/i06/governance.md b/docs/deployments/i06/governance.md
deleted file mode 100644
index b1f3a664f7f..00000000000
--- a/docs/deployments/i06/governance.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Governance
-
-*Who would act at i06, and the trust shape that would gate it. Scaffold.*
-
-Governance at i06 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-i06 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited, shared with the soft X-ray and MX siblings (I22, I03, I15-1, I11, I24). i06 adds only its own beamline-bound principals. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
-
-Because i06 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed.
-
-## The Enclosures i06 gates
-
-The beamline spans three enclosures, the grouping CORA's Zone would follow (ENC-1):
-
-| Enclosure | PV zone | What it holds |
-| --- | --- | --- |
-| i06-optics | BL06I (optics spine), SR06I (the APPLE-II servo crates) | the PGM, the twin APPLE-II controllers, and the i06-branch PEEM sample stage |
-| i06-1 | BL06J | the diffraction-dichroism endstation |
-| i06-2 | BL06K | the PEEM endstation |
-
-How the two endstations share the source, and whether the three PV zones are three separate hutches, is the beamline team's to confirm (ENC-1). The Zone grouping is named here, not built.
-
-## The safety tier behind the beam
-
-The safety tier behind the beam is the personnel safety system. On a soft X-ray beamline the leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from dodal, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
-
-The hazard classes i06 brings to that envelope are those of a soft X-ray UHV beamline:
-
-- **An intense, variable-polarization beam.** i06 is the fleet's first APPLE-II source, so the beam's polarization is a driven experiment axis (LH / LV / PC / NC / LA plus third-harmonic variants over 70-2200 eV), not a fixed property. The radiation hazard is the standard photon-shutter concern the PSS gates (PSS-1); the polarization axis adds optics state, not a new safety tier.
-- **Ultra-high vacuum on the optics and both endstations.** The soft X-ray optics and the two endstations run under UHV (SUP-1). The hazard is the vacuum envelope itself, the same class the PEEM and diffraction-dichroism endstations carry.
-- **In-situ temperature environments.** The i06-1 endstation carries two Lakeshore 336 controllers for sample cooling and heating (TEMP-1). The sample environment spans a temperature range whose limits are pending; the hazard is the cryogen and heater envelope at the sample.
-
-Where these become Clearance-gated operation (for example any unattended or hazardous run) is the shape the Diamond siblings reserve, not instantiated here.
-
-## What is deliberately not modelled
-
-- **The PSS permit signals and shutters (PSS-1).** Absent from dodal, carried pending, not invented.
-- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
-- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The deferred detectors (the i06-1 scattering detector and the PEEM electron-image column, DET-1 and PEEM-1) are equipment, not governance, decisions; they live on [Model](model.md#deliberately-not-here-yet). The full delete-on-answer queue is on [Open questions](questions.md).
diff --git a/docs/deployments/i06/model.md b/docs/deployments/i06/model.md
deleted file mode 100644
index caeb760f90b..00000000000
--- a/docs/deployments/i06/model.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's i06 content lives, why this first APPLE-II deployment coins no new family and models polarization as an axis, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at i06 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes i06 new
-
-i06 is CORA's first APPLE-II (variable-polarization) source. The fleet's other insertion devices set a gap; an APPLE-II additionally drives its magnetic phase rows to choose the X-ray polarization, so i06 is the first beamline whose run sets the polarization as an experiment axis: linear horizontal or vertical, linear at an arbitrary angle, circular positive or negative, and third-harmonic variants. That is what magnetic dichroism needs (the X-ray magnetic circular and linear dichroism contrast comes from flipping or rotating the polarization at an absorption edge). i06 is also CORA's first PEEM (photoemission electron microscopy) endstation, an electron-imaging technique distinct from the electron-energy analysis of ARPES.
-
-The novelty forces no new device families. It is carried by two reuse decisions and two deferrals (below). The genuinely new modelling primitive, polarization as a driven axis, is expressed by reusing the existing `PseudoAxis` Family, the same way incident energy is already a pseudo-axis.
-
-## No new families
-
-i06 coins no new Family and changes nothing in the catalog. The four devices that could have tempted a new kind all fold into existing vocabulary:
-
-- **The two APPLE-II undulators bind the catalog `InsertionDevice`, not a new source family.** An APPLE-II is the same source-undulator anatomy as the EPUs already bound by SIX, CSX, and ESM. The catalog `InsertionDevice` Family already "spans the undulator and the wiggler; the device type and its gap / field parameters are a per-Asset settings difference." The APPLE-II variable-polarization phase rows, the EPICS energy-to-gap polynomial lookup, and the coordinating controller are per-Asset settings and the bound Model (they are how the gap and phase are driven), not a new device class. This resolves the long-standing `SRC-1` question toward reuse: a second concordant variable-polarization source confirms the existing Family stretches, rather than earning a split.
-
-- **Polarization is a `PseudoAxis`, not a new primitive.** The thing an i06 run sets, the polarization, is modelled as a `PseudoAxis` Asset, a sibling of the incident-energy pseudo-axis over the same source. The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants) is the axis's value set, and the controller's polarization-to-phase conversion is its partition rule. This is exactly the 2-BM beam-energy-as-pseudo-axis precedent, extended to a second driven source quantity. CORA names the axis, writes the value, and records the move; by default the live i06 controller owns the polarization-to-phase kinematics (the partition rule is carried rule-less, `POL-1`), so CORA does not duplicate a second source of truth for the optics geometry.
-
-- **The PEEM sample manipulators bind the graduated `Manipulator`.** The PEEM endstation's UHV sample manipulators (x / y / phi plus the energy-slit translation) reuse the `Manipulator` Family graduated on SIX and ESM; the energy-slit axis and axis count are per-Asset settings.
-
-- **The PGM binds `GratingMonochromator`, the diffractometer binds `Goniometer`, the Lakeshores bind `TemperatureController`.** All three reuse families the soft X-ray and diffraction siblings already earned.
-
-## Deliberately not here yet
-
-- **The PEEM electron-imaging column and detector (`PEEM-1`).** The PEEM technique's defining instrument, the electron-optical column that forms a magnified electron image of the photoemitting surface, is not a dodal device (dodal binds the PEEM sample manipulator and its energy slit, not the column or the image detector). It is the `ElectronMicroscope` anatomy: an electron-imaging column, distinct from the photon `Camera` (which produces a Frame from photons) and from the energy-analyzing catalog `ElectronAnalyzer` (the ESM / ARPES electron-energy analyzer). It is deferred as `PEEM-1`, not coined: binding a family with no PV would create an orphan, so the column and detector land once their handles are sourced. i06's PEEM branch is then a candidate first sighting for an `ElectronMicroscope` family.
-
-- **The i06-1 diffraction detector and the flux monitors (`DET-1`).** The i06-1 scattering detector and any incident-flux or drain-current (electron-yield) monitor are absent from dodal (only the detector-arm motors are present). The geometry is modelled now; the detectors are bound later from outside dodal, and no detector Family is invented in the meantime.
-
-- **The diffractometer Assembly (`DIFF-1`).** Whether the i06-1 sample circles plus the detector arm compose an `Assembly(Diffractometer)` is deferred, exactly as 4-ID, 8-ID, and CSX deferred materializing their soft X-ray diffractometer Assemblies in descriptor mode. The first cut is a flat `Goniometer` Asset plus a reciprocal-space `PseudoAxis`, with the Assembly named as the follow-on.
-
-- **The XMCD / XMLD / PEEM Methods.** Whether magnetic dichroism, photoemission microscopy, and resonant soft X-ray diffraction enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. XMCD and resonant scattering share the 4-ID Methods; XMLD and photoemission microscopy are new pending slugs (`TECH-1`, `PEEM-1`).
-
-- **The polarization Calibration (`POL-1`).** Pinning the polarization-to-phase conversion as a CORA-owned LookupTable Calibration revision (rather than letting the live i06 controller own it) is deferred; it is only needed if CORA must scan polarization without the i06 controller in the loop.
-
-- **The simulated devices and full asset-tree scenarios.** No `test_i06_*.py` registers the asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i06/notes.md b/docs/deployments/i06/notes.md
new file mode 100644
index 00000000000..f4bf5fdf04d
--- /dev/null
+++ b/docs/deployments/i06/notes.md
@@ -0,0 +1,210 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of i06 is designed to do, as intent. Scaffold.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i06's techniques all sit in one family: polarization-driven dichroism. Every one of them turns the X-ray polarization at an absorption edge and reads the change in contrast, whether that contrast is an absorption spectrum, an electron image, or a diffraction peak. So i06's modelling story is not a new recipe over the spine; it is a new acquisition axis (the polarization) that the existing soft X-ray Methods now drive.
+
+i06 is CORA's first APPLE-II source, so it is the first beamline that can set that axis at all. It is also CORA's first PEEM (photoemission electron microscopy) endstation, an electron-imaging technique whose defining instrument (the electron-optical column and its image detector) is not yet a CORA device (PEEM-1). The function view below survives both: it describes what each technique does, while the catalog vocabulary and the deferred instruments are carried as questions.
+
+### The polarization-driven dichroism family
+
+i06 carries four techniques, all pending in CORA's catalog. Two share Methods already pending from the 4-ID soft X-ray deployment; two are new pending slugs.
+
+| Technique | CORA Method | Contrast it reads | Status in CORA |
+| --- | --- | --- | --- |
+| X-ray magnetic circular dichroism (XMCD) | `xmcd` | absorption difference between circular-positive and circular-negative polarization at a magnetic edge | shares the 4-ID `xmcd` Method, pending (TECH-1) |
+| X-ray magnetic linear dichroism (XMLD) | `xmld` | absorption difference between two linear-polarization angles at a magnetic edge | new pending slug `xmld` (TECH-1) |
+| Photoemission electron microscopy (PEEM) | `photoemission_microscopy` | magnified electron image of the photoemitting surface, with polarization-driven magnetic / electronic contrast | new pending slug, the imaging detector deferred (PEEM-1) |
+| Resonant soft X-ray diffraction / dichroism | `resonant_scattering` | a diffraction peak whose intensity tracks order (magnetic / charge / orbital) as the polarization and energy are tuned through resonance | shares the 4-ID `resonant_scattering` Method, pending (TECH-1) |
+
+Each technique adapts to i06 as a Site Practice on the [Diamond Site](../diamond/index.md#the-techniques-adapted-here): `I06_xmcd_practice`, `I06_xmld_practice`, `I06_peem_practice`, and `I06_resonant_diffraction_practice`, all pending. The Practices render unlinked until the owner decides whether each Method enters the catalog (TECH-1, PEEM-1).
+
+A few points of intent shape the family:
+
+- **The four techniques differ in what reads the contrast, not in how the contrast is made.** XMCD and XMLD read it as an absorption spectrum on the i06-1 stages; PEEM reads it as a magnified electron image at the i06-2 endstation; resonant diffraction reads it as the intensity of a Bragg peak on the i06-1 diffractometer. The shared move underneath all four is the same: set or turn the polarization at an absorption edge and observe the difference. That shared move is the new primitive (see below), and it is why XMCD and resonant scattering can reuse the Methods 4-ID already carries rather than coin i06-specific ones.
+
+- **Two techniques reuse 4-ID Methods; two are new.** XMCD and resonant soft X-ray diffraction are the same Methods CORA already carries pending from the 4-ID deployment, so i06 is a second consumer rather than a coiner: the second consumer is the graduation watch-item for both. XMLD and photoemission microscopy have no existing Method that fits, so they are new pending slugs (`xmld`, `photoemission_microscopy`). Whether any of the four enters CORA's catalog as a Capability is an owner decision (TECH-1, PEEM-1).
+
+- **PEEM is an imaging technique, and its instrument is not modelled yet.** PEEM is distinct from the electron-energy analysis of ARPES (the ESM endstation): ARPES analyses the energy and angle of photoelectrons, while PEEM forms a magnified spatial image of where they came from. The instrument that forms that image, the electron-optical column and its magnified electron-image detector, is absent from dodal and is deferred (PEEM-1). CORA models the PEEM sample manipulators now (they reuse the graduated `Manipulator` Family), and the column and image detector land once their PV handles are sourced. The `photoemission_microscopy` Method is the technique view of the same deferral: the recipe is named, the imaging instrument it would bind is not yet coined.
+
+- **Resonant diffraction and XAS reuse the i06-1 geometry, and the detectors are deferred.** The i06-1 diffractometer (sample circles plus the detector arm) and the absorption stage are modelled now (DIFF-1, STAGE-1), but the i06-1 scattering detector and any incident-flux or drain-current electron-yield monitor are absent from dodal and are not invented (DET-1). So the techniques that read a diffraction peak or an absorption spectrum carry their detector as pending: the geometry that aims the beam is in the model, the device that records the signal is bound later.
+
+### Polarization as a new operating axis for the fleet
+
+The genuinely new thing i06 brings is not a Method; it is an axis. An APPLE-II undulator can drive its magnetic phase rows to choose the X-ray polarization, not just set a gap, so for the first time in the fleet a run can ask for a polarization the way it asks for an energy.
+
+i06 models this as a [`PseudoAxis`](../../catalog/families.md), a sibling of the incident-energy pseudo-axis over the same source (the 2-BM beam-energy precedent, extended to a second driven source quantity). The shape is:
+
+- **Set the polarization on the APPLE-II.** The axis's value domain is the polarization set the source can produce: linear horizontal (LH), linear vertical (LV), linear at an arbitrary angle (LA), circular positive (PC), circular negative (NC), plus third-harmonic variants (POL-1). The run names a value; CORA writes it; the source's phase rows move to produce it.
+
+- **Flip or rotate it at an absorption edge to make the contrast.** XMCD flips between PC and NC at a magnetic edge and reads the absorption difference. XMLD rotates between two linear angles. Resonant diffraction tunes the polarization and the incident energy together through a resonance. In every case the contrast is the change the polarization causes, so turning the polarization at the edge is the acquisition primitive the whole dichroism family is built on.
+
+- **The conversion stays on the live controller.** The polarization-to-phase kinematics (how a requested polarization becomes a phase-row position) is the axis's partition rule, and it is carried rule-less by default: the live i06 controller owns the conversion, so CORA names the axis and records the move without duplicating a second source of truth for the source geometry (POL-1). Pinning the conversion as a CORA-owned Calibration is deferred until a run needs to scan polarization without that controller in the loop. The same asymmetry the source-axis wiring carries (only the upstream IDU exposes the driven polarization handle in dodal) is an open question (POL-2).
+
+This is the new acquisition primitive expressed entirely by reuse. The polarization axis is a `PseudoAxis` and the source is an `InsertionDevice`; no new device Family appears. What is new is that a run now carries a polarization alongside its energy, and the dichroism Methods drive both.
+
+### Not modelled yet
+
+The intent above is the function view. The concrete recipes that turn it into runnable acquisition are deliberately not written, because writing them for a beamline CORA does not yet drive would be invention rather than record:
+
+- **The concrete dichroism recipes.** The per-edge energy and polarization sequences, the dwell and averaging, the field and temperature setpoints for an in-situ measurement, and the PEEM imaging sequence are calibration the deployment must supply. None of it is invented here.
+
+- **Whether each Method enters the catalog.** Minting a Method is owner-scope. XMCD and resonant scattering reuse 4-ID Methods, and XMLD and photoemission microscopy are new slugs, but all four render pending until the owner decides (TECH-1, PEEM-1). The decision is recorded on the [Model](#model) page, not made here.
+
+- **The PEEM imaging instrument.** The PEEM electron-optical column and its magnified electron-image detector are deferred (PEEM-1): they are the `ElectronMicroscope` anatomy, distinct from the photon `Camera` and from the energy-analyzing catalog `ElectronAnalyzer`, and they are not coined here because they have no PV in dodal.
+
+- **The i06-1 detectors and flux monitor.** The diffraction scattering detector and the incident-flux / drain-current monitor are absent from dodal and are bound later from outside it, with no detector Family invented in the meantime (DET-1).
+
+For the source and optics that feed these techniques, see the generated source-walk on [the beamline page](source.md). For what the i06 team must confirm before the model can be trusted, see [Open questions](#open-questions). The CORA-owned scope decisions (the polarization Calibration, the deferred Methods, the diffractometer Assembly) are recorded on the [Model](#deliberately-not-here-yet) page.
+
+## Governance
+
+*Who would act at i06, and the trust shape that would gate it. Scaffold.*
+
+Governance at i06 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+i06 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited, shared with the soft X-ray and MX siblings (I22, I03, I15-1, I11, I24). i06 adds only its own beamline-bound principals. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
+
+Because i06 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed.
+
+### The Enclosures i06 gates
+
+The beamline spans three enclosures, the grouping CORA's Zone would follow (ENC-1):
+
+| Enclosure | PV zone | What it holds |
+| --- | --- | --- |
+| i06-optics | BL06I (optics spine), SR06I (the APPLE-II servo crates) | the PGM, the twin APPLE-II controllers, and the i06-branch PEEM sample stage |
+| i06-1 | BL06J | the diffraction-dichroism endstation |
+| i06-2 | BL06K | the PEEM endstation |
+
+How the two endstations share the source, and whether the three PV zones are three separate hutches, is the beamline team's to confirm (ENC-1). The Zone grouping is named here, not built.
+
+### The safety tier behind the beam
+
+The safety tier behind the beam is the personnel safety system. On a soft X-ray beamline the leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from dodal, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
+
+The hazard classes i06 brings to that envelope are those of a soft X-ray UHV beamline:
+
+- **An intense, variable-polarization beam.** i06 is the fleet's first APPLE-II source, so the beam's polarization is a driven experiment axis (LH / LV / PC / NC / LA plus third-harmonic variants over 70-2200 eV), not a fixed property. The radiation hazard is the standard photon-shutter concern the PSS gates (PSS-1); the polarization axis adds optics state, not a new safety tier.
+- **Ultra-high vacuum on the optics and both endstations.** The soft X-ray optics and the two endstations run under UHV (SUP-1). The hazard is the vacuum envelope itself, the same class the PEEM and diffraction-dichroism endstations carry.
+- **In-situ temperature environments.** The i06-1 endstation carries two Lakeshore 336 controllers for sample cooling and heating (TEMP-1). The sample environment spans a temperature range whose limits are pending; the hazard is the cryogen and heater envelope at the sample.
+
+Where these become Clearance-gated operation (for example any unattended or hazardous run) is the shape the Diamond siblings reserve, not instantiated here.
+
+### What is deliberately not modelled
+
+- **The PSS permit signals and shutters (PSS-1).** Absent from dodal, carried pending, not invented.
+- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
+- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The deferred detectors (the i06-1 scattering detector and the PEEM electron-image column, DET-1 and PEEM-1) are equipment, not governance, decisions; they live on [Model](#deliberately-not-here-yet). The full delete-on-answer queue is on [Open questions](#open-questions).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's i06 content lives, why this first APPLE-II deployment coins no new family and models polarization as an axis, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at i06 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes i06 new
+
+i06 is CORA's first APPLE-II (variable-polarization) source. The fleet's other insertion devices set a gap; an APPLE-II additionally drives its magnetic phase rows to choose the X-ray polarization, so i06 is the first beamline whose run sets the polarization as an experiment axis: linear horizontal or vertical, linear at an arbitrary angle, circular positive or negative, and third-harmonic variants. That is what magnetic dichroism needs (the X-ray magnetic circular and linear dichroism contrast comes from flipping or rotating the polarization at an absorption edge). i06 is also CORA's first PEEM (photoemission electron microscopy) endstation, an electron-imaging technique distinct from the electron-energy analysis of ARPES.
+
+The novelty forces no new device families. It is carried by two reuse decisions and two deferrals (below). The genuinely new modelling primitive, polarization as a driven axis, is expressed by reusing the existing `PseudoAxis` Family, the same way incident energy is already a pseudo-axis.
+
+### No new families
+
+i06 coins no new Family and changes nothing in the catalog. The four devices that could have tempted a new kind all fold into existing vocabulary:
+
+- **The two APPLE-II undulators bind the catalog `InsertionDevice`, not a new source family.** An APPLE-II is the same source-undulator anatomy as the EPUs already bound by SIX, CSX, and ESM. The catalog `InsertionDevice` Family already "spans the undulator and the wiggler; the device type and its gap / field parameters are a per-Asset settings difference." The APPLE-II variable-polarization phase rows, the EPICS energy-to-gap polynomial lookup, and the coordinating controller are per-Asset settings and the bound Model (they are how the gap and phase are driven), not a new device class. This resolves the long-standing `SRC-1` question toward reuse: a second concordant variable-polarization source confirms the existing Family stretches, rather than earning a split.
+
+- **Polarization is a `PseudoAxis`, not a new primitive.** The thing an i06 run sets, the polarization, is modelled as a `PseudoAxis` Asset, a sibling of the incident-energy pseudo-axis over the same source. The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants) is the axis's value set, and the controller's polarization-to-phase conversion is its partition rule. This is exactly the 2-BM beam-energy-as-pseudo-axis precedent, extended to a second driven source quantity. CORA names the axis, writes the value, and records the move; by default the live i06 controller owns the polarization-to-phase kinematics (the partition rule is carried rule-less, `POL-1`), so CORA does not duplicate a second source of truth for the optics geometry.
+
+- **The PEEM sample manipulators bind the graduated `Manipulator`.** The PEEM endstation's UHV sample manipulators (x / y / phi plus the energy-slit translation) reuse the `Manipulator` Family graduated on SIX and ESM; the energy-slit axis and axis count are per-Asset settings.
+
+- **The PGM binds `GratingMonochromator`, the diffractometer binds `Goniometer`, the Lakeshores bind `TemperatureController`.** All three reuse families the soft X-ray and diffraction siblings already earned.
+
+### Deliberately not here yet
+
+- **The PEEM electron-imaging column and detector (`PEEM-1`).** The PEEM technique's defining instrument, the electron-optical column that forms a magnified electron image of the photoemitting surface, is not a dodal device (dodal binds the PEEM sample manipulator and its energy slit, not the column or the image detector). It is the `ElectronMicroscope` anatomy: an electron-imaging column, distinct from the photon `Camera` (which produces a Frame from photons) and from the energy-analyzing catalog `ElectronAnalyzer` (the ESM / ARPES electron-energy analyzer). It is deferred as `PEEM-1`, not coined: binding a family with no PV would create an orphan, so the column and detector land once their handles are sourced. i06's PEEM branch is then a candidate first sighting for an `ElectronMicroscope` family.
+
+- **The i06-1 diffraction detector and the flux monitors (`DET-1`).** The i06-1 scattering detector and any incident-flux or drain-current (electron-yield) monitor are absent from dodal (only the detector-arm motors are present). The geometry is modelled now; the detectors are bound later from outside dodal, and no detector Family is invented in the meantime.
+
+- **The diffractometer Assembly (`DIFF-1`).** Whether the i06-1 sample circles plus the detector arm compose an `Assembly(Diffractometer)` is deferred, exactly as 4-ID, 8-ID, and CSX deferred materializing their soft X-ray diffractometer Assemblies in descriptor mode. The first cut is a flat `Goniometer` Asset plus a reciprocal-space `PseudoAxis`, with the Assembly named as the follow-on.
+
+- **The XMCD / XMLD / PEEM Methods.** Whether magnetic dichroism, photoemission microscopy, and resonant soft X-ray diffraction enter CORA's catalog as Capabilities / Methods is an owner decision; the Practices render unlinked, pending. XMCD and resonant scattering share the 4-ID Methods; XMLD and photoemission microscopy are new pending slugs (`TECH-1`, `PEEM-1`).
+
+- **The polarization Calibration (`POL-1`).** Pinning the polarization-to-phase conversion as a CORA-owned LookupTable Calibration revision (rather than letting the live i06 controller own it) is deferred; it is only needed if CORA must scan polarization without the i06 controller in the loop.
+
+- **The simulated devices and full asset-tree scenarios.** No `test_i06_*.py` registers the asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the i06 team to confirm before the model can be trusted.*
+
+i06 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i06*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the PV zones BL06I (optics spine), BL06J (i06-1), and BL06K (i06-2) three separate hutches, and how do the two endstations share the source? | Three enclosures: a shared `i06-optics` zone and the `i06-1` and `i06-2` experiment hutches. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The two APPLE-II undulator periods, the gap range, and how the downstream (IDD) and upstream (IDU) devices coordinate to feed the branches. | Two `InsertionDevice` Assets; period and coordination carried pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state i06 reads (current, fill, machine mode). | Observe-only machine state on `SR-DI-DCCT-01` / `CS-CS-MSTAT-01` / `SR-CS-FILL-01`, a loose `StorageRing`. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The plane-grating monochromator gratings (line densities), the cff fixed-focus constant, and the incident-energy range and partition rule. | A soft X-ray PGM bound to `GratingMonochromator`, 70-2200 eV, gratings 150 / 400 / 1200 l/mm; the energy pseudo-axis decomposes to the PGM and the APPLE-II gap. | The monochromator and incident-energy Assets. |
+| POL-2 | Blocks-go-live | The IDD / IDU asymmetry: only the upstream IDU exposes the driven energy / polarization handles in dodal, while the downstream IDD stops at its controller. Should CORA expose a symmetric IDD handle? | The energy and polarization pseudo-axes are over the upstream IDU; the IDD is a sibling `InsertionDevice` Asset. | The source-axis wiring. |
+
+### Beam axes: polarization
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| POL-1 | Blocks-go-live | The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants) and the polarization-to-phase conversion: should CORA pin the conversion as a LookupTable Calibration, or run the polarization pseudo-axis rule-less and let the live i06 controller own the kinematics? | A `PseudoAxis` over the APPLE-II phase rows, value domain as listed, carried rule-less by default (the controller owns the conversion). | The polarization-axis modelling. |
+
+### Diffraction-dichroism endstation (i06-1)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The i06-1 diffraction-dichroism circle roles (sample theta incidence, chi / phi orientation, the DET:2THETA / DET:Y detector arm) and whether they compose an Assembly. | A `Goniometer` for the sample circles plus a detector arm; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the diffraction-dichroism circles (the inverse-kinematics rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / CSX. | The reciprocal-space Asset. |
+| STAGE-1 | Nice-to-have | Whether the absorption-stage theta (and the diffractometer chi / phi) warrant a `Goniometer` plus Assembly rather than the `LinearStage` placeholder. | The absorption stage bound to `LinearStage` as a design-phase placeholder. | The absorption-stage Family. |
+| TEMP-1 | Nice-to-have | The Lakeshore 336 cooling and heating ranges and channel assignment. | Two `TemperatureController` Assets presenting the `Regulator` Role; cooling-vs-heating a per-Asset setting; ranges pending. | The temperature-control modelling. |
+| DET-1 | Blocks-go-live | The i06-1 diffraction scattering detector and any incident-flux / drain-current (electron-yield) monitor: both are absent from dodal. | Not modelled as devices: the geometry is modelled now and the detector(s) bound later from outside dodal; no detector Family invented. | The detector modelling. |
+
+### PEEM endstation (i06-2)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MANIP-1 | Blocks-go-live | The PEEM sample-manipulator axis sets (the i06-2 `peem` x / y / phi plus the es energy-slit translation, and the i06-branch sample stage). | Two `Manipulator` Assets reusing the graduated Family; axis sets carried pending. | The manipulator modelling. |
+| PEEM-1 | Blocks-go-live | The PEEM electron-optical column and its magnified electron-image detector: both are absent from dodal. | Not modelled: the electron-imaging column is the `ElectronMicroscope` anatomy, deferred until its PVs are sourced; not coined here. | The PEEM imaging-detector modelling; the CORA family decision is on [Model](#deliberately-not-here-yet). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the soft X-ray optics and the UHV endstations) and the cooling supply. | Photon beam, cooling water, and ultra-high vacuum on the optics and endstations. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do the soft X-ray dichroism and resonant-scattering techniques (XMCD, XMLD, resonant diffraction) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; XMCD and resonant scattering share the 4-ID Methods, XMLD is a new pending slug; none coined. | The dichroism / resonant Capabilities. |
diff --git a/docs/deployments/i06/questions.md b/docs/deployments/i06/questions.md
deleted file mode 100644
index 611551be2f2..00000000000
--- a/docs/deployments/i06/questions.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Open questions
-
-*What CORA needs the i06 team to confirm before the model can be trusted.*
-
-i06 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i06*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the PV zones BL06I (optics spine), BL06J (i06-1), and BL06K (i06-2) three separate hutches, and how do the two endstations share the source? | Three enclosures: a shared `i06-optics` zone and the `i06-1` and `i06-2` experiment hutches. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The two APPLE-II undulator periods, the gap range, and how the downstream (IDD) and upstream (IDU) devices coordinate to feed the branches. | Two `InsertionDevice` Assets; period and coordination carried pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state i06 reads (current, fill, machine mode). | Observe-only machine state on `SR-DI-DCCT-01` / `CS-CS-MSTAT-01` / `SR-CS-FILL-01`, a loose `StorageRing`. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The plane-grating monochromator gratings (line densities), the cff fixed-focus constant, and the incident-energy range and partition rule. | A soft X-ray PGM bound to `GratingMonochromator`, 70-2200 eV, gratings 150 / 400 / 1200 l/mm; the energy pseudo-axis decomposes to the PGM and the APPLE-II gap. | The monochromator and incident-energy Assets. |
-| POL-2 | Blocks-go-live | The IDD / IDU asymmetry: only the upstream IDU exposes the driven energy / polarization handles in dodal, while the downstream IDD stops at its controller. Should CORA expose a symmetric IDD handle? | The energy and polarization pseudo-axes are over the upstream IDU; the IDD is a sibling `InsertionDevice` Asset. | The source-axis wiring. |
-
-## Beam axes: polarization
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| POL-1 | Blocks-go-live | The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants) and the polarization-to-phase conversion: should CORA pin the conversion as a LookupTable Calibration, or run the polarization pseudo-axis rule-less and let the live i06 controller own the kinematics? | A `PseudoAxis` over the APPLE-II phase rows, value domain as listed, carried rule-less by default (the controller owns the conversion). | The polarization-axis modelling. |
-
-## Diffraction-dichroism endstation (i06-1)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The i06-1 diffraction-dichroism circle roles (sample theta incidence, chi / phi orientation, the DET:2THETA / DET:Y detector arm) and whether they compose an Assembly. | A `Goniometer` for the sample circles plus a detector arm; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the diffraction-dichroism circles (the inverse-kinematics rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / CSX. | The reciprocal-space Asset. |
-| STAGE-1 | Nice-to-have | Whether the absorption-stage theta (and the diffractometer chi / phi) warrant a `Goniometer` plus Assembly rather than the `LinearStage` placeholder. | The absorption stage bound to `LinearStage` as a design-phase placeholder. | The absorption-stage Family. |
-| TEMP-1 | Nice-to-have | The Lakeshore 336 cooling and heating ranges and channel assignment. | Two `TemperatureController` Assets presenting the `Regulator` Role; cooling-vs-heating a per-Asset setting; ranges pending. | The temperature-control modelling. |
-| DET-1 | Blocks-go-live | The i06-1 diffraction scattering detector and any incident-flux / drain-current (electron-yield) monitor: both are absent from dodal. | Not modelled as devices: the geometry is modelled now and the detector(s) bound later from outside dodal; no detector Family invented. | The detector modelling. |
-
-## PEEM endstation (i06-2)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MANIP-1 | Blocks-go-live | The PEEM sample-manipulator axis sets (the i06-2 `peem` x / y / phi plus the es energy-slit translation, and the i06-branch sample stage). | Two `Manipulator` Assets reusing the graduated Family; axis sets carried pending. | The manipulator modelling. |
-| PEEM-1 | Blocks-go-live | The PEEM electron-optical column and its magnified electron-image detector: both are absent from dodal. | Not modelled: the electron-imaging column is the `ElectronMicroscope` anatomy, deferred until its PVs are sourced; not coined here. | The PEEM imaging-detector modelling; the CORA family decision is on [Model](model.md#deliberately-not-here-yet). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the soft X-ray optics and the UHV endstations) and the cooling supply. | Photon beam, cooling water, and ultra-high vacuum on the optics and endstations. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do the soft X-ray dichroism and resonant-scattering techniques (XMCD, XMLD, resonant diffraction) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; XMCD and resonant scattering share the 4-ID Methods, XMLD is a new pending slug; none coined. | The dichroism / resonant Capabilities. |
diff --git a/docs/deployments/i06/techniques.md b/docs/deployments/i06/techniques.md
deleted file mode 100644
index 51a59a7fbc1..00000000000
--- a/docs/deployments/i06/techniques.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Techniques
-
-*What the modelled part of i06 is designed to do, as intent. Scaffold.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i06's techniques all sit in one family: polarization-driven dichroism. Every one of them turns the X-ray polarization at an absorption edge and reads the change in contrast, whether that contrast is an absorption spectrum, an electron image, or a diffraction peak. So i06's modelling story is not a new recipe over the spine; it is a new acquisition axis (the polarization) that the existing soft X-ray Methods now drive.
-
-i06 is CORA's first APPLE-II source, so it is the first beamline that can set that axis at all. It is also CORA's first PEEM (photoemission electron microscopy) endstation, an electron-imaging technique whose defining instrument (the electron-optical column and its image detector) is not yet a CORA device (PEEM-1). The function view below survives both: it describes what each technique does, while the catalog vocabulary and the deferred instruments are carried as questions.
-
-## The polarization-driven dichroism family
-
-i06 carries four techniques, all pending in CORA's catalog. Two share Methods already pending from the 4-ID soft X-ray deployment; two are new pending slugs.
-
-| Technique | CORA Method | Contrast it reads | Status in CORA |
-| --- | --- | --- | --- |
-| X-ray magnetic circular dichroism (XMCD) | `xmcd` | absorption difference between circular-positive and circular-negative polarization at a magnetic edge | shares the 4-ID `xmcd` Method, pending (TECH-1) |
-| X-ray magnetic linear dichroism (XMLD) | `xmld` | absorption difference between two linear-polarization angles at a magnetic edge | new pending slug `xmld` (TECH-1) |
-| Photoemission electron microscopy (PEEM) | `photoemission_microscopy` | magnified electron image of the photoemitting surface, with polarization-driven magnetic / electronic contrast | new pending slug, the imaging detector deferred (PEEM-1) |
-| Resonant soft X-ray diffraction / dichroism | `resonant_scattering` | a diffraction peak whose intensity tracks order (magnetic / charge / orbital) as the polarization and energy are tuned through resonance | shares the 4-ID `resonant_scattering` Method, pending (TECH-1) |
-
-Each technique adapts to i06 as a Site Practice on the [Diamond Site](../diamond/index.md#the-techniques-adapted-here): `I06_xmcd_practice`, `I06_xmld_practice`, `I06_peem_practice`, and `I06_resonant_diffraction_practice`, all pending. The Practices render unlinked until the owner decides whether each Method enters the catalog (TECH-1, PEEM-1).
-
-A few points of intent shape the family:
-
-- **The four techniques differ in what reads the contrast, not in how the contrast is made.** XMCD and XMLD read it as an absorption spectrum on the i06-1 stages; PEEM reads it as a magnified electron image at the i06-2 endstation; resonant diffraction reads it as the intensity of a Bragg peak on the i06-1 diffractometer. The shared move underneath all four is the same: set or turn the polarization at an absorption edge and observe the difference. That shared move is the new primitive (see below), and it is why XMCD and resonant scattering can reuse the Methods 4-ID already carries rather than coin i06-specific ones.
-
-- **Two techniques reuse 4-ID Methods; two are new.** XMCD and resonant soft X-ray diffraction are the same Methods CORA already carries pending from the 4-ID deployment, so i06 is a second consumer rather than a coiner: the second consumer is the graduation watch-item for both. XMLD and photoemission microscopy have no existing Method that fits, so they are new pending slugs (`xmld`, `photoemission_microscopy`). Whether any of the four enters CORA's catalog as a Capability is an owner decision (TECH-1, PEEM-1).
-
-- **PEEM is an imaging technique, and its instrument is not modelled yet.** PEEM is distinct from the electron-energy analysis of ARPES (the ESM endstation): ARPES analyses the energy and angle of photoelectrons, while PEEM forms a magnified spatial image of where they came from. The instrument that forms that image, the electron-optical column and its magnified electron-image detector, is absent from dodal and is deferred (PEEM-1). CORA models the PEEM sample manipulators now (they reuse the graduated `Manipulator` Family), and the column and image detector land once their PV handles are sourced. The `photoemission_microscopy` Method is the technique view of the same deferral: the recipe is named, the imaging instrument it would bind is not yet coined.
-
-- **Resonant diffraction and XAS reuse the i06-1 geometry, and the detectors are deferred.** The i06-1 diffractometer (sample circles plus the detector arm) and the absorption stage are modelled now (DIFF-1, STAGE-1), but the i06-1 scattering detector and any incident-flux or drain-current electron-yield monitor are absent from dodal and are not invented (DET-1). So the techniques that read a diffraction peak or an absorption spectrum carry their detector as pending: the geometry that aims the beam is in the model, the device that records the signal is bound later.
-
-## Polarization as a new operating axis for the fleet
-
-The genuinely new thing i06 brings is not a Method; it is an axis. An APPLE-II undulator can drive its magnetic phase rows to choose the X-ray polarization, not just set a gap, so for the first time in the fleet a run can ask for a polarization the way it asks for an energy.
-
-i06 models this as a [`PseudoAxis`](../../catalog/families.md), a sibling of the incident-energy pseudo-axis over the same source (the 2-BM beam-energy precedent, extended to a second driven source quantity). The shape is:
-
-- **Set the polarization on the APPLE-II.** The axis's value domain is the polarization set the source can produce: linear horizontal (LH), linear vertical (LV), linear at an arbitrary angle (LA), circular positive (PC), circular negative (NC), plus third-harmonic variants (POL-1). The run names a value; CORA writes it; the source's phase rows move to produce it.
-
-- **Flip or rotate it at an absorption edge to make the contrast.** XMCD flips between PC and NC at a magnetic edge and reads the absorption difference. XMLD rotates between two linear angles. Resonant diffraction tunes the polarization and the incident energy together through a resonance. In every case the contrast is the change the polarization causes, so turning the polarization at the edge is the acquisition primitive the whole dichroism family is built on.
-
-- **The conversion stays on the live controller.** The polarization-to-phase kinematics (how a requested polarization becomes a phase-row position) is the axis's partition rule, and it is carried rule-less by default: the live i06 controller owns the conversion, so CORA names the axis and records the move without duplicating a second source of truth for the source geometry (POL-1). Pinning the conversion as a CORA-owned Calibration is deferred until a run needs to scan polarization without that controller in the loop. The same asymmetry the source-axis wiring carries (only the upstream IDU exposes the driven polarization handle in dodal) is an open question (POL-2).
-
-This is the new acquisition primitive expressed entirely by reuse. The polarization axis is a `PseudoAxis` and the source is an `InsertionDevice`; no new device Family appears. What is new is that a run now carries a polarization alongside its energy, and the dichroism Methods drive both.
-
-## Not modelled yet
-
-The intent above is the function view. The concrete recipes that turn it into runnable acquisition are deliberately not written, because writing them for a beamline CORA does not yet drive would be invention rather than record:
-
-- **The concrete dichroism recipes.** The per-edge energy and polarization sequences, the dwell and averaging, the field and temperature setpoints for an in-situ measurement, and the PEEM imaging sequence are calibration the deployment must supply. None of it is invented here.
-
-- **Whether each Method enters the catalog.** Minting a Method is owner-scope. XMCD and resonant scattering reuse 4-ID Methods, and XMLD and photoemission microscopy are new slugs, but all four render pending until the owner decides (TECH-1, PEEM-1). The decision is recorded on the [Model](model.md) page, not made here.
-
-- **The PEEM imaging instrument.** The PEEM electron-optical column and its magnified electron-image detector are deferred (PEEM-1): they are the `ElectronMicroscope` anatomy, distinct from the photon `Camera` and from the energy-analyzing catalog `ElectronAnalyzer`, and they are not coined here because they have no PV in dodal.
-
-- **The i06-1 detectors and flux monitor.** The diffraction scattering detector and the incident-flux / drain-current monitor are absent from dodal and are bound later from outside it, with no detector Family invented in the meantime (DET-1).
-
-For the source and optics that feed these techniques, see the generated source-walk on [the beamline page](source.md). For what the i06 team must confirm before the model can be trusted, see [Open questions](questions.md). The CORA-owned scope decisions (the polarization Calibration, the deferred Methods, the diffractometer Assembly) are recorded on the [Model](model.md#deliberately-not-here-yet) page.
diff --git a/docs/deployments/i10/governance.md b/docs/deployments/i10/governance.md
deleted file mode 100644
index bd22809a08a..00000000000
--- a/docs/deployments/i10/governance.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Governance
-
-*Who would act at i10, and the trust shape that would gate it. Scaffold.*
-
-Governance at i10 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-i10 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited, shared with the soft X-ray and MX siblings (I22, I03, I15-1, I11, I24, I06). i10 adds only its own beamline-bound principals. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
-
-Because i10 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed.
-
-i10 is i06's soft X-ray twin: the two beamlines share a twin-APPLE-II and PGM spine and feed branch endstations. The governance shape is the same on both, and i10 inherits it the same way, so this page reads as the i06 page does, with the hazard classes that are particular to i10 called out below.
-
-## The Enclosures i10 gates
-
-The beamline spans three enclosures, the grouping CORA's Zone would follow (ENC-1):
-
-| Enclosure | PV zone | What it holds |
-| --- | --- | --- |
-| i10-optics | BL10I (optics spine), SR10I (the APPLE-II servo crates) | the PGM, the twin APPLE-II controllers, and the collimating and switching mirrors |
-| i10-rasor | ME01D | the RASOR resonant-scattering and reflectivity endstation, with its branch focusing mirror |
-| i10-1 / I10J | BL10J | the magnet endstation, with its electromagnet and superconducting magnet |
-
-How the two endstations share the source, and whether the three PV zones are three separate hutches, is the beamline team's to confirm (ENC-1). The Zone grouping is named here, not built.
-
-## The safety tier behind the beam
-
-The safety tier behind the beam is the personnel safety system. On a soft X-ray beamline the leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from dodal, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
-
-The hazard classes i10 brings to that envelope are those of a soft X-ray UHV beamline, plus the magnet endstation's own:
-
-- **An intense, variable-polarization beam.** i10 is the fleet's second APPLE-II source, after i06, so the beam's polarization is a driven experiment axis (LH / LV / PC / NC / LA plus third-harmonic variants, with the continuous linear-arbitrary-angle the realization of the LA value within the same axis) rather than a fixed property (POL-1). The radiation hazard is the standard photon-shutter concern the PSS gates (PSS-1); the polarization axis adds optics state, not a new safety tier.
-- **Ultra-high vacuum on the optics and the endstations.** The soft X-ray optics run under UHV (SUP-1). The hazard is the vacuum envelope itself, the same class the Diamond soft X-ray siblings carry.
-- **High magnetic fields at i10-1.** The i10-1 / I10J endstation carries an electromagnet (BL10J-EA-MAGC-01) and a superconducting magnet whose field can be swept (BL10J-EA-SMC-01), both modelled on the graduated catalog Magnet family (MAG-1). A superconducting magnet is a high-field environment, a class of hazard the optics and the RASOR endstation do not carry. CORA does not invent field values or sweep specifics (MAG-1); what it records is that this endstation adds a hazard class the rest of the beamline does not have.
-- **Cryogenics at the sample.** The RASOR sample sits on a cryostat stage (ME01D-MO-CRYO-01) read by a Lakeshore 340 (ME01D-EA-TCTRL-01), and the i10-1 magnet endstation folds a cryostat low-temperature environment into its stages, read by a Lakeshore 336 (BL10J-EA-TCTRL-41) (TEMP-1). The hazard is the cryogen and low-temperature envelope at the sample, the same class the soft X-ray siblings carry, here paired with the magnet field at i10-1.
-
-Where these become Clearance-gated operation (for example any unattended or hazardous run, or a superconducting-magnet field sweep) is the shape the Diamond siblings reserve, not instantiated here.
-
-## What is deliberately not modelled
-
-- **The PSS permit signals and shutters (PSS-1).** Absent from dodal, carried pending, not invented.
-- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
-- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The RASOR analyzer arm binds the catalog `PolarizationAnalyzer` (graduated, POL-2); the analyzer-crystal spec is an equipment, not governance, detail. The graduated `Magnet` family (the magnet devices, MAG-1) is likewise equipment modelling; they live on [Model](model.md). The full delete-on-answer queue is on [Open questions](questions.md).
diff --git a/docs/deployments/i10/model.md b/docs/deployments/i10/model.md
deleted file mode 100644
index aa057baa195..00000000000
--- a/docs/deployments/i10/model.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's i10 content lives, why this second APPLE-II deployment coins no new family and decides two loose families' second sighting, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at i10 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes i10 new
-
-i10 is the fleet's second APPLE-II (variable-polarization) source, after i06, and it is i06's soft X-ray twin: the same shared spine of twin APPLE-II undulators feeding a plane-grating monochromator and two branch endstations. What i10 adds is the science those endstations do with the polarization: resonant soft X-ray scattering and reflectivity on the RASOR diffractometer (with a polarization-analysis arm that resolves the polarization of the scattered beam), and X-ray magnetic dichroism with the sample in an applied magnetic field at the i10-1 endstation.
-
-For the modelling, i10's significance is that it brings two device families that were loose at a single beamline (4-ID) to a second sighting: the polarization analyzer and the sample-environment magnet. That second independent deployment was a step toward the rule-of-three; both families have since completed it and graduated into the catalog (PolarizationAnalyzer across 4-ID / i10 / ID32 / P09, Magnet across 4-ID / i10-1 / ID32), so i10's analyzer arm and magnets bind their catalog Families. i10 coins no new family.
-
-## No new families
-
-i10 coins no new Family and changes nothing in the catalog.
-
-- **The polarization decisions follow the merged i06 precedent.** The two APPLE-II undulators bind the catalog `InsertionDevice` (the phase rows, the energy-to-gap polynomial, and the controller are per-Asset settings and the bound Model). The polarization is a `PseudoAxis` Asset, a sibling of the incident-energy axis over the same source; the Pol value domain (LH / LV / PC / NC / LA plus third-harmonic variants) is the axis's value set, and the controller's polarization-to-phase conversion is its partition rule, carried rule-less (`POL-1`). i10's one addition over i06 is the continuous linear-arbitrary-angle: it is the continuous realization of the LA value within the same polarization axis, not a second axis, since the angle is meaningful only as a refinement of LA.
-- **The RASOR sample circles bind `Goniometer`, with a reciprocal-space `PseudoAxis`** (the 4-ID / 8-ID / i06-1 diffractometer pattern; the Assembly is named, not built, `DIFF-1`).
-- **The rest reuse existing families:** the PGM binds `GratingMonochromator`; the collimating, switching, and focusing mirrors bind `Mirror`; the slits bind `Slit`; the pinhole binds `Aperture`; the sample and magnet stages bind `LinearStage`; the Lakeshore controllers bind `TemperatureController`; and the counting chains bind `FluxMonitor`. The machine state reuses the loose `StorageRing`.
-
-## Loose families at a second sighting
-
-Two families that were used only at 4-ID reach a further sighting at i10, and both have since graduated. The promotion guard (`PROMOTION_THRESHOLD = 2`) makes a loose family used by two or more deployments require a recorded hold-or-graduate decision: the signal is mechanical, the decision stays human. `Magnet` has graduated: i10-1 was one of the three consumers (with 4-ID and ESRF ID32) whose rule-of-three earned it into the catalog, so i10's magnets now bind the graduated catalog `Magnet` Family (it presents the `Regulator` Role, the field a settable process variable). `PolarizationAnalyzer` has also graduated to a catalog Family (earned across 4-ID / i10 / ID32 / P09, presenting Positioner), so i10's RASOR arm now binds the catalog Family.
-
-| Loose family | Sightings | i10 binding | Decision |
-| --- | --- | --- | --- |
-| `PolarizationAnalyzer` | 4-ID, i10, ID32, P09 | the RASOR polarization-analysis arm (the POLAN stage) | **graduated** (`POL-2`): catalog Family across 4-ID / i10 / ID32 / P09, presents Positioner; dodal exposes the analyzer arm's motors only (the analyzer crystal is implicit hardware), so CORA models the role on the real motorized arm and binds the catalog Family |
-| `Magnet` | 4-ID, i10 (i10-1), ID32 | the i10-1 electromagnet and the superconducting field-sweep magnet | **graduated** (`MAG-1`): i10-1 was one of the three consumers (4-ID + i10-1 + ID32) whose rule-of-three earned it; both magnet devices are one Family, the field-sweep capability is a per-Asset bound-Model affordance, not a split (the `InsertionDevice` / `TemperatureController` precedent); presents the `Regulator` Role (`MAG-1` now covers only the per-Asset field detail) |
-
-The decision to bind the RASOR PaStage to the catalog `PolarizationAnalyzer` Family (rather than to a plain detector-arm `RotaryStage` with the analyzer as a setting) is a deliberate one: RASOR's defining role is polarization analysis (the PV root is `POLAN`), and CORA models that role on the real arm rather than hiding it in a note. The absence of an analyzer-crystal signal in dodal is an absence in the data, not proof the role is absent; the analyzer-crystal spec stays a per-Asset detail to confirm (`POL-2`).
-
-## Deliberately not here yet
-
-- **No area detector; the science detector is a point counter (`DET-1`).** Neither endstation has an area detector in dodal. Detection is point and current-integrating: the scattered-beam point detector, the incident-flux monitor, and the fluorescence and drain-current / total-electron-yield channels are current-amplifier-plus-scaler chains, which bind `FluxMonitor`. Whether scattered-beam point-counting eventually earns its own Sensor Family is `DET-1`; if a future i10 area detector appears, the science detector migrates.
-- **The diffractometer Assembly (`DIFF-1`) and the reciprocal-space rule (`DIFF-2`).** Named, not built, exactly as 4-ID, 8-ID, and i06-1 deferred theirs.
-- **The polarization Calibration (`POL-1`).** Pinning the polarization-to-phase and the linear-arbitrary-angle conversion as a CORA-owned Calibration is deferred; it is only needed if CORA must scan polarization without the i10 controller in the loop.
-- **The resonant-scattering / reflectivity / XMCD / XMLD Methods.** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending. Resonant scattering and XMCD share the 4-ID Methods, XMLD shares the i06 slug, and reflectivity is a new pending slug (`TECH-1`).
-- **The upstream diagnostics and simulated devices.** The diagnostic screens (d1-d7 fluorescent screens and webcams) and the simulated devices are not modelled in this cut; no `test_i10_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i10/notes.md b/docs/deployments/i10/notes.md
new file mode 100644
index 00000000000..fcdd0c7fef0
--- /dev/null
+++ b/docs/deployments/i10/notes.md
@@ -0,0 +1,225 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of i10 is designed to do, as intent. Scaffold.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i10 (BLADE) is i06's soft X-ray twin: the fleet's second APPLE-II source, sharing the twin-APPLE-II and PGM spine, feeding two endstations that study magnetic materials. Its techniques sit in the same family i06 already named, polarization-driven contrast, but i10 reads that contrast two ways i06 does not: it resolves the polarization of the scattered beam (the RASOR analyzer arm), and it makes the contrast under an applied magnetic field at low temperature (the i10-1 magnets).
+
+So i10's modelling story is mostly reuse. The polarization acquisition axis already exists from i06, and three of i10's four Methods are already pending in CORA's catalog. What i10 adds on top is two affordances, polarization analysis and applied-field dichroism, expressed against families CORA already carries rather than new recipes over the spine. The function view below describes what each technique does, while the catalog vocabulary and the deferred decisions are carried as questions.
+
+### The four techniques
+
+i10 carries four techniques, all pending in CORA's catalog. Three reuse Methods already pending from earlier soft X-ray deployments; one is a new pending slug.
+
+| Technique | CORA Method | Contrast it reads | Status in CORA |
+| --- | --- | --- | --- |
+| Resonant soft X-ray scattering | `resonant_scattering` | a diffraction peak whose intensity tracks magnetic / charge / orbital order as the polarization and energy are tuned through resonance | shares the 4-ID `resonant_scattering` Method, pending (TECH-1) |
+| Soft X-ray reflectivity | `reflectivity` | the specularly reflected intensity versus angle and energy, sensitive to depth structure and magnetic profile (the R in RASOR) | new pending slug `reflectivity` (TECH-1) |
+| X-ray magnetic circular dichroism (XMCD) | `xmcd` | absorption difference between circular-positive and circular-negative polarization at a magnetic edge, here in an applied field | shares the 4-ID `xmcd` Method, pending (TECH-1) |
+| X-ray magnetic linear dichroism (XMLD) | `xmld` | absorption difference between two linear-polarization angles at a magnetic edge, here in an applied field | shares the i06 `xmld` slug, pending (TECH-1) |
+
+Each technique adapts to i10 as a Site Practice on the [Diamond Site](../diamond/index.md#the-techniques-adapted-here): `I10_resonant_scattering_practice`, `I10_reflectivity_practice`, `I10_xmcd_practice`, and `I10_xmld_practice`, all pending. The Practices render unlinked until the owner decides whether each Method enters the catalog (TECH-1).
+
+A few points of intent shape the four:
+
+- **The four split across two endstations by what reads the contrast.** Resonant scattering and reflectivity read it at the RASOR endstation: the contrast is the intensity of a scattered or reflected beam on the diffractometer, observed through point and current-integrating detection (DET-1). XMCD and XMLD read it at the i10-1 / I10J magnet endstation: the contrast is an absorption difference observed as total-electron-yield, fluorescence, or diode signal while a magnetic field is applied to the sample (DET-1, MAG-1). Underneath all four is the same shared move that i06 named: set or turn the polarization at an absorption edge and observe the difference.
+
+- **Three techniques reuse existing Methods; one is new.** Resonant scattering and XMCD are the same Methods CORA already carries pending from the 4-ID deployment, and XMLD reuses the i06 slug, so for those three i10 is a second (or third) consumer rather than a coiner: the second consumer is the graduation watch-item. Reflectivity has no existing Method that fits, so it is a new pending slug. Whether any of the four enters CORA's catalog as a Capability is an owner decision (TECH-1), recorded on the [Model](#model) page, not made here.
+
+- **Resonant scattering and reflectivity reuse the RASOR geometry, and the science detector is a flux monitor.** The RASOR diffractometer (the two-theta scattering arm with sample theta, chi, chamber X, and alpha) is modelled now as a `Goniometer` (DIFF-1), with a reciprocal-space `PseudoAxis` over it (DIFF-2). There is no area detector at RASOR, so the scattered-beam point detector, the incident-flux monitor, the fluorescence channel, and the drain-current / total-electron-yield channel all bind the catalog `FluxMonitor` family through their current amplifiers (DET-1). The geometry that aims and reads the beam is in the model; the recipe that sequences a scan or a reflectivity curve is calibration the deployment supplies later.
+
+- **XMCD and XMLD here are field-and-temperature techniques.** At i10-1 the contrast is made not just by turning the polarization but by applying a magnetic field with the sample held cold. The magnets are modelled (MAG-1), the cryostat stage and its temperature controller are modelled (TEMP-1), and the i10-1 point detection is again a `FluxMonitor` (DET-1). The applied-field affordance is what distinguishes i10's XMCD / XMLD from i06's, and it is the second of the two things i10 adds (see below).
+
+### The polarization axis, reused from i06
+
+The polarization acquisition axis is not new with i10. i06 brought it to the fleet first: an APPLE-II undulator drives its magnetic phase rows to choose the X-ray polarization, not just set a gap, so a run can ask for a polarization the way it asks for an energy. i10 is the fleet's second APPLE-II source and reuses that axis unchanged.
+
+i10 models it as a [`PseudoAxis`](../../catalog/families.md) over the twin-APPLE-II phase rows, a sibling of the incident-energy pseudo-axis over the same source. The shape is:
+
+- **Set the polarization on the APPLE-II.** The axis's value domain is the polarization set the source can produce: linear horizontal (LH), linear vertical (LV), circular positive (PC), circular negative (NC), and linear at an arbitrary angle (LA), plus third-harmonic variants (POL-1). The continuous linear-arbitrary-angle is the continuous realization of the LA value within this same axis, not a second axis and not a new family. The run names a value; CORA writes it; the source's phase rows move to produce it.
+
+- **Turn it at an absorption edge to make the contrast.** XMCD flips between PC and NC at a magnetic edge and reads the absorption difference. XMLD rotates between two linear angles. Resonant scattering tunes the polarization and the incident energy together through a resonance. In every case the contrast is the change the polarization causes, so turning the polarization at the edge is the acquisition primitive the whole family is built on.
+
+- **The conversion stays on the live controller.** The polarization-to-phase kinematics is carried rule-less by default: the live i10 controller owns the conversion, so CORA names the axis and records the move without duplicating a second source of truth for the source geometry (POL-1). Both undulators are driven sources, and whether the polarization handle is wired over one axis or two is an open question (ENERGY-1).
+
+So far this is i06's primitive expressed by reuse: the polarization axis is a `PseudoAxis`, the source is an `InsertionDevice`, and no new device Family appears. i10 then adds two things i06 does not carry.
+
+#### What i10 adds: polarization analysis of the scattered beam
+
+RASOR does not only set the incident polarization; it can resolve the polarization of the scattered beam. The motorized analyzer arm (the PaStage / POLAN arm, with its analyzer two-theta and theta, py and pz, and eta motors) selects a scattered-polarization channel, which is what lets resonant scattering separate the magnetic and charge contributions to a peak rather than read only its total intensity. This is the analysis half of polarization: i06 turns it, i10 also reads it back.
+
+CORA models that arm as the catalog `PolarizationAnalyzer` Family. This is a deliberate modelling choice: dodal exposes only the arm's motors, and the analyzer crystal is implicit hardware, but RASOR's defining polarization-analysis role lives on that real motorized arm, so CORA models the arm rather than hiding the role. The analyzer crystal specifics are not invented (POL-2). The Family has graduated across 4-ID / i10 / ID32 / P09, presenting Positioner; the analyzer-crystal spec stays a per-Asset detail to confirm (POL-2).
+
+#### What i10 adds: applied-field dichroism
+
+The i10-1 / I10J endstation makes the dichroic contrast under an applied magnetic field, with the sample held at low temperature. Two magnet devices serve it: a set-and-read electromagnet and a superconducting magnet whose field can be swept (a Flyable affordance). CORA models both as the single graduated `Magnet` family: they are one family, and the field sweep is a per-Asset affordance, not a split (MAG-1). i10-1 was the `Magnet` family's second sighting after 4-ID, and with the later ESRF ID32 magnet it reached a rule-of-three and graduated into the catalog (MAG-1). The field values and the sweep specifics are not invented (MAG-1).
+
+The applied field is what makes i10's XMCD / XMLD different from i06's: i06 reads dichroism from the polarization alone, while i10 reads it with a field applied and the sample cold. The cryostat low-temperature stage folds into the catalog `LinearStage`, and the magnet temperature is held by a catalog `TemperatureController` (TEMP-1). As with the polarization axis, no new device Family is coined for either addition: the analyzer binds the graduated catalog `PolarizationAnalyzer`, and the magnets are the graduated `Magnet` family, whose rule-of-three i10-1 helped complete.
+
+### Not modelled yet
+
+The intent above is the function view. The concrete recipes that turn it into runnable acquisition are deliberately not written, because writing them for a beamline CORA does not yet drive would be invention rather than record:
+
+- **The concrete recipes.** The per-edge energy and polarization sequences, the reflectivity angle and energy scans, the polarization-analysis channel selections, the field and temperature setpoints for an in-situ measurement, and the dwell and averaging are all calibration the deployment must supply. None of it is invented here. No energies, angles, fields, or resolutions are stated.
+
+- **Whether each Method enters the catalog.** Minting a Method is owner-scope. Resonant scattering and XMCD reuse 4-ID Methods, XMLD reuses the i06 slug, and reflectivity is a new slug, but all four render pending until the owner decides (TECH-1). The decision is recorded on the [Model](#model) page, not made here.
+
+- **The graduated analyzer and magnet families.** `PolarizationAnalyzer` has graduated to a catalog Family across 4-ID / i10 / ID32 / P09 (POL-2), so i10's analyzer arm binds the catalog Family; the analyzer-crystal spec stays uninvented as a per-Asset detail. The `Magnet` family has also graduated (i10-1 was one of its three consumers with 4-ID and ID32), so i10's magnets bind the catalog Family; only the per-Asset magnet field values stay uninvented (MAG-1).
+
+- **The science detectors.** Neither endstation has an area detector. The RASOR and i10-1 point and current-integrating channels bind the catalog `FluxMonitor` through their current amplifiers (DET-1); no detector Family is invented in the meantime.
+
+For the source and optics that feed these techniques, see the generated source-walk on [the beamline page](source.md). For what the i10 team must confirm before the model can be trusted, see [Open questions](#open-questions). The CORA-owned scope decisions (the deferred Methods, the held families, the diffractometer Assembly) are recorded on the [Model](#deliberately-not-here-yet) page.
+
+## Governance
+
+*Who would act at i10, and the trust shape that would gate it. Scaffold.*
+
+Governance at i10 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+i10 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited, shared with the soft X-ray and MX siblings (I22, I03, I15-1, I11, I24, I06). i10 adds only its own beamline-bound principals. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
+
+Because i10 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed.
+
+i10 is i06's soft X-ray twin: the two beamlines share a twin-APPLE-II and PGM spine and feed branch endstations. The governance shape is the same on both, and i10 inherits it the same way, so this page reads as the i06 page does, with the hazard classes that are particular to i10 called out below.
+
+### The Enclosures i10 gates
+
+The beamline spans three enclosures, the grouping CORA's Zone would follow (ENC-1):
+
+| Enclosure | PV zone | What it holds |
+| --- | --- | --- |
+| i10-optics | BL10I (optics spine), SR10I (the APPLE-II servo crates) | the PGM, the twin APPLE-II controllers, and the collimating and switching mirrors |
+| i10-rasor | ME01D | the RASOR resonant-scattering and reflectivity endstation, with its branch focusing mirror |
+| i10-1 / I10J | BL10J | the magnet endstation, with its electromagnet and superconducting magnet |
+
+How the two endstations share the source, and whether the three PV zones are three separate hutches, is the beamline team's to confirm (ENC-1). The Zone grouping is named here, not built.
+
+### The safety tier behind the beam
+
+The safety tier behind the beam is the personnel safety system. On a soft X-ray beamline the leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from dodal, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
+
+The hazard classes i10 brings to that envelope are those of a soft X-ray UHV beamline, plus the magnet endstation's own:
+
+- **An intense, variable-polarization beam.** i10 is the fleet's second APPLE-II source, after i06, so the beam's polarization is a driven experiment axis (LH / LV / PC / NC / LA plus third-harmonic variants, with the continuous linear-arbitrary-angle the realization of the LA value within the same axis) rather than a fixed property (POL-1). The radiation hazard is the standard photon-shutter concern the PSS gates (PSS-1); the polarization axis adds optics state, not a new safety tier.
+- **Ultra-high vacuum on the optics and the endstations.** The soft X-ray optics run under UHV (SUP-1). The hazard is the vacuum envelope itself, the same class the Diamond soft X-ray siblings carry.
+- **High magnetic fields at i10-1.** The i10-1 / I10J endstation carries an electromagnet (BL10J-EA-MAGC-01) and a superconducting magnet whose field can be swept (BL10J-EA-SMC-01), both modelled on the graduated catalog Magnet family (MAG-1). A superconducting magnet is a high-field environment, a class of hazard the optics and the RASOR endstation do not carry. CORA does not invent field values or sweep specifics (MAG-1); what it records is that this endstation adds a hazard class the rest of the beamline does not have.
+- **Cryogenics at the sample.** The RASOR sample sits on a cryostat stage (ME01D-MO-CRYO-01) read by a Lakeshore 340 (ME01D-EA-TCTRL-01), and the i10-1 magnet endstation folds a cryostat low-temperature environment into its stages, read by a Lakeshore 336 (BL10J-EA-TCTRL-41) (TEMP-1). The hazard is the cryogen and low-temperature envelope at the sample, the same class the soft X-ray siblings carry, here paired with the magnet field at i10-1.
+
+Where these become Clearance-gated operation (for example any unattended or hazardous run, or a superconducting-magnet field sweep) is the shape the Diamond siblings reserve, not instantiated here.
+
+### What is deliberately not modelled
+
+- **The PSS permit signals and shutters (PSS-1).** Absent from dodal, carried pending, not invented.
+- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
+- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The RASOR analyzer arm binds the catalog `PolarizationAnalyzer` (graduated, POL-2); the analyzer-crystal spec is an equipment, not governance, detail. The graduated `Magnet` family (the magnet devices, MAG-1) is likewise equipment modelling; they live on [Model](#model). The full delete-on-answer queue is on [Open questions](#open-questions).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's i10 content lives, why this second APPLE-II deployment coins no new family and decides two loose families' second sighting, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at i10 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes i10 new
+
+i10 is the fleet's second APPLE-II (variable-polarization) source, after i06, and it is i06's soft X-ray twin: the same shared spine of twin APPLE-II undulators feeding a plane-grating monochromator and two branch endstations. What i10 adds is the science those endstations do with the polarization: resonant soft X-ray scattering and reflectivity on the RASOR diffractometer (with a polarization-analysis arm that resolves the polarization of the scattered beam), and X-ray magnetic dichroism with the sample in an applied magnetic field at the i10-1 endstation.
+
+For the modelling, i10's significance is that it brings two device families that were loose at a single beamline (4-ID) to a second sighting: the polarization analyzer and the sample-environment magnet. That second independent deployment was a step toward the rule-of-three; both families have since completed it and graduated into the catalog (PolarizationAnalyzer across 4-ID / i10 / ID32 / P09, Magnet across 4-ID / i10-1 / ID32), so i10's analyzer arm and magnets bind their catalog Families. i10 coins no new family.
+
+### No new families
+
+i10 coins no new Family and changes nothing in the catalog.
+
+- **The polarization decisions follow the merged i06 precedent.** The two APPLE-II undulators bind the catalog `InsertionDevice` (the phase rows, the energy-to-gap polynomial, and the controller are per-Asset settings and the bound Model). The polarization is a `PseudoAxis` Asset, a sibling of the incident-energy axis over the same source; the Pol value domain (LH / LV / PC / NC / LA plus third-harmonic variants) is the axis's value set, and the controller's polarization-to-phase conversion is its partition rule, carried rule-less (`POL-1`). i10's one addition over i06 is the continuous linear-arbitrary-angle: it is the continuous realization of the LA value within the same polarization axis, not a second axis, since the angle is meaningful only as a refinement of LA.
+- **The RASOR sample circles bind `Goniometer`, with a reciprocal-space `PseudoAxis`** (the 4-ID / 8-ID / i06-1 diffractometer pattern; the Assembly is named, not built, `DIFF-1`).
+- **The rest reuse existing families:** the PGM binds `GratingMonochromator`; the collimating, switching, and focusing mirrors bind `Mirror`; the slits bind `Slit`; the pinhole binds `Aperture`; the sample and magnet stages bind `LinearStage`; the Lakeshore controllers bind `TemperatureController`; and the counting chains bind `FluxMonitor`. The machine state reuses the loose `StorageRing`.
+
+### Loose families at a second sighting
+
+Two families that were used only at 4-ID reach a further sighting at i10, and both have since graduated. The promotion guard (`PROMOTION_THRESHOLD = 2`) makes a loose family used by two or more deployments require a recorded hold-or-graduate decision: the signal is mechanical, the decision stays human. `Magnet` has graduated: i10-1 was one of the three consumers (with 4-ID and ESRF ID32) whose rule-of-three earned it into the catalog, so i10's magnets now bind the graduated catalog `Magnet` Family (it presents the `Regulator` Role, the field a settable process variable). `PolarizationAnalyzer` has also graduated to a catalog Family (earned across 4-ID / i10 / ID32 / P09, presenting Positioner), so i10's RASOR arm now binds the catalog Family.
+
+| Loose family | Sightings | i10 binding | Decision |
+| --- | --- | --- | --- |
+| `PolarizationAnalyzer` | 4-ID, i10, ID32, P09 | the RASOR polarization-analysis arm (the POLAN stage) | **graduated** (`POL-2`): catalog Family across 4-ID / i10 / ID32 / P09, presents Positioner; dodal exposes the analyzer arm's motors only (the analyzer crystal is implicit hardware), so CORA models the role on the real motorized arm and binds the catalog Family |
+| `Magnet` | 4-ID, i10 (i10-1), ID32 | the i10-1 electromagnet and the superconducting field-sweep magnet | **graduated** (`MAG-1`): i10-1 was one of the three consumers (4-ID + i10-1 + ID32) whose rule-of-three earned it; both magnet devices are one Family, the field-sweep capability is a per-Asset bound-Model affordance, not a split (the `InsertionDevice` / `TemperatureController` precedent); presents the `Regulator` Role (`MAG-1` now covers only the per-Asset field detail) |
+
+The decision to bind the RASOR PaStage to the catalog `PolarizationAnalyzer` Family (rather than to a plain detector-arm `RotaryStage` with the analyzer as a setting) is a deliberate one: RASOR's defining role is polarization analysis (the PV root is `POLAN`), and CORA models that role on the real arm rather than hiding it in a note. The absence of an analyzer-crystal signal in dodal is an absence in the data, not proof the role is absent; the analyzer-crystal spec stays a per-Asset detail to confirm (`POL-2`).
+
+### Deliberately not here yet
+
+- **No area detector; the science detector is a point counter (`DET-1`).** Neither endstation has an area detector in dodal. Detection is point and current-integrating: the scattered-beam point detector, the incident-flux monitor, and the fluorescence and drain-current / total-electron-yield channels are current-amplifier-plus-scaler chains, which bind `FluxMonitor`. Whether scattered-beam point-counting eventually earns its own Sensor Family is `DET-1`; if a future i10 area detector appears, the science detector migrates.
+- **The diffractometer Assembly (`DIFF-1`) and the reciprocal-space rule (`DIFF-2`).** Named, not built, exactly as 4-ID, 8-ID, and i06-1 deferred theirs.
+- **The polarization Calibration (`POL-1`).** Pinning the polarization-to-phase and the linear-arbitrary-angle conversion as a CORA-owned Calibration is deferred; it is only needed if CORA must scan polarization without the i10 controller in the loop.
+- **The resonant-scattering / reflectivity / XMCD / XMLD Methods.** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending. Resonant scattering and XMCD share the 4-ID Methods, XMLD shares the i06 slug, and reflectivity is a new pending slug (`TECH-1`).
+- **The upstream diagnostics and simulated devices.** The diagnostic screens (d1-d7 fluorescent screens and webcams) and the simulated devices are not modelled in this cut; no `test_i10_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the i10 team to confirm before the model can be trusted.*
+
+i10 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i10*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the PV zones BL10I (optics spine), ME01D (RASOR), and BL10J (i10-1) three separate hutches, and how do the two endstations share the source? | Three enclosures: a shared `i10-optics` zone and the `i10-rasor` and `i10-1` experiment hutches. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The two APPLE-II undulator periods, the gap range, and how the downstream (IDD) and upstream (IDU) devices feed the branches. | Two `InsertionDevice` Assets; period carried pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state i10 reads (current, energy, fill). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The plane-grating monochromator gratings, the cff constant, and the incident-energy range and partition rule. | A soft X-ray PGM bound to `GratingMonochromator`; gratings and range pending. | The monochromator and incident-energy Assets. |
+
+### Beam axes: energy and polarization
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENERGY-1 | Nice-to-have | Both APPLE-IIs are driven sources (energy_dd over IDD, energy_ud over IDU); should CORA carry one incident-energy axis or two, and how do they map to the branches? | One `BeamEnergy` `PseudoAxis` over the PGM and the APPLE-II gap; the two-source wiring pending. | The incident-energy Asset wiring. |
+| POL-1 | Blocks-go-live | The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants and the continuous linear-arbitrary-angle) and the polarization-to-phase conversion: pin it as a CORA Calibration, or run the axis rule-less and let the live controller own it? | A `PseudoAxis` over the APPLE-II phase rows; the linear-arbitrary-angle is the continuous realization of LA in the same axis; rule-less by default. | The polarization-axis modelling. |
+
+### RASOR endstation (i10-rasor)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The RASOR diffractometer circle roles (two-theta scattering arm, sample theta / chi, chamber X, alpha) and whether they compose an Assembly. | A `Goniometer` for the sample circles; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the RASOR circles (the inverse-kinematics rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / i06-1. | The reciprocal-space Asset. |
+| POL-2 | Blocks-go-live | Does RASOR run genuine polarization analysis on the PaStage (the POLAN arm), confirming the analyzer-crystal spec on the catalog `PolarizationAnalyzer` Family? | The PaStage binds the catalog `PolarizationAnalyzer` (graduated across 4-ID / i10 / ID32 / P09); dodal exposes the motors only, the analyzer crystal is implicit, so the crystal spec stays a per-Asset detail to confirm. | The analyzer-crystal spec; the graduation is recorded on [Model](#loose-families-at-a-second-sighting). |
+| STAGE-1 | Nice-to-have | Whether the cryostat sample stage warrants a `Manipulator` rather than `LinearStage`, and whether the pinhole is an `Aperture` or a plain stage. | The sample stage bound to `LinearStage` (plain in-air translation); the pinhole bound to `Aperture`. | The sample-stage and pinhole Families. |
+| TEMP-1 | Nice-to-have | The Lakeshore 340 (RASOR) and Lakeshore 336 (i10-1) temperature ranges and channel assignment. | Two `TemperatureController` Assets presenting the `Regulator` Role; ranges pending. | The temperature-control modelling. |
+| DET-1 | Blocks-go-live | The RASOR and i10-1 detection: no area detector exists in dodal, only the current-amplifier / scaler point-counting chains (monitor, scattered-beam point detector, fluorescence, drain-current / total-electron-yield). Is the point detector best a `FluxMonitor`, or does scattered-beam point-counting earn its own Sensor Family? | The scattered-beam point detector and the monitor / fluorescence / yield channels bind `FluxMonitor`; no detector Family invented. | The detector modelling. |
+
+### i10-1 magnet endstation (i10-1)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MAG-1 | Blocks-go-live | The i10-1 electromagnet and superconducting field-sweep magnet (field ranges, the sweep mode), and the low-temperature environment. | The two magnets bind the graduated catalog `Magnet` Family (one Family, the sweep is a per-Asset affordance); i10-1 was one of its three consumers with 4-ID and ID32; the cryostat folds into the stage. | The per-Asset magnet field / control detail; the family graduation is settled (see [Model](#loose-families-at-a-second-sighting)). |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the soft X-ray optics and the UHV endstations) and the cooling supply. | Photon beam, cooling water, and ultra-high vacuum on the optics and endstations. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do the resonant-scattering, reflectivity, and magnetic-dichroism techniques (RSXS, soft X-ray reflectivity, XMCD, XMLD) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; resonant scattering and XMCD share the 4-ID Methods, XMLD shares the i06 slug, reflectivity is a new pending slug; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/i10/questions.md b/docs/deployments/i10/questions.md
deleted file mode 100644
index 6d6430581ef..00000000000
--- a/docs/deployments/i10/questions.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Open questions
-
-*What CORA needs the i10 team to confirm before the model can be trusted.*
-
-i10 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i10*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the PV zones BL10I (optics spine), ME01D (RASOR), and BL10J (i10-1) three separate hutches, and how do the two endstations share the source? | Three enclosures: a shared `i10-optics` zone and the `i10-rasor` and `i10-1` experiment hutches. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The two APPLE-II undulator periods, the gap range, and how the downstream (IDD) and upstream (IDU) devices feed the branches. | Two `InsertionDevice` Assets; period carried pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state i10 reads (current, energy, fill). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The plane-grating monochromator gratings, the cff constant, and the incident-energy range and partition rule. | A soft X-ray PGM bound to `GratingMonochromator`; gratings and range pending. | The monochromator and incident-energy Assets. |
-
-## Beam axes: energy and polarization
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENERGY-1 | Nice-to-have | Both APPLE-IIs are driven sources (energy_dd over IDD, energy_ud over IDU); should CORA carry one incident-energy axis or two, and how do they map to the branches? | One `BeamEnergy` `PseudoAxis` over the PGM and the APPLE-II gap; the two-source wiring pending. | The incident-energy Asset wiring. |
-| POL-1 | Blocks-go-live | The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants and the continuous linear-arbitrary-angle) and the polarization-to-phase conversion: pin it as a CORA Calibration, or run the axis rule-less and let the live controller own it? | A `PseudoAxis` over the APPLE-II phase rows; the linear-arbitrary-angle is the continuous realization of LA in the same axis; rule-less by default. | The polarization-axis modelling. |
-
-## RASOR endstation (i10-rasor)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The RASOR diffractometer circle roles (two-theta scattering arm, sample theta / chi, chamber X, alpha) and whether they compose an Assembly. | A `Goniometer` for the sample circles; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the RASOR circles (the inverse-kinematics rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / i06-1. | The reciprocal-space Asset. |
-| POL-2 | Blocks-go-live | Does RASOR run genuine polarization analysis on the PaStage (the POLAN arm), confirming the analyzer-crystal spec on the catalog `PolarizationAnalyzer` Family? | The PaStage binds the catalog `PolarizationAnalyzer` (graduated across 4-ID / i10 / ID32 / P09); dodal exposes the motors only, the analyzer crystal is implicit, so the crystal spec stays a per-Asset detail to confirm. | The analyzer-crystal spec; the graduation is recorded on [Model](model.md#loose-families-at-a-second-sighting). |
-| STAGE-1 | Nice-to-have | Whether the cryostat sample stage warrants a `Manipulator` rather than `LinearStage`, and whether the pinhole is an `Aperture` or a plain stage. | The sample stage bound to `LinearStage` (plain in-air translation); the pinhole bound to `Aperture`. | The sample-stage and pinhole Families. |
-| TEMP-1 | Nice-to-have | The Lakeshore 340 (RASOR) and Lakeshore 336 (i10-1) temperature ranges and channel assignment. | Two `TemperatureController` Assets presenting the `Regulator` Role; ranges pending. | The temperature-control modelling. |
-| DET-1 | Blocks-go-live | The RASOR and i10-1 detection: no area detector exists in dodal, only the current-amplifier / scaler point-counting chains (monitor, scattered-beam point detector, fluorescence, drain-current / total-electron-yield). Is the point detector best a `FluxMonitor`, or does scattered-beam point-counting earn its own Sensor Family? | The scattered-beam point detector and the monitor / fluorescence / yield channels bind `FluxMonitor`; no detector Family invented. | The detector modelling. |
-
-## i10-1 magnet endstation (i10-1)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MAG-1 | Blocks-go-live | The i10-1 electromagnet and superconducting field-sweep magnet (field ranges, the sweep mode), and the low-temperature environment. | The two magnets bind the graduated catalog `Magnet` Family (one Family, the sweep is a per-Asset affordance); i10-1 was one of its three consumers with 4-ID and ID32; the cryostat folds into the stage. | The per-Asset magnet field / control detail; the family graduation is settled (see [Model](model.md#loose-families-at-a-second-sighting)). |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the soft X-ray optics and the UHV endstations) and the cooling supply. | Photon beam, cooling water, and ultra-high vacuum on the optics and endstations. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do the resonant-scattering, reflectivity, and magnetic-dichroism techniques (RSXS, soft X-ray reflectivity, XMCD, XMLD) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; resonant scattering and XMCD share the 4-ID Methods, XMLD shares the i06 slug, reflectivity is a new pending slug; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/i10/techniques.md b/docs/deployments/i10/techniques.md
deleted file mode 100644
index 3ff0099da1b..00000000000
--- a/docs/deployments/i10/techniques.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# Techniques
-
-*What the modelled part of i10 is designed to do, as intent. Scaffold.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i10 (BLADE) is i06's soft X-ray twin: the fleet's second APPLE-II source, sharing the twin-APPLE-II and PGM spine, feeding two endstations that study magnetic materials. Its techniques sit in the same family i06 already named, polarization-driven contrast, but i10 reads that contrast two ways i06 does not: it resolves the polarization of the scattered beam (the RASOR analyzer arm), and it makes the contrast under an applied magnetic field at low temperature (the i10-1 magnets).
-
-So i10's modelling story is mostly reuse. The polarization acquisition axis already exists from i06, and three of i10's four Methods are already pending in CORA's catalog. What i10 adds on top is two affordances, polarization analysis and applied-field dichroism, expressed against families CORA already carries rather than new recipes over the spine. The function view below describes what each technique does, while the catalog vocabulary and the deferred decisions are carried as questions.
-
-## The four techniques
-
-i10 carries four techniques, all pending in CORA's catalog. Three reuse Methods already pending from earlier soft X-ray deployments; one is a new pending slug.
-
-| Technique | CORA Method | Contrast it reads | Status in CORA |
-| --- | --- | --- | --- |
-| Resonant soft X-ray scattering | `resonant_scattering` | a diffraction peak whose intensity tracks magnetic / charge / orbital order as the polarization and energy are tuned through resonance | shares the 4-ID `resonant_scattering` Method, pending (TECH-1) |
-| Soft X-ray reflectivity | `reflectivity` | the specularly reflected intensity versus angle and energy, sensitive to depth structure and magnetic profile (the R in RASOR) | new pending slug `reflectivity` (TECH-1) |
-| X-ray magnetic circular dichroism (XMCD) | `xmcd` | absorption difference between circular-positive and circular-negative polarization at a magnetic edge, here in an applied field | shares the 4-ID `xmcd` Method, pending (TECH-1) |
-| X-ray magnetic linear dichroism (XMLD) | `xmld` | absorption difference between two linear-polarization angles at a magnetic edge, here in an applied field | shares the i06 `xmld` slug, pending (TECH-1) |
-
-Each technique adapts to i10 as a Site Practice on the [Diamond Site](../diamond/index.md#the-techniques-adapted-here): `I10_resonant_scattering_practice`, `I10_reflectivity_practice`, `I10_xmcd_practice`, and `I10_xmld_practice`, all pending. The Practices render unlinked until the owner decides whether each Method enters the catalog (TECH-1).
-
-A few points of intent shape the four:
-
-- **The four split across two endstations by what reads the contrast.** Resonant scattering and reflectivity read it at the RASOR endstation: the contrast is the intensity of a scattered or reflected beam on the diffractometer, observed through point and current-integrating detection (DET-1). XMCD and XMLD read it at the i10-1 / I10J magnet endstation: the contrast is an absorption difference observed as total-electron-yield, fluorescence, or diode signal while a magnetic field is applied to the sample (DET-1, MAG-1). Underneath all four is the same shared move that i06 named: set or turn the polarization at an absorption edge and observe the difference.
-
-- **Three techniques reuse existing Methods; one is new.** Resonant scattering and XMCD are the same Methods CORA already carries pending from the 4-ID deployment, and XMLD reuses the i06 slug, so for those three i10 is a second (or third) consumer rather than a coiner: the second consumer is the graduation watch-item. Reflectivity has no existing Method that fits, so it is a new pending slug. Whether any of the four enters CORA's catalog as a Capability is an owner decision (TECH-1), recorded on the [Model](model.md) page, not made here.
-
-- **Resonant scattering and reflectivity reuse the RASOR geometry, and the science detector is a flux monitor.** The RASOR diffractometer (the two-theta scattering arm with sample theta, chi, chamber X, and alpha) is modelled now as a `Goniometer` (DIFF-1), with a reciprocal-space `PseudoAxis` over it (DIFF-2). There is no area detector at RASOR, so the scattered-beam point detector, the incident-flux monitor, the fluorescence channel, and the drain-current / total-electron-yield channel all bind the catalog `FluxMonitor` family through their current amplifiers (DET-1). The geometry that aims and reads the beam is in the model; the recipe that sequences a scan or a reflectivity curve is calibration the deployment supplies later.
-
-- **XMCD and XMLD here are field-and-temperature techniques.** At i10-1 the contrast is made not just by turning the polarization but by applying a magnetic field with the sample held cold. The magnets are modelled (MAG-1), the cryostat stage and its temperature controller are modelled (TEMP-1), and the i10-1 point detection is again a `FluxMonitor` (DET-1). The applied-field affordance is what distinguishes i10's XMCD / XMLD from i06's, and it is the second of the two things i10 adds (see below).
-
-## The polarization axis, reused from i06
-
-The polarization acquisition axis is not new with i10. i06 brought it to the fleet first: an APPLE-II undulator drives its magnetic phase rows to choose the X-ray polarization, not just set a gap, so a run can ask for a polarization the way it asks for an energy. i10 is the fleet's second APPLE-II source and reuses that axis unchanged.
-
-i10 models it as a [`PseudoAxis`](../../catalog/families.md) over the twin-APPLE-II phase rows, a sibling of the incident-energy pseudo-axis over the same source. The shape is:
-
-- **Set the polarization on the APPLE-II.** The axis's value domain is the polarization set the source can produce: linear horizontal (LH), linear vertical (LV), circular positive (PC), circular negative (NC), and linear at an arbitrary angle (LA), plus third-harmonic variants (POL-1). The continuous linear-arbitrary-angle is the continuous realization of the LA value within this same axis, not a second axis and not a new family. The run names a value; CORA writes it; the source's phase rows move to produce it.
-
-- **Turn it at an absorption edge to make the contrast.** XMCD flips between PC and NC at a magnetic edge and reads the absorption difference. XMLD rotates between two linear angles. Resonant scattering tunes the polarization and the incident energy together through a resonance. In every case the contrast is the change the polarization causes, so turning the polarization at the edge is the acquisition primitive the whole family is built on.
-
-- **The conversion stays on the live controller.** The polarization-to-phase kinematics is carried rule-less by default: the live i10 controller owns the conversion, so CORA names the axis and records the move without duplicating a second source of truth for the source geometry (POL-1). Both undulators are driven sources, and whether the polarization handle is wired over one axis or two is an open question (ENERGY-1).
-
-So far this is i06's primitive expressed by reuse: the polarization axis is a `PseudoAxis`, the source is an `InsertionDevice`, and no new device Family appears. i10 then adds two things i06 does not carry.
-
-### What i10 adds: polarization analysis of the scattered beam
-
-RASOR does not only set the incident polarization; it can resolve the polarization of the scattered beam. The motorized analyzer arm (the PaStage / POLAN arm, with its analyzer two-theta and theta, py and pz, and eta motors) selects a scattered-polarization channel, which is what lets resonant scattering separate the magnetic and charge contributions to a peak rather than read only its total intensity. This is the analysis half of polarization: i06 turns it, i10 also reads it back.
-
-CORA models that arm as the catalog `PolarizationAnalyzer` Family. This is a deliberate modelling choice: dodal exposes only the arm's motors, and the analyzer crystal is implicit hardware, but RASOR's defining polarization-analysis role lives on that real motorized arm, so CORA models the arm rather than hiding the role. The analyzer crystal specifics are not invented (POL-2). The Family has graduated across 4-ID / i10 / ID32 / P09, presenting Positioner; the analyzer-crystal spec stays a per-Asset detail to confirm (POL-2).
-
-### What i10 adds: applied-field dichroism
-
-The i10-1 / I10J endstation makes the dichroic contrast under an applied magnetic field, with the sample held at low temperature. Two magnet devices serve it: a set-and-read electromagnet and a superconducting magnet whose field can be swept (a Flyable affordance). CORA models both as the single graduated `Magnet` family: they are one family, and the field sweep is a per-Asset affordance, not a split (MAG-1). i10-1 was the `Magnet` family's second sighting after 4-ID, and with the later ESRF ID32 magnet it reached a rule-of-three and graduated into the catalog (MAG-1). The field values and the sweep specifics are not invented (MAG-1).
-
-The applied field is what makes i10's XMCD / XMLD different from i06's: i06 reads dichroism from the polarization alone, while i10 reads it with a field applied and the sample cold. The cryostat low-temperature stage folds into the catalog `LinearStage`, and the magnet temperature is held by a catalog `TemperatureController` (TEMP-1). As with the polarization axis, no new device Family is coined for either addition: the analyzer binds the graduated catalog `PolarizationAnalyzer`, and the magnets are the graduated `Magnet` family, whose rule-of-three i10-1 helped complete.
-
-## Not modelled yet
-
-The intent above is the function view. The concrete recipes that turn it into runnable acquisition are deliberately not written, because writing them for a beamline CORA does not yet drive would be invention rather than record:
-
-- **The concrete recipes.** The per-edge energy and polarization sequences, the reflectivity angle and energy scans, the polarization-analysis channel selections, the field and temperature setpoints for an in-situ measurement, and the dwell and averaging are all calibration the deployment must supply. None of it is invented here. No energies, angles, fields, or resolutions are stated.
-
-- **Whether each Method enters the catalog.** Minting a Method is owner-scope. Resonant scattering and XMCD reuse 4-ID Methods, XMLD reuses the i06 slug, and reflectivity is a new slug, but all four render pending until the owner decides (TECH-1). The decision is recorded on the [Model](model.md) page, not made here.
-
-- **The graduated analyzer and magnet families.** `PolarizationAnalyzer` has graduated to a catalog Family across 4-ID / i10 / ID32 / P09 (POL-2), so i10's analyzer arm binds the catalog Family; the analyzer-crystal spec stays uninvented as a per-Asset detail. The `Magnet` family has also graduated (i10-1 was one of its three consumers with 4-ID and ID32), so i10's magnets bind the catalog Family; only the per-Asset magnet field values stay uninvented (MAG-1).
-
-- **The science detectors.** Neither endstation has an area detector. The RASOR and i10-1 point and current-integrating channels bind the catalog `FluxMonitor` through their current amplifiers (DET-1); no detector Family is invented in the meantime.
-
-For the source and optics that feed these techniques, see the generated source-walk on [the beamline page](source.md). For what the i10 team must confirm before the model can be trusted, see [Open questions](questions.md). The CORA-owned scope decisions (the deferred Methods, the held families, the diffractometer Assembly) are recorded on the [Model](model.md#deliberately-not-here-yet) page.
diff --git a/docs/deployments/i11/governance.md b/docs/deployments/i11/governance.md
deleted file mode 100644
index fa5f58db338..00000000000
--- a/docs/deployments/i11/governance.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Governance
-
-*Who would act at I11, and the trust shape that would gate it. Design-phase.*
-
-Governance at I11 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take, gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the command surfaces, and Policies).
-
-I11 is the fourth beamline at the Diamond Site (after I22, I03, and I15-1), so it reuses the Diamond facility envelope: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I11 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md).
-
-Two governance notes at I11:
-
-- **Autonomous sample loading is gated by a Clearance.** Like I03, the sample-changing robot + carousel would run unattended, so its operation is gated by a Clearance that must be Active, issued after a safety review; the robot is one Positioner Asset and the sample it carries is a `Subject` (ROBOT-1).
-- **The TemperatureController earn touched governed vocabulary.** I11 was the rule-of-three that earned graduating the `TemperatureController` Family and a new settable-actuator Role. Because a new Role is a code change to a core BC aggregate (`SEED_ROLES`), that change was routed through the gate-review panel (3 baseline + specialist reviewers) rather than slipped into this scaffold (TEMP-1), and has since landed: `TemperatureController` is a catalog Family presenting the `Regulator` Role. The scaffold cadence stayed clean; the core-vocabulary change got its proper governance.
-
-Because I11 is a modelling exercise, the concrete Zone, Conduit, and Policy instances are not instantiated; the off-roadmap question SCOPE-1 applies as at the other Diamond beamlines. They would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i11/model.md b/docs/deployments/i11/model.md
deleted file mode 100644
index 198fe4acc6e..00000000000
--- a/docs/deployments/i11/model.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I11 content lives, the settable-continuous-setpoint actuator Role it earns, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I11 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The earn, and why it is not in this PR
-
-I11 is the deployment that genuinely earns an abstraction CORA has deferred since 7-BM: a **settable-continuous-setpoint actuator**. Its four thermal actuators (two Cyberstar/Eurotherm blowers, two Oxford cryostreams) are `Locatable[float]` with `set(value)`/`setpoint`/`ramprate`/PID. After the loose `TemperatureController` family was carried at I22 and I03, I11 is the rule-of-three.
-
-That earns two things:
-
-1. **Graduating the `TemperatureController` Family** (catalog `families:` add, like I03's Goniometer).
-2. **A new settable-continuous-setpoint actuator Role** (CORA had none at the time: Positioner is spatial, Controller supervises, GenericProbe is read-only).
-
-The Role was a **code change** to `cora.equipment.aggregates.role.SEED_ROLES`, which is drift-guarded by an exact-match test (`test_roles_match_seed_roles`), and is core cross-facility vocabulary. Per the gate-review discipline, that did not belong in a families-only scaffold PR; it was routed to a **separate, gate-reviewed change** (TEMP-1). Graduating the Family is coupled to the Role (a `TemperatureController` Family presenting a non-existent Role would be hollow), so both landed together in that change: `TemperatureController` is now a catalog Family presenting the new `Regulator` Role. This scaffold carried the actuators loose, as I22 and I03 did, and recorded the trigger.
-
-## What is deliberately not here yet
-
-- **The TemperatureController graduation + `Regulator` Role**: not part of this families-only scaffold; landed via the gate-reviewed follow-up (TEMP-1).
-- **New Capabilities / Methods and vendor Models.** The powder-diffraction Method is carried pending; no Model is bound.
-- **The robot as a Family.** It presents the existing Positioner Role; shape deferred (ROBOT-1).
-- **Integration scenarios.** No `test_i11_*.py` registers I11 Assets.
-- **Operations and experiment views.** See the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i11/notes.md b/docs/deployments/i11/notes.md
new file mode 100644
index 00000000000..93dd1e8641c
--- /dev/null
+++ b/docs/deployments/i11/notes.md
@@ -0,0 +1,105 @@
+# Notes
+
+## Techniques
+
+*What I11 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I11 does high-resolution powder diffraction, a new science domain for CORA. Which Methods enter scope is an open question (TECH-1).
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| High-resolution powder diffraction | monochromatic (DCM) | `Mythen3` strip detector on the two-theta arm, capillary `Spinner` for averaging | new Capability, pending (TECH-1) |
+| Variable-temperature powder diffraction | monochromatic | same, over a temperature ramp on the thermal actuators | the variable-temperature axis that earns TemperatureController (TEMP-1) |
+| Autonomous sample exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
+
+A few points of intent shape the model:
+
+- **Powder diffraction is a new Capability, not a new device shape.** A measurement spins a capillary sample for powder averaging and sweeps the detector arm while the Mythen3 strip captures the diffraction pattern. The device Roles already exist (the diffractometer and spinner present Positioner, the Mythen3 presents Detector); what is new is the science Capability binding them (TECH-1).
+- **Variable temperature is the genuinely new operating axis, and it earns an abstraction.** Powder diffraction at I11 routinely runs over a temperature ramp using the Cyberstar/Eurotherm blowers and the cryostreams. These are continuous-setpoint actuators (`set(value)`/`ramprate`), the first such cluster CORA has at rule-of-three. That earned the `TemperatureController` Family graduation and the `Regulator` Role, which landed via gate-review (TEMP-1).
+- **The diffractometer is not goniometry.** Unlike I03's MX goniometer (a sample-orientation cradle, the graduated Goniometer Family), I11's theta/two_theta/delta are a sample rotation plus detector-arm angles, modelled as per-axis RotaryStage (GONIO-1).
+
+The concrete recipes (two-theta ranges, exposure, temperature ramps) are calibration the deployment must supply. See [Open questions](#open-questions).
+
+## Governance
+
+*Who would act at I11, and the trust shape that would gate it. Design-phase.*
+
+Governance at I11 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take, gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the command surfaces, and Policies).
+
+I11 is the fourth beamline at the Diamond Site (after I22, I03, and I15-1), so it reuses the Diamond facility envelope: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I11 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md).
+
+Two governance notes at I11:
+
+- **Autonomous sample loading is gated by a Clearance.** Like I03, the sample-changing robot + carousel would run unattended, so its operation is gated by a Clearance that must be Active, issued after a safety review; the robot is one Positioner Asset and the sample it carries is a `Subject` (ROBOT-1).
+- **The TemperatureController earn touched governed vocabulary.** I11 was the rule-of-three that earned graduating the `TemperatureController` Family and a new settable-actuator Role. Because a new Role is a code change to a core BC aggregate (`SEED_ROLES`), that change was routed through the gate-review panel (3 baseline + specialist reviewers) rather than slipped into this scaffold (TEMP-1), and has since landed: `TemperatureController` is a catalog Family presenting the `Regulator` Role. The scaffold cadence stayed clean; the core-vocabulary change got its proper governance.
+
+Because I11 is a modelling exercise, the concrete Zone, Conduit, and Policy instances are not instantiated; the off-roadmap question SCOPE-1 applies as at the other Diamond beamlines. They would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I11 content lives, the settable-continuous-setpoint actuator Role it earns, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I11 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The earn, and why it is not in this PR
+
+I11 is the deployment that genuinely earns an abstraction CORA has deferred since 7-BM: a **settable-continuous-setpoint actuator**. Its four thermal actuators (two Cyberstar/Eurotherm blowers, two Oxford cryostreams) are `Locatable[float]` with `set(value)`/`setpoint`/`ramprate`/PID. After the loose `TemperatureController` family was carried at I22 and I03, I11 is the rule-of-three.
+
+That earns two things:
+
+1. **Graduating the `TemperatureController` Family** (catalog `families:` add, like I03's Goniometer).
+2. **A new settable-continuous-setpoint actuator Role** (CORA had none at the time: Positioner is spatial, Controller supervises, GenericProbe is read-only).
+
+The Role was a **code change** to `cora.equipment.aggregates.role.SEED_ROLES`, which is drift-guarded by an exact-match test (`test_roles_match_seed_roles`), and is core cross-facility vocabulary. Per the gate-review discipline, that did not belong in a families-only scaffold PR; it was routed to a **separate, gate-reviewed change** (TEMP-1). Graduating the Family is coupled to the Role (a `TemperatureController` Family presenting a non-existent Role would be hollow), so both landed together in that change: `TemperatureController` is now a catalog Family presenting the new `Regulator` Role. This scaffold carried the actuators loose, as I22 and I03 did, and recorded the trigger.
+
+### What is deliberately not here yet
+
+- **The TemperatureController graduation + `Regulator` Role**: not part of this families-only scaffold; landed via the gate-reviewed follow-up (TEMP-1).
+- **New Capabilities / Methods and vendor Models.** The powder-diffraction Method is carried pending; no Model is bound.
+- **The robot as a Family.** It presents the existing Positioner Role; shape deferred (ROBOT-1).
+- **Integration scenarios.** No `test_i11_*.py` registers I11 Assets.
+- **Operations and experiment views.** See the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the I11 team (and Diamond's documentation) to confirm before the model can be trusted.*
+
+I11 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles; it does not give the calibrated numbers, the hutch / PSS safety meaning, or the Capability / Method binding. This is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Scope and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is I11 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise? | A generalization exercise; not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
+| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the two hutches? | Both hutches exist; permit signals to be named. | The Enclosure permit signals. |
+| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones, not the access-gated hutch. | The standard optics + experiment hutch split. | The per-device Enclosure assignment. |
+
+*(TEMP-1, the thermal earn, is resolved: i11's four continuous-setpoint actuators triggered graduating the `TemperatureController` catalog Family and adding the `Regulator` Role with the `Settable` affordance, landed via a gate-reviewed change.)*
+
+### Source, optics, diffractometer
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What is the I11 source and its energy range? dodal does not pin it (the Synchrotron device is facility-wide, observe-only). | A source carried `confirm`; energy range is calibration to supply. | The source and beamline energy range. |
+| OPT-1 | Nice-to-have | What are the DCM crystal d-spacing and thermal model? dodal exposes the axes and the Si(111) default, not the calibrated values. | Settings / a bound Model on the existing Monochromator Family. | The mono calibration. |
+| MACHINE-1 | Nice-to-have | How should the storage-ring state be modelled: loose `StorageRing`, observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
+| GONIO-1 | Nice-to-have | Is the diffractometer (theta / two_theta / delta) correctly modelled as per-axis `RotaryStage` (not the I03-graduated `Goniometer`)? | Yes: theta is a sample rotation and two_theta / delta are detector-arm angles, not an MX orientation cradle. | That the diffractometer stays RotaryStage, not Goniometer. |
+| DIFF-1 | Blocks-go-live | What are the diffractometer axis PVs and ranges (the dodal class was not read axis-by-axis), and the detector-arm geometry? | Per-axis RotaryStage under a DiffractometerStage Assembly; axes to confirm. | The diffractometer per-axis Assets and geometry. |
+| SPIN-1 | Nice-to-have | Is the capillary spinner correctly a `RotaryStage` (a sample-rotation device for powder averaging), and what speed range? | Yes, a RotaryStage; speed is calibration. | The spinner modelling and speed range. |
+
+### Detector, robot, technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MYTHEN-1 | Blocks-go-live | How is the Mythen3 (a 1D position-sensitive strip detector) modelled: reuse `Camera` (Detector Role), or does a strip / PSD warrant a distinct shape? And what are its threshold / deadtime values? It is skip-flagged in dodal (issue I11-916). | Reuse `Camera` / Detector Role, with the strip-vs-2D nuance noted; calibration to supply. | The strip-detector Role choice and calibration. |
+| ROBOT-1 | Blocks-go-live | What is the sample-changing robot + carousel, how is autonomous loading gated, and what is the sample custody lifecycle? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance, vendor in a bound Model (the I03 / 19-BM shape); not a new Family. | The robot Asset, its Clearance gate, and the Subject custody thread. |
+| TECH-1 | Blocks-go-live | What is the powder-diffraction Capability and its Methods (binding the diffractometer + Mythen3 + spinner, often over a temperature ramp)? | A new powder-diffraction Capability not yet in the catalog, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
+| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags)? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i11/questions.md b/docs/deployments/i11/questions.md
deleted file mode 100644
index 95851cfd55e..00000000000
--- a/docs/deployments/i11/questions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Open questions
-
-*What CORA needs the I11 team (and Diamond's documentation) to confirm before the model can be trusted.*
-
-I11 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles; it does not give the calibrated numbers, the hutch / PSS safety meaning, or the Capability / Method binding. This is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Scope and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is I11 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise? | A generalization exercise; not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
-| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the two hutches? | Both hutches exist; permit signals to be named. | The Enclosure permit signals. |
-| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones, not the access-gated hutch. | The standard optics + experiment hutch split. | The per-device Enclosure assignment. |
-
-*(TEMP-1, the thermal earn, is resolved: i11's four continuous-setpoint actuators triggered graduating the `TemperatureController` catalog Family and adding the `Regulator` Role with the `Settable` affordance, landed via a gate-reviewed change.)*
-
-## Source, optics, diffractometer
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What is the I11 source and its energy range? dodal does not pin it (the Synchrotron device is facility-wide, observe-only). | A source carried `confirm`; energy range is calibration to supply. | The source and beamline energy range. |
-| OPT-1 | Nice-to-have | What are the DCM crystal d-spacing and thermal model? dodal exposes the axes and the Si(111) default, not the calibrated values. | Settings / a bound Model on the existing Monochromator Family. | The mono calibration. |
-| MACHINE-1 | Nice-to-have | How should the storage-ring state be modelled: loose `StorageRing`, observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
-| GONIO-1 | Nice-to-have | Is the diffractometer (theta / two_theta / delta) correctly modelled as per-axis `RotaryStage` (not the I03-graduated `Goniometer`)? | Yes: theta is a sample rotation and two_theta / delta are detector-arm angles, not an MX orientation cradle. | That the diffractometer stays RotaryStage, not Goniometer. |
-| DIFF-1 | Blocks-go-live | What are the diffractometer axis PVs and ranges (the dodal class was not read axis-by-axis), and the detector-arm geometry? | Per-axis RotaryStage under a DiffractometerStage Assembly; axes to confirm. | The diffractometer per-axis Assets and geometry. |
-| SPIN-1 | Nice-to-have | Is the capillary spinner correctly a `RotaryStage` (a sample-rotation device for powder averaging), and what speed range? | Yes, a RotaryStage; speed is calibration. | The spinner modelling and speed range. |
-
-## Detector, robot, technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MYTHEN-1 | Blocks-go-live | How is the Mythen3 (a 1D position-sensitive strip detector) modelled: reuse `Camera` (Detector Role), or does a strip / PSD warrant a distinct shape? And what are its threshold / deadtime values? It is skip-flagged in dodal (issue I11-916). | Reuse `Camera` / Detector Role, with the strip-vs-2D nuance noted; calibration to supply. | The strip-detector Role choice and calibration. |
-| ROBOT-1 | Blocks-go-live | What is the sample-changing robot + carousel, how is autonomous loading gated, and what is the sample custody lifecycle? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance, vendor in a bound Model (the I03 / 19-BM shape); not a new Family. | The robot Asset, its Clearance gate, and the Subject custody thread. |
-| TECH-1 | Blocks-go-live | What is the powder-diffraction Capability and its Methods (binding the diffractometer + Mythen3 + spinner, often over a temperature ramp)? | A new powder-diffraction Capability not yet in the catalog, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
-| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags)? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i11/techniques.md b/docs/deployments/i11/techniques.md
deleted file mode 100644
index 2728e2d213b..00000000000
--- a/docs/deployments/i11/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What I11 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I11 does high-resolution powder diffraction, a new science domain for CORA. Which Methods enter scope is an open question (TECH-1).
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| High-resolution powder diffraction | monochromatic (DCM) | `Mythen3` strip detector on the two-theta arm, capillary `Spinner` for averaging | new Capability, pending (TECH-1) |
-| Variable-temperature powder diffraction | monochromatic | same, over a temperature ramp on the thermal actuators | the variable-temperature axis that earns TemperatureController (TEMP-1) |
-| Autonomous sample exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
-
-A few points of intent shape the model:
-
-- **Powder diffraction is a new Capability, not a new device shape.** A measurement spins a capillary sample for powder averaging and sweeps the detector arm while the Mythen3 strip captures the diffraction pattern. The device Roles already exist (the diffractometer and spinner present Positioner, the Mythen3 presents Detector); what is new is the science Capability binding them (TECH-1).
-- **Variable temperature is the genuinely new operating axis, and it earns an abstraction.** Powder diffraction at I11 routinely runs over a temperature ramp using the Cyberstar/Eurotherm blowers and the cryostreams. These are continuous-setpoint actuators (`set(value)`/`ramprate`), the first such cluster CORA has at rule-of-three. That earned the `TemperatureController` Family graduation and the `Regulator` Role, which landed via gate-review (TEMP-1).
-- **The diffractometer is not goniometry.** Unlike I03's MX goniometer (a sample-orientation cradle, the graduated Goniometer Family), I11's theta/two_theta/delta are a sample rotation plus detector-arm angles, modelled as per-axis RotaryStage (GONIO-1).
-
-The concrete recipes (two-theta ranges, exposure, temperature ramps) are calibration the deployment must supply. See [Open questions](questions.md).
diff --git a/docs/deployments/i13-1/governance.md b/docs/deployments/i13-1/governance.md
deleted file mode 100644
index 56c9764c3db..00000000000
--- a/docs/deployments/i13-1/governance.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Governance
-
-*Who may act at I13-1 and the trust shape CORA applies. This is CORA's governance design landing on the coherence-branch endstation, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
-
-People and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the `i13_1` dodal module (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as the other Diamond beamlines, and the same partial-first-cut posture as the I13-1 scaffold overall: only the coherence-branch endstation is in this cut, and the shared I13 source and optics are deferred (SRC-1, OPT-1).
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Diamond Site. An I13-1 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive the [sample stage](sample.md) through a ptychography raster, arm the [Merlin detector](sample.md) to record the far-field coherent-diffraction pattern, view the sample on the side camera, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
-
-Because I13-1 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zone grouping the coherence-branch resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-
-## The Enclosure I13-1 gates
-
-This cut covers a single enclosure, the grouping CORA's Zone would follow (ENC-1):
-
-| Enclosure | PV zone | What it holds |
-| --- | --- | --- |
-| `i13-1` | `BL13J` | the coherence-branch experiment hutch: the PI piezo sample-scanning stage, the Aravis / GenICam side camera, and the Merlin / Medipix3 detector |
-
-The shared I13 source and the I13-2 imaging branch are out of this cut and not part of the Zone here (SRC-1, OPT-1).
-
-## The safety tier behind the beam
-
-The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from the `i13_1` dodal module, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
-
-Clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The Diamond PSS clearance is carried pending because its form names are not confirmed (PSS-1).
-
-## Coherent imaging under custody
-
-I13-1's reason for existing is coherent lensless imaging: a ptychography or coherent-diffraction-imaging acquisition raster-scans the coherent beam across the sample and records the far-field diffraction, and a real-space image is reconstructed from that diffraction stack. In CORA's model this novelty is an acquisition shape and a reconstruction, a Method, not a new device class (TECH-1); the devices it gates are a raster LinearStage and Cameras (SAMPLE-1, DET-1), and the reconstruction is ComputePort work, not a beamline device. That makes the repeated raster acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the raster and arm the Merlin detector, and the Campaign and Subject shapes carry the sample's custody and the diffraction record.
-
-If an autonomous Agent were added (for example to step the raster or decide when a diffraction stack is complete enough to reconstruct), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; with the shared source and optics deferred and the ptychography Method carried pending (SRC-1, OPT-1, TECH-1), this stays design intent.
-
-## What is deliberately not modelled
-
-- **The PSS permit signals and shutters (PSS-1).** Absent from the `i13_1` dodal module, carried pending, not invented.
-- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
-- **The shared I13 source and optics (SRC-1, OPT-1).** Upstream and absent from the module; deferred, not invented. No monochromator, mirror, slit, or undulator Asset is coined.
-- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The full delete-on-answer queue is on [Open questions](questions.md); where each device and Method lands is on [Model](model.md).
diff --git a/docs/deployments/i13-1/model.md b/docs/deployments/i13-1/model.md
deleted file mode 100644
index 9f800eca974..00000000000
--- a/docs/deployments/i13-1/model.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I13-1 content lives, why coherent imaging coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I13-1 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes I13-1 new
-
-I13-1 is CORA's first coherent lensless-imaging beamline. The fleet has tomography, XRF microprobe, and a hard X-ray nanoprobe (HXN), but no ptychography or coherent diffraction imaging (CDI). Ptychography raster-scans a coherent illumination across overlapping points on the sample and records a far-field coherent-diffraction pattern at each point; the real-space image is reconstructed downstream from the diffraction stack. That is the novelty, and it is an **acquisition shape plus a reconstruction**, a new Capability deferred as a pending Method (`TECH-1`), not a new device class.
-
-## No new families
-
-The scout that surfaced I13-1 anticipated a new "coherent imaging" device family. That is the wrong axis: coherent imaging is a Method, not a device. The devices the technique needs are a sample-scanning stage and an area detector, both of which the catalog already covers, so I13-1 coins no new Family and changes nothing in the catalog:
-
-- **The piezo sample-scanning stage binds the catalog `LinearStage`.** The ptychography raster is its operative motion; the fixed-angle lab-frame variant (`BL13J-MO-PI-02:FIXANG:`) is a setting on the same stage, not a separate device class (`SAMPLE-1`).
-- **The Merlin photon-counting detector and the side viewing camera bind the catalog `Camera`.** The Merlin records the far-field coherent-diffraction pattern (the science detector); the side camera is for alignment (`DET-1`).
-- **The machine state binds the loose `StorageRing`** (`MACHINE-1`).
-
-The coherent imaging itself is the `ptychography` Method, the fleet's first, carried pending (`TECH-1`).
-
-## Deliberately not here yet
-
-- **The shared I13 source and optics (`SRC-1`, `OPT-1`).** The dodal `i13_1` module exposes only the coherence-branch endstation; the undulator, monochromator, mirrors, and slits are upstream and not in the module, so they are deferred, not invented. This is the same partial-first-cut posture as I20-1.
-- **The ptychography Method and the reconstruction.** Whether ptychography / CDI enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`TECH-1`). The image reconstruction from the diffraction stack is `ComputePort` work, not a beamline device.
-- **The simulated devices and full asset-tree scenarios.** No `test_i13_1_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i13-1/notes.md b/docs/deployments/i13-1/notes.md
new file mode 100644
index 00000000000..4e898036daa
--- /dev/null
+++ b/docs/deployments/i13-1/notes.md
@@ -0,0 +1,157 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at I13-1: hard X-ray ptychography and coherent diffraction imaging, a [Catalog](../../catalog/methods.md) Method bound through a [Diamond Practice](../diamond/index.md#the-techniques-adapted-here). It is the fleet's first coherent lensless imaging, and its Capability is new and deferred, the more so because only the coherence-branch endstation is in source.*
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Ptychography / coherent diffraction imaging (CDI) | `ptychography` | a coherent beam is raster-scanned across overlapping points on the sample and the far-field coherent-diffraction pattern is captured at each point; the real-space image is reconstructed downstream. The fleet's first coherent lensless imaging. New Capability, pending (TECH-1) |
+
+The technique is recorded as a pending [Practice](../diamond/index.md#the-techniques-adapted-here) on the Diamond Site, `I13-1_ptychography_practice` (TECH-1).
+
+### The acquisition shape
+
+Ptychography is not a new kind of device, it is a way of acquiring. A coherent beam is rastered across the sample in overlapping points, the [sample stage](sample.md) moving point to point (SAMPLE-1); at each point the Merlin (the Medipix3 photon-counting detector) records the far-field coherent-diffraction pattern; and the stack of diffraction patterns, together with the known scan positions, is enough to reconstruct a real-space image of the sample. The overlap between adjacent points is what makes the reconstruction tractable.
+
+CDI is the same lensless-imaging idea read from far-field coherent diffraction; CORA carries the pair under the one `ptychography` Method (TECH-1).
+
+So the parts in source are a raster `LinearStage` (the PI piezo sample-scanning stage, SAMPLE-1) and two `Camera`s: the Merlin as the science detector that records each diffraction frame, and the Aravis / GenICam side camera for sample alignment (DET-1). The novelty lives in how they are driven and in what happens afterward, not in a new device class.
+
+### Why the Capability is new, and deferred
+
+Ptychography is a genuinely new science Capability for CORA to model as a beamline's purpose. HXN already rasters a coherent nanobeam and reconstructs from the diffraction stack, but as one of several scanning-probe modes; I13-1 is the first beamline CORA models around coherent lensless imaging as its reason for being. CORA carries the `ptychography` Method as pending rather than coining it outright, the same earn-the-abstraction discipline every new-domain technique follows (TECH-1).
+
+It would be tempting to read the novelty as a new device family, a "coherent imaging" class. That is the wrong axis. The coherence is a property of the beam and the acquisition, and the devices that realise it are a raster `LinearStage` and `Camera`s already in the Catalog. The new thing is a Method, an acquisition shape plus a reconstruction, and it adds no Family ([Model](#model)).
+
+The image reconstruction, turning the stack of far-field diffraction patterns into a real-space image, is `ComputePort` work, not a beamline Method. It runs downstream of the acquisition, not on a device on the floor.
+
+### Not modelled yet
+
+This is a deliberately partial first cut, the same posture as the sibling i20-1 scaffold. The public dodal module exposes only the coherence-branch endstation, the sample stage, the side camera, and the Merlin detector. What sits upstream is absent from source and deferred, not invented:
+
+- The shared I13 source and the optics that condition the coherent beam (the undulator, monochromator, mirrors, and slits) are upstream of the endstation and not in the module. They are carried as open questions, not fabricated (SRC-1, OPT-1).
+- The machine state is observe-only against a loose `StorageRing`; the shared source is deferred with it (MACHINE-1, SRC-1).
+- The PSS search-and-secure permit signals and the photon / front-end shutters are absent from the dodal module and carried pending, not invented (PSS-1).
+- Beam-conditioning and shutter conduct paths, and the supporting infrastructure around the endstation, follow once their devices are in source (CTRL-1, SUP-1).
+
+Each of these is named on the [Open questions](#open-questions) page rather than guessed at. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
+
+## Governance
+
+*Who may act at I13-1 and the trust shape CORA applies. This is CORA's governance design landing on the coherence-branch endstation, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
+
+People and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the `i13_1` dodal module (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as the other Diamond beamlines, and the same partial-first-cut posture as the I13-1 scaffold overall: only the coherence-branch endstation is in this cut, and the shared I13 source and optics are deferred (SRC-1, OPT-1).
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Diamond Site. An I13-1 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The Diamond operator pool and review structure are site-level and shared across the beamlines, so they are not instantiated per beamline; they are carried pending on the [Diamond Site page](../diamond/index.md#safety-and-governance) (GOV-1). None of this is in dodal, which is a controls library, not an organizational record.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive the [sample stage](sample.md) through a ptychography raster, arm the [Merlin detector](sample.md) to record the far-field coherent-diffraction pattern, view the sample on the side camera, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
+
+Because I13-1 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zone grouping the coherence-branch resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+
+### The Enclosure I13-1 gates
+
+This cut covers a single enclosure, the grouping CORA's Zone would follow (ENC-1):
+
+| Enclosure | PV zone | What it holds |
+| --- | --- | --- |
+| `i13-1` | `BL13J` | the coherence-branch experiment hutch: the PI piezo sample-scanning stage, the Aravis / GenICam side camera, and the Merlin / Medipix3 detector |
+
+The shared I13 source and the I13-2 imaging branch are out of this cut and not part of the Zone here (SRC-1, OPT-1).
+
+### The safety tier behind the beam
+
+The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the photon and front-end shutters are what those leaves gate. Both the permit signals and the shutters are absent from the `i13_1` dodal module, so CORA does not name them and does not invent them: the Enclosure permit signals and the shutters are carried pending (PSS-1). When staff confirm the signal and shutter handles, they bind to the Enclosure as the permit leaves the way the Diamond siblings carry theirs. No interlock, PSS, or equipment-protection tier is invented in the meantime.
+
+Clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The Diamond PSS clearance is carried pending because its form names are not confirmed (PSS-1).
+
+### Coherent imaging under custody
+
+I13-1's reason for existing is coherent lensless imaging: a ptychography or coherent-diffraction-imaging acquisition raster-scans the coherent beam across the sample and records the far-field diffraction, and a real-space image is reconstructed from that diffraction stack. In CORA's model this novelty is an acquisition shape and a reconstruction, a Method, not a new device class (TECH-1); the devices it gates are a raster LinearStage and Cameras (SAMPLE-1, DET-1), and the reconstruction is ComputePort work, not a beamline device. That makes the repeated raster acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the raster and arm the Merlin detector, and the Campaign and Subject shapes carry the sample's custody and the diffraction record.
+
+If an autonomous Agent were added (for example to step the raster or decide when a diffraction stack is complete enough to reconstruct), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; with the shared source and optics deferred and the ptychography Method carried pending (SRC-1, OPT-1, TECH-1), this stays design intent.
+
+### What is deliberately not modelled
+
+- **The PSS permit signals and shutters (PSS-1).** Absent from the `i13_1` dodal module, carried pending, not invented.
+- **The Diamond operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the Diamond Site, not instantiated per beamline.
+- **The shared I13 source and optics (SRC-1, OPT-1).** Upstream and absent from the module; deferred, not invented. No monochromator, mirror, slit, or undulator Asset is coined.
+- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The full delete-on-answer queue is on [Open questions](#open-questions); where each device and Method lands is on [Model](#model).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I13-1 content lives, why coherent imaging coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I13-1 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes I13-1 new
+
+I13-1 is CORA's first coherent lensless-imaging beamline. The fleet has tomography, XRF microprobe, and a hard X-ray nanoprobe (HXN), but no ptychography or coherent diffraction imaging (CDI). Ptychography raster-scans a coherent illumination across overlapping points on the sample and records a far-field coherent-diffraction pattern at each point; the real-space image is reconstructed downstream from the diffraction stack. That is the novelty, and it is an **acquisition shape plus a reconstruction**, a new Capability deferred as a pending Method (`TECH-1`), not a new device class.
+
+### No new families
+
+The scout that surfaced I13-1 anticipated a new "coherent imaging" device family. That is the wrong axis: coherent imaging is a Method, not a device. The devices the technique needs are a sample-scanning stage and an area detector, both of which the catalog already covers, so I13-1 coins no new Family and changes nothing in the catalog:
+
+- **The piezo sample-scanning stage binds the catalog `LinearStage`.** The ptychography raster is its operative motion; the fixed-angle lab-frame variant (`BL13J-MO-PI-02:FIXANG:`) is a setting on the same stage, not a separate device class (`SAMPLE-1`).
+- **The Merlin photon-counting detector and the side viewing camera bind the catalog `Camera`.** The Merlin records the far-field coherent-diffraction pattern (the science detector); the side camera is for alignment (`DET-1`).
+- **The machine state binds the loose `StorageRing`** (`MACHINE-1`).
+
+The coherent imaging itself is the `ptychography` Method, the fleet's first, carried pending (`TECH-1`).
+
+### Deliberately not here yet
+
+- **The shared I13 source and optics (`SRC-1`, `OPT-1`).** The dodal `i13_1` module exposes only the coherence-branch endstation; the undulator, monochromator, mirrors, and slits are upstream and not in the module, so they are deferred, not invented. This is the same partial-first-cut posture as I20-1.
+- **The ptychography Method and the reconstruction.** Whether ptychography / CDI enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`TECH-1`). The image reconstruction from the diffraction stack is `ComputePort` work, not a beamline device.
+- **The simulated devices and full asset-tree scenarios.** No `test_i13_1_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the I13-1 team to confirm before the model can be trusted.*
+
+I13-1 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal), `src/dodal/beamlines/i13_1.py`), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. This is a **deliberately partial** first cut: dodal currently exposes only the coherence-branch endstation, so the shared I13 source and optics are deferred, not invented. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Is I13-1 its own experiment hutch, and how does it relate to the I13-2 imaging branch and the shared I13 source? | One `i13-1` experiment hutch on the `BL13J` prefix. | The Enclosure grouping. |
+| SRC-1 | Blocks-go-live | The shared I13 undulator source, absent from the i13_1 dodal module. | An undulator upstream, not modelled in this partial cut. | The source Asset. |
+| OPT-1 | Blocks-go-live | The shared I13 optics (monochromator, mirrors, slits), absent from the i13_1 dodal module. | Shared optics upstream, not modelled in this partial cut. | The optics Assets. |
+
+### Endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The piezo sample-scanning stage axes, and the fixed-angle lab-frame variant (`BL13J-MO-PI-02:FIXANG:`): one stage with two reference frames or two stages? | One `LinearStage` (the ptychography raster); the fixed-angle frame a setting on the same stage. | The sample-stage modelling. |
+| DET-1 | Blocks-go-live | The Merlin (Medipix3) detector configuration and the side viewing camera role. | The Merlin and the side camera bind `Camera`; the Merlin is the coherent-diffraction science detector. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the i13_1 dodal module). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| MACHINE-1 | Nice-to-have | The storage-ring state I13-1 reads. | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| SUP-1 | Nice-to-have | The vacuum extent of the coherent-beam path. | Photon beam, cooling water, and vacuum on the flight path. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does ptychography / coherent diffraction imaging enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice; the fleet's first coherent diffractive imaging, no `cora.capability.ptychography` coined. | The ptychography Capability. |
diff --git a/docs/deployments/i13-1/questions.md b/docs/deployments/i13-1/questions.md
deleted file mode 100644
index fcf840ef23e..00000000000
--- a/docs/deployments/i13-1/questions.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Open questions
-
-*What CORA needs the I13-1 team to confirm before the model can be trusted.*
-
-I13-1 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal), `src/dodal/beamlines/i13_1.py`), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. This is a **deliberately partial** first cut: dodal currently exposes only the coherence-branch endstation, so the shared I13 source and optics are deferred, not invented. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Is I13-1 its own experiment hutch, and how does it relate to the I13-2 imaging branch and the shared I13 source? | One `i13-1` experiment hutch on the `BL13J` prefix. | The Enclosure grouping. |
-| SRC-1 | Blocks-go-live | The shared I13 undulator source, absent from the i13_1 dodal module. | An undulator upstream, not modelled in this partial cut. | The source Asset. |
-| OPT-1 | Blocks-go-live | The shared I13 optics (monochromator, mirrors, slits), absent from the i13_1 dodal module. | Shared optics upstream, not modelled in this partial cut. | The optics Assets. |
-
-## Endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The piezo sample-scanning stage axes, and the fixed-angle lab-frame variant (`BL13J-MO-PI-02:FIXANG:`): one stage with two reference frames or two stages? | One `LinearStage` (the ptychography raster); the fixed-angle frame a setting on the same stage. | The sample-stage modelling. |
-| DET-1 | Blocks-go-live | The Merlin (Medipix3) detector configuration and the side viewing camera role. | The Merlin and the side camera bind `Camera`; the Merlin is the coherent-diffraction science detector. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from the i13_1 dodal module). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| MACHINE-1 | Nice-to-have | The storage-ring state I13-1 reads. | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| SUP-1 | Nice-to-have | The vacuum extent of the coherent-beam path. | Photon beam, cooling water, and vacuum on the flight path. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does ptychography / coherent diffraction imaging enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice; the fleet's first coherent diffractive imaging, no `cora.capability.ptychography` coined. | The ptychography Capability. |
diff --git a/docs/deployments/i13-1/techniques.md b/docs/deployments/i13-1/techniques.md
deleted file mode 100644
index 557a42f60ee..00000000000
--- a/docs/deployments/i13-1/techniques.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Techniques
-
-*What CORA would run at I13-1: hard X-ray ptychography and coherent diffraction imaging, a [Catalog](../../catalog/methods.md) Method bound through a [Diamond Practice](../diamond/index.md#the-techniques-adapted-here). It is the fleet's first coherent lensless imaging, and its Capability is new and deferred, the more so because only the coherence-branch endstation is in source.*
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Ptychography / coherent diffraction imaging (CDI) | `ptychography` | a coherent beam is raster-scanned across overlapping points on the sample and the far-field coherent-diffraction pattern is captured at each point; the real-space image is reconstructed downstream. The fleet's first coherent lensless imaging. New Capability, pending (TECH-1) |
-
-The technique is recorded as a pending [Practice](../diamond/index.md#the-techniques-adapted-here) on the Diamond Site, `I13-1_ptychography_practice` (TECH-1).
-
-## The acquisition shape
-
-Ptychography is not a new kind of device, it is a way of acquiring. A coherent beam is rastered across the sample in overlapping points, the [sample stage](sample.md) moving point to point (SAMPLE-1); at each point the Merlin (the Medipix3 photon-counting detector) records the far-field coherent-diffraction pattern; and the stack of diffraction patterns, together with the known scan positions, is enough to reconstruct a real-space image of the sample. The overlap between adjacent points is what makes the reconstruction tractable.
-
-CDI is the same lensless-imaging idea read from far-field coherent diffraction; CORA carries the pair under the one `ptychography` Method (TECH-1).
-
-So the parts in source are a raster `LinearStage` (the PI piezo sample-scanning stage, SAMPLE-1) and two `Camera`s: the Merlin as the science detector that records each diffraction frame, and the Aravis / GenICam side camera for sample alignment (DET-1). The novelty lives in how they are driven and in what happens afterward, not in a new device class.
-
-## Why the Capability is new, and deferred
-
-Ptychography is a genuinely new science Capability for CORA to model as a beamline's purpose. HXN already rasters a coherent nanobeam and reconstructs from the diffraction stack, but as one of several scanning-probe modes; I13-1 is the first beamline CORA models around coherent lensless imaging as its reason for being. CORA carries the `ptychography` Method as pending rather than coining it outright, the same earn-the-abstraction discipline every new-domain technique follows (TECH-1).
-
-It would be tempting to read the novelty as a new device family, a "coherent imaging" class. That is the wrong axis. The coherence is a property of the beam and the acquisition, and the devices that realise it are a raster `LinearStage` and `Camera`s already in the Catalog. The new thing is a Method, an acquisition shape plus a reconstruction, and it adds no Family ([Model](model.md)).
-
-The image reconstruction, turning the stack of far-field diffraction patterns into a real-space image, is `ComputePort` work, not a beamline Method. It runs downstream of the acquisition, not on a device on the floor.
-
-## Not modelled yet
-
-This is a deliberately partial first cut, the same posture as the sibling i20-1 scaffold. The public dodal module exposes only the coherence-branch endstation, the sample stage, the side camera, and the Merlin detector. What sits upstream is absent from source and deferred, not invented:
-
-- The shared I13 source and the optics that condition the coherent beam (the undulator, monochromator, mirrors, and slits) are upstream of the endstation and not in the module. They are carried as open questions, not fabricated (SRC-1, OPT-1).
-- The machine state is observe-only against a loose `StorageRing`; the shared source is deferred with it (MACHINE-1, SRC-1).
-- The PSS search-and-secure permit signals and the photon / front-end shutters are absent from the dodal module and carried pending, not invented (PSS-1).
-- Beam-conditioning and shutter conduct paths, and the supporting infrastructure around the endstation, follow once their devices are in source (CTRL-1, SUP-1).
-
-Each of these is named on the [Open questions](questions.md) page rather than guessed at. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
diff --git a/docs/deployments/i15-1/governance.md b/docs/deployments/i15-1/governance.md
deleted file mode 100644
index 7e5f5aa92f1..00000000000
--- a/docs/deployments/i15-1/governance.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Governance
-
-*Who would act at I15-1, and the trust shape that would gate it. Design-phase.*
-
-Governance at I15-1 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take, gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the command surfaces, and Policies).
-
-I15-1 is the third beamline at the Diamond Site (after I22 and I03), so it reuses the Diamond facility envelope: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I15-1 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md).
-
-Two governance points are worth noting at I15-1:
-
-- **The interlocks are governance data, not equipment.** dodal exposes a PSS hutch interlock and a goniometer interlock. CORA does not model these as Assets: an interlock is the read-only permit behind the **Enclosure** aggregate (the shipped Enclosure BC), so it is carried as the Enclosure `permit_signal`, mutated by the safety system, not by CORA (INTERLOCK-1). dodal even gives real interlock PVs here (unlike I22 / I03), carried as the permit-signal candidates pending confirmation (PSS-1).
-- **Autonomous sample loading is gated by a Clearance.** Like I03, the powder/capillary robot would run unattended, so its operation is gated by a Clearance that must be Active, issued after a safety review; the robot is one Positioner Asset and the sample it carries is a `Subject` (ROBOT-1).
-
-Because I15-1 is a modelling exercise, the concrete Zone, Conduit, and Policy instances are not instantiated; the off-roadmap question SCOPE-1 applies as at I22 / I03. They would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i15-1/model.md b/docs/deployments/i15-1/model.md
deleted file mode 100644
index 7a1b5491172..00000000000
--- a/docs/deployments/i15-1/model.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I15-1 content lives, why it adds no catalog kinds and reinforces the existing model, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I15-1 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Why I15-1 adds no catalog kinds
-
-I15-1 was picked partly expecting it to graduate the open settable-actuator affordance from its `SafeOrBeamPositioner` sample-environment devices. A source-level adversarial eval **refuted that**, and the refutation is the modelling content of this deployment:
-
-- **`SafeOrBeamPositioner` folds into Positioner.** It is a `Movable` that drives a motor to two named positions (SAFE / BEAM), which is the existing Positioner Role with Indexable named positions, not a new affordance. It is also **not** a `TemperatureController`: the dodal classes are named for temperature controllers (blower / cobra / cryostream) but model only the in/out-of-beam move, so calling them `TemperatureController` would mirror the class name rather than the behaviour (intentional-modelling-not-mirroring). Modelled as `LinearStage` + Positioner / Indexable (SAFEBEAM-1).
-- **The `rail` folds into Table** (the TomoWISE DetectorGantry precedent), not a new `Rail` Family (RAIL-1).
-- **The interlocks fold into the Enclosure permit**, not an equipment Family (INTERLOCK-1).
-
-So I15-1 is a reuse + reinforce deployment: it provides the third `FluxMonitor` deployment that completed its rule-of-three graduation into the catalog, and adds a third robot-as-Positioner instance, while coining no new vocabulary of its own. That is a result, not a gap: the value is confirming the existing model absorbs a new technique cleanly.
-
-## What is deliberately not here yet
-
-- **New Capabilities / Methods and vendor Models.** The total-scattering Method is carried pending; no Model is bound.
-- **The robot as a Family.** It presents the existing Positioner Role; shape deferred (ROBOT-1).
-- **Integration scenarios.** No `test_i15_1_*.py` registers I15-1 Assets.
-- **Operations and experiment views.** A runbook for an unmodelled beamline would be invention; see the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i15-1/notes.md b/docs/deployments/i15-1/notes.md
new file mode 100644
index 00000000000..691de278828
--- /dev/null
+++ b/docs/deployments/i15-1/notes.md
@@ -0,0 +1,103 @@
+# Notes
+
+## Techniques
+
+*What I15-1 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I15-1 does total scattering / pair distribution function (PDF), a new science domain for CORA. Which Methods enter scope is an open question (TECH-1).
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Total scattering / PDF | fixed-energy, bent-Laue mono | `Eiger` (Detector Role), wide-Q on the two-theta arm | new Capability, pending (TECH-1) |
+| Autonomous powder/capillary exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
+
+A few points of intent shape the model:
+
+- **Total scattering is a new Capability, not a new device shape.** A PDF measurement captures wide-Q scattering on the Eiger across the two-theta arm at a fixed high energy. The device Roles already exist (Camera presents Detector, the mono and arm present Positioner); what is new is the science Capability binding them. Carried pending on the [Diamond Practices](../diamond/index.md) (TECH-1).
+- **Energy scanning is explicitly NOT in scope here.** I15-1's bent-Laue monochromator selects a fixed energy: dodal exposes `energy_kev` as a read-only readback derived from the crystal y position via a lookup table, not a commanded or swept axis. So the pending `energy_scan` Capability is **not** earnable from I15-1's source; it must wait for a tunable XAS/EXAFS beamline whose scanning monochromator is actually instantiated in dodal (ENERGY-1).
+- **The autonomous loop reuses the I03 shape.** The powder/capillary robot exchange is a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the I03 MX loop, with a powder/capillary twist instead of MX pins (ROBOT-1).
+
+The concrete recipes (q-ranges, exposure, the exchange sequence) are calibration the deployment must supply. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who would act at I15-1, and the trust shape that would gate it. Design-phase.*
+
+Governance at I15-1 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take, gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the command surfaces, and Policies).
+
+I15-1 is the third beamline at the Diamond Site (after I22 and I03), so it reuses the Diamond facility envelope: the operator pool, the safety review structure, and the safety forms are facility-wide and inherited. I15-1 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md).
+
+Two governance points are worth noting at I15-1:
+
+- **The interlocks are governance data, not equipment.** dodal exposes a PSS hutch interlock and a goniometer interlock. CORA does not model these as Assets: an interlock is the read-only permit behind the **Enclosure** aggregate (the shipped Enclosure BC), so it is carried as the Enclosure `permit_signal`, mutated by the safety system, not by CORA (INTERLOCK-1). dodal even gives real interlock PVs here (unlike I22 / I03), carried as the permit-signal candidates pending confirmation (PSS-1).
+- **Autonomous sample loading is gated by a Clearance.** Like I03, the powder/capillary robot would run unattended, so its operation is gated by a Clearance that must be Active, issued after a safety review; the robot is one Positioner Asset and the sample it carries is a `Subject` (ROBOT-1).
+
+Because I15-1 is a modelling exercise, the concrete Zone, Conduit, and Policy instances are not instantiated; the off-roadmap question SCOPE-1 applies as at I22 / I03. They would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I15-1 content lives, why it adds no catalog kinds and reinforces the existing model, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I15-1 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Why I15-1 adds no catalog kinds
+
+I15-1 was picked partly expecting it to graduate the open settable-actuator affordance from its `SafeOrBeamPositioner` sample-environment devices. A source-level adversarial eval **refuted that**, and the refutation is the modelling content of this deployment:
+
+- **`SafeOrBeamPositioner` folds into Positioner.** It is a `Movable` that drives a motor to two named positions (SAFE / BEAM), which is the existing Positioner Role with Indexable named positions, not a new affordance. It is also **not** a `TemperatureController`: the dodal classes are named for temperature controllers (blower / cobra / cryostream) but model only the in/out-of-beam move, so calling them `TemperatureController` would mirror the class name rather than the behaviour (intentional-modelling-not-mirroring). Modelled as `LinearStage` + Positioner / Indexable (SAFEBEAM-1).
+- **The `rail` folds into Table** (the TomoWISE DetectorGantry precedent), not a new `Rail` Family (RAIL-1).
+- **The interlocks fold into the Enclosure permit**, not an equipment Family (INTERLOCK-1).
+
+So I15-1 is a reuse + reinforce deployment: it provides the third `FluxMonitor` deployment that completed its rule-of-three graduation into the catalog, and adds a third robot-as-Positioner instance, while coining no new vocabulary of its own. That is a result, not a gap: the value is confirming the existing model absorbs a new technique cleanly.
+
+### What is deliberately not here yet
+
+- **New Capabilities / Methods and vendor Models.** The total-scattering Method is carried pending; no Model is bound.
+- **The robot as a Family.** It presents the existing Positioner Role; shape deferred (ROBOT-1).
+- **Integration scenarios.** No `test_i15_1_*.py` registers I15-1 Assets.
+- **Operations and experiment views.** A runbook for an unmodelled beamline would be invention; see the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the I15-1 team (and Diamond's documentation) to confirm before the model can be trusted.*
+
+I15-1 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles; it does not give the calibrated numbers, the hutch / PSS safety meaning, or the Capability / Method binding. This is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Scope, safety, and the modelling decisions
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is I15-1 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise? | A generalization exercise; not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
+| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the two hutches? dodal records interlock readbacks (BL15I-PS-IOC-02:M11:LOP, BL15I-VA-OMRON-01:INT3:ILK) but not confirmed permits. | Both hutches exist; the dodal interlock readbacks are permit-signal candidates. | The Enclosure permit signals. |
+| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones, not the access-gated hutch. | The standard optics + experiment hutch split. | The per-device Enclosure assignment. |
+| INTERLOCK-1 | Nice-to-have | Are the PSS / gonio interlocks correctly modelled as the Enclosure `permit_signal` (not as equipment devices)? | Yes: an interlock is the read-only permit behind the Enclosure aggregate, not an Asset. | That interlocks stay on the Enclosure, not the device walk. |
+| SAFEBEAM-1 | Blocks-go-live | Are the blower / cobra / cryostream correctly modelled as Positioner + Indexable SAFE/BEAM (not TemperatureController), and is the cobra/cryostream rail-interchange a Fixture-style swap or an Assembly? | Positioner with two named positions; the interchange is a Fixture-style swap (they share the ENV:X rail motor). | The sample-environment actuator shape and the exchange modelling. |
+| RAIL-1 | Nice-to-have | Is the rail correctly the existing Table Family, and what are its exchange semantics? | The existing Table Family (the TomoWISE DetectorGantry precedent), not a new Rail kind. | The rail Family and exchange shape. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What is the I15-1 source (it is a branch line) and its energy range? dodal does not pin it. | A source carried `confirm`; energy range is calibration to supply. | The source and beamline energy range. |
+| ENERGY-1 | Blocks-go-live | Is the bent-Laue energy ever a goto-command (driving y to hit a target energy via inverse lookup), or only the fixed-selection read-only readback dodal exposes? | A read-only y-to-energy lookup readback; the pending energy_scan Capability is NOT earnable here. | Whether energy is a commandable axis and whether energy_scan applies. |
+| OPT-1 | Nice-to-have | What are the bent-Laue crystal lookup table, the multilayer mirror coating, and the attenuator transmission-vs-foil table? dodal exposes the axes, not the calibrated values. | The optic internals are settings / a bound Model / a Calibration on the existing Families. | The optic calibration. |
+| MACHINE-1 | Nice-to-have | How should the storage-ring state be modelled: loose `StorageRing`, observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
+| ATTN-1 | Nice-to-have | Are the ATTN-01 three-stick stage and the ATTN-02 transmission selector two physically distinct attenuator stations, or two control surfaces of one unit? | Two distinct stations (separate EPICS roots), the selector folding into Filter via Indexable named positions. | The attenuator station topology. |
+
+### Sample, detector, technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| FLUX-1 | Blocks-go-live | How is the incident-flux monitor (the JBPM TetrAMM i0) modelled, and what beam-center calibration does it need? | The existing Sensor Role, via the `FluxMonitor` catalog Family (graduated on the i22/i03/i15-1 rule-of-three this deployment completes). | The flux-monitor modelling and beam-center. |
+| ROBOT-1 | Blocks-go-live | What is the powder/capillary sample-changing robot, how is autonomous loading gated, and what is the puck custody lifecycle? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance, vendor in a bound Model (the I03 / 19-BM shape); not a new Family. | The robot Asset, its Clearance gate, and the Subject custody thread. |
+| DET-1 | Blocks-go-live | What are the Eiger threshold energy and beam-center, the two-theta arm geometry, and the second detector translation ranges? | The Eiger reuses `Camera`; calibration to supply. | The detector calibration and arm geometry. |
+| TECH-1 | Blocks-go-live | What are the total-scattering / PDF Capability and Methods (binding the mono + Eiger + two-theta arm + the powder robot exchange)? | A new total-scattering Capability not yet in the catalog, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
+| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags)? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i15-1/questions.md b/docs/deployments/i15-1/questions.md
deleted file mode 100644
index 175af849288..00000000000
--- a/docs/deployments/i15-1/questions.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Open questions
-
-*What CORA needs the I15-1 team (and Diamond's documentation) to confirm before the model can be trusted.*
-
-I15-1 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles; it does not give the calibrated numbers, the hutch / PSS safety meaning, or the Capability / Method binding. This is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Scope, safety, and the modelling decisions
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is I15-1 (or any Diamond beamline) actually intended to enter CORA scope, or is this a generalization exercise? | A generalization exercise; not on the pilot roadmap. | Whether Diamond is a real Site or a modelling fixture. |
-| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the two hutches? dodal records interlock readbacks (BL15I-PS-IOC-02:M11:LOP, BL15I-VA-OMRON-01:INT3:ILK) but not confirmed permits. | Both hutches exist; the dodal interlock readbacks are permit-signal candidates. | The Enclosure permit signals. |
-| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones, not the access-gated hutch. | The standard optics + experiment hutch split. | The per-device Enclosure assignment. |
-| INTERLOCK-1 | Nice-to-have | Are the PSS / gonio interlocks correctly modelled as the Enclosure `permit_signal` (not as equipment devices)? | Yes: an interlock is the read-only permit behind the Enclosure aggregate, not an Asset. | That interlocks stay on the Enclosure, not the device walk. |
-| SAFEBEAM-1 | Blocks-go-live | Are the blower / cobra / cryostream correctly modelled as Positioner + Indexable SAFE/BEAM (not TemperatureController), and is the cobra/cryostream rail-interchange a Fixture-style swap or an Assembly? | Positioner with two named positions; the interchange is a Fixture-style swap (they share the ENV:X rail motor). | The sample-environment actuator shape and the exchange modelling. |
-| RAIL-1 | Nice-to-have | Is the rail correctly the existing Table Family, and what are its exchange semantics? | The existing Table Family (the TomoWISE DetectorGantry precedent), not a new Rail kind. | The rail Family and exchange shape. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What is the I15-1 source (it is a branch line) and its energy range? dodal does not pin it. | A source carried `confirm`; energy range is calibration to supply. | The source and beamline energy range. |
-| ENERGY-1 | Blocks-go-live | Is the bent-Laue energy ever a goto-command (driving y to hit a target energy via inverse lookup), or only the fixed-selection read-only readback dodal exposes? | A read-only y-to-energy lookup readback; the pending energy_scan Capability is NOT earnable here. | Whether energy is a commandable axis and whether energy_scan applies. |
-| OPT-1 | Nice-to-have | What are the bent-Laue crystal lookup table, the multilayer mirror coating, and the attenuator transmission-vs-foil table? dodal exposes the axes, not the calibrated values. | The optic internals are settings / a bound Model / a Calibration on the existing Families. | The optic calibration. |
-| MACHINE-1 | Nice-to-have | How should the storage-ring state be modelled: loose `StorageRing`, observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, reused from I22. | The machine-state modelling boundary. |
-| ATTN-1 | Nice-to-have | Are the ATTN-01 three-stick stage and the ATTN-02 transmission selector two physically distinct attenuator stations, or two control surfaces of one unit? | Two distinct stations (separate EPICS roots), the selector folding into Filter via Indexable named positions. | The attenuator station topology. |
-
-## Sample, detector, technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| FLUX-1 | Blocks-go-live | How is the incident-flux monitor (the JBPM TetrAMM i0) modelled, and what beam-center calibration does it need? | The existing Sensor Role, via the `FluxMonitor` catalog Family (graduated on the i22/i03/i15-1 rule-of-three this deployment completes). | The flux-monitor modelling and beam-center. |
-| ROBOT-1 | Blocks-go-live | What is the powder/capillary sample-changing robot, how is autonomous loading gated, and what is the puck custody lifecycle? | One Positioner-presenting Asset loading / unloading a `Subject`, gated by a Clearance, vendor in a bound Model (the I03 / 19-BM shape); not a new Family. | The robot Asset, its Clearance gate, and the Subject custody thread. |
-| DET-1 | Blocks-go-live | What are the Eiger threshold energy and beam-center, the two-theta arm geometry, and the second detector translation ranges? | The Eiger reuses `Camera`; calibration to supply. | The detector calibration and arm geometry. |
-| TECH-1 | Blocks-go-live | What are the total-scattering / PDF Capability and Methods (binding the mono + Eiger + two-theta arm + the powder robot exchange)? | A new total-scattering Capability not yet in the catalog, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
-| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags)? dodal carries none. | Assets carry no part / serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i15-1/techniques.md b/docs/deployments/i15-1/techniques.md
deleted file mode 100644
index 5599a83409b..00000000000
--- a/docs/deployments/i15-1/techniques.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Techniques
-
-*What I15-1 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I15-1 does total scattering / pair distribution function (PDF), a new science domain for CORA. Which Methods enter scope is an open question (TECH-1).
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Total scattering / PDF | fixed-energy, bent-Laue mono | `Eiger` (Detector Role), wide-Q on the two-theta arm | new Capability, pending (TECH-1) |
-| Autonomous powder/capillary exchange | n/a | n/a | a Procedure over the spine + a Subject custody thread, pending (ROBOT-1) |
-
-A few points of intent shape the model:
-
-- **Total scattering is a new Capability, not a new device shape.** A PDF measurement captures wide-Q scattering on the Eiger across the two-theta arm at a fixed high energy. The device Roles already exist (Camera presents Detector, the mono and arm present Positioner); what is new is the science Capability binding them. Carried pending on the [Diamond Practices](../diamond/index.md) (TECH-1).
-- **Energy scanning is explicitly NOT in scope here.** I15-1's bent-Laue monochromator selects a fixed energy: dodal exposes `energy_kev` as a read-only readback derived from the crystal y position via a lookup table, not a commanded or swept axis. So the pending `energy_scan` Capability is **not** earnable from I15-1's source; it must wait for a tunable XAS/EXAFS beamline whose scanning monochromator is actually instantiated in dodal (ENERGY-1).
-- **The autonomous loop reuses the I03 shape.** The powder/capillary robot exchange is a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the I03 MX loop, with a powder/capillary twist instead of MX pins (ROBOT-1).
-
-The concrete recipes (q-ranges, exposure, the exchange sequence) are calibration the deployment must supply. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/i19/governance.md b/docs/deployments/i19/governance.md
deleted file mode 100644
index b7af390f401..00000000000
--- a/docs/deployments/i19/governance.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Governance
-
-*Who would act at i19 and the trust shape that would gate it. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Not yet instantiated (scaffold).*
-
-Governance at i19 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape: a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what. The human roster is not in the dodal module (GOV-1), so the principals below are the design shape, not a registered list.
-
-Because i19 is a scaffold, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety state that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them.
-
-## Who acts
-
-The Diamond operator pool runs an i19 beamtime, with a beamline scientist and a safety reviewer in the facility-wide review chain. These are the Diamond facility principals, carried pending at the [Diamond Site page](../diamond/index.md#safety-and-governance); i19 inherits them rather than coining its own (GOV-1). The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## The trust boundary
-
-i19's boundary is shaped by the Trust BC aggregates (Zone, Conduit, Policy); the [Trust module](../../architecture/modules/trust/index.md) defines what each one is. This page records only the intended i19 instances, all pending until the beamline approaches real scope.
-
-| Zone | Conduit | Endpoints |
-| --- | --- | --- |
-| `i19 Zone` | `i19 Local Conduit` | `i19 Zone` -> `i19 Zone` |
-
-A Policy governs who may issue which command across a Conduit.
-
-| Policy | Permitted principals | Permitted commands |
-| --- | --- | --- |
-| `i19 Operations Policy` | Diamond operator pool (GOV-1) | Operator-driven commands (Equipment, Recipe, Operation, Run, Subject, Dataset, Caution, Clearance, Supply, Campaign) |
-| `i19 Agent Policy` | Diamond agent principals (GOV-1) | Decision family: `RegisterDecision`, `RateDecision`, `AppendInferences` |
-
-## The safety envelope
-
-i19 inherits the Diamond [safety envelope](../diamond/index.md#safety-and-governance). The one safety signal CORA can name today is the dodal interlocked optics shutter (`OpticsShutter`, BL19I-PS-SHTR-01), which is PSS-interlocked and bound to the Shutter family. Beyond that, the PSS search-and-secure permit signals per hutch are pending and are not invented (PSS-1). Clearances are issued at the Diamond Site and the beamline links up to them.
-
-## The active-hutch permit (ACCESS-1)
-
-i19 has two experiment hutches in series, EH1 (`i19-1`) and EH2 (`i19-2`), that share one optics line (`i19-optics`, the shared BL19I optics). This is the i19-specific governance element, and it is the genuine novelty of the deployment: only the **active** hutch may drive the shared optics. A non-active hutch may still observe the shared optics state, but it may not move them.
-
-dodal expresses this with a central arbiter, the i19-blueapi optics service. A hutch reads the shared-optics state directly over EPICS, but its writes (change the energy, operate the experiment shutter, move the attenuator, set a mirror piezo) are posted to the arbiter. The arbiter compares the requesting hutch against the active-hutch readback (BL19I-OP-STAT-01:EHStatus) and runs or rejects.
-
-CORA models this as an **Enclosure-permit plus Trust-gate** over the shared-optics Assets, not as a device family (ACCESS-1):
-
-- The Enclosure-permit is the active-hutch state itself: of the two Enclosures `i19-1` and `i19-2`, the one currently holding the permit is the only one whose commands against the shared `i19-optics` Assets may proceed (ENC-1).
-- The Trust-gate is the Policy condition layered on the shared-optics commands: a command to change energy (`BeamEnergy`, the coordinated DCM plus undulator plus mirror-stripe move, MONO-1), operate the optics shutter (PSS-1), move the attenuator (`Attenuator`, the i03 precedent, ATTN-1), or set a focusing-mirror piezo (`HorizontalFocusingMirror` / `VerticalFocusingMirror`, with its hutch-keyed coating stripe Si 5-10 / Rh 10-20 / Pt 20-30 keV, OPT-1) is admitted only from the hutch that holds the permit.
-- The i19-blueapi arbiter is the **actuate-floor seam** partner, the same "EPICS is the floor" pattern the rest of the Diamond fleet follows, here a blueapi-arbiter floor. CORA's gate decides whether the command is authorized; the arbiter remains the floor that compares the requesting hutch against the active-hutch readback and runs or rejects against EPICS.
-
-The shared-optics devices are single Assets, access-gated rather than duplicated per hutch: the monochromator (DCM, MONO-1), the two focusing mirrors (OPT-1), the attenuator (ATTN-1), the coordinated `BeamEnergy` pseudo-axis (MONO-1), and the optics shutter (PSS-1) all live in `i19-optics` and are reached through the permit. The undulator (`Undulator`, SR19I-MO-SERVC-01) is coordinated with the DCM on an energy move (SRC-1); the storage ring is observe-only machine state (MACHINE-1).
-
-None of this is instantiated yet. The Zone, Conduit, and Policy instances, the Diamond operator pool, and the active-hutch permit gate would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i19/model.md b/docs/deployments/i19/model.md
deleted file mode 100644
index 1560dc31f67..00000000000
--- a/docs/deployments/i19/model.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's i19 content lives, why the four-circle is not the novelty and the dual-hutch access-control seam is, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at i19 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy PseudoAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes i19 new (and what does not)
-
-i19 is CORA's first chemical (small-molecule) single-crystal crystallography beamline. The fleet's other diffraction-imaging crystallography is all macromolecular MX (I03, I24, FMX, MX3); i19 solves small-molecule structures on a Newport kappa four-circle goniometer with an Eiger detector, plus a serial / microfocus fixed-target arm.
-
-The honest framing: the instrument is **not** the novelty. The kappa four-circle is plain catalog `Goniometer` reuse:
-
-- The catalog `Goniometer` note states that **chi-versus-kappa and axis-count are a per-Asset setting, not a Family split**. So the phi / omega / kappa sample circles bind the catalog `Goniometer`, exactly as the i03 Smargon and the MX3 mini-kappa do.
-- The larger four-circle (the goniometer plus the 2theta detector arm plus a reciprocal-space axis) composes the catalog `Assembly(Diffractometer)`, the 8-ID / 4-ID / i06-1 pattern, named-not-built in descriptor mode (`DIFF-1`, `DIFF-2`).
-- The single-crystal diffraction technique reuses the pending `diffraction` Method that 4-ID, 8-ID, and CSX already share; chemical-versus-magnetic single crystal is a Practice-level science difference, not a new Method (`TECH-1`).
-
-What **is** genuinely new is the governance seam, below. i19 coins no new Family and changes nothing in the catalog.
-
-## The dual-hutch access-control seam
-
-i19 has two experiment hutches in series (EH1 and EH2) that share one optics line, and only the active hutch may drive the shared optics. dodal expresses this through a central arbiter (the i19-blueapi optics service): a hutch reads the shared-optics state directly over EPICS, but its writes (change energy, operate the experiment shutter, move the attenuator, set a mirror piezo) are posted to the arbiter, which compares the requesting hutch against the active-hutch readback (`BL19I-OP-STAT-01:EHStatus`) and runs or rejects the operation.
-
-CORA models this without a new device family:
-
-- **The shared-optics devices are single Assets** in the `i19-optics` enclosure (the `Monochromator`, `Undulator`, the two `Mirror`s, the `Filter` attenuator, the `Shutter`). A non-active hutch reading them read-only is the same Asset surfaced through a permit, not a second Asset.
-- **The active-hutch permit is an Enclosure-permit + Trust-gate.** EH1 and EH2 are two `Enclosure`s; which one may drive the shared optics now is a permit axis on the Enclosure, governed by Trust authorization. The `BL19I-OP-STAT-01:EHStatus` readback is the read-model of that permit (`ACCESS-1`).
-- **The i19-blueapi arbiter is an actuate-floor seam partner.** It is the same shape as the "EPICS is the floor" seam, here a blueapi-arbiter floor: today it performs the active-hutch arbitration; CORA's edge would conduct the run over its `ControlPort`, either driving through the arbiter or replacing its plan-orchestration per routine, a seam decision not pre-empted here.
-
-This is the design-interesting content of i19: an Enclosure-permit-gated actuate seam, the first dual-hutch shared-optics arbitration in the fleet. The concrete Enclosure-permit, Trust, and seam instances are named, not built, in this scaffold.
-
-## No new families
-
-Beyond the four-circle (Goniometer) and the MAPT aperture (below), the rest reuse the catalog directly: the DCM binds `Monochromator`; the focusing mirrors bind `Mirror` (the coating stripe is a hutch-keyed setting); the attenuator binds `Filter` (the i03 precedent); the undulator binds `InsertionDevice`; the Eiger and the OAV viewing cameras bind `Camera`; the Zebra and PandA hardware triggers bind `TimingController`; the serial / microfocus arm binds a second `Goniometer`; the beamstops bind `BeamStop`; the shutter binds `Shutter`; the incident energy is a `PseudoAxis`. The machine state reuses the loose `StorageRing`.
-
-- **The MAPT pinhole and collimator bind the catalog `Aperture` (`APERTURE-1`).** This follows the i03 ApertureScatterguard-at-MAPT precedent: the consumer-facing beam-defining Asset binds `Aperture`, composing the pinhole and collimator XY stages, with the configuration aperture sizes as a Capability settings schema. The discriminator tension (the catalog `Aperture` describes a fixed code pattern, while the MAPT is a driven, size-selectable opening) is carried as `APERTURE-1`; the i03 sibling, the same controls stack and the same MAPT, already binds `Aperture`, so i19 follows it.
-
-- **The sample backlight binds the catalog `Backlight` Family.** i03, i24, and fmx already bind it; i19 is a further consumer of the illumination affordance now graduated across the MX / imaging fleet (`DET-1`). i19 adds a consumer, not a new Family.
-
-## Deliberately not here yet
-
-- **The Assembly(Diffractometer) and the reciprocal-space rule (`DIFF-1`, `DIFF-2`).** Named, not built, exactly as 4-ID, 8-ID, and i06-1 deferred theirs. The 2theta detector arm is a `RotaryStage` slot of the Assembly; det_z folds as a per-Asset axis on the arm (the i06-1 precedent).
-- **The serial / microfocus raster (`SERIAL-1`).** The fixed-target arm binds a second `Goniometer`; the raster sub-mode (which would touch a grid-scan-style Method that the catalog does not yet carry) is carried as a note, not modelled.
-- **The Enclosure-permit + Trust-gate + actuate seam instances (`ACCESS-1`).** The dual-hutch access-control is described above and is the governance novelty, but the concrete Zone / Conduit / Policy and the arbiter-seam drive-through-versus-replace decision are named, not built, in this scaffold.
-- **The diffraction Method.** Whether single-crystal diffraction enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending, reusing the slug 4-ID / 8-ID / CSX share (`TECH-1`).
-- **The centring image-recognition behaviour and the simulated devices.** The OAV pin-tip recognition is a Method behaviour on the Camera, not a device; no `test_i19_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i19/notes.md b/docs/deployments/i19/notes.md
new file mode 100644
index 00000000000..4b4514aa0ba
--- /dev/null
+++ b/docs/deployments/i19/notes.md
@@ -0,0 +1,188 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of i19 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i19 is CORA's first *chemical* crystallography beamline: small-molecule single-crystal structure solution, distinct from the macromolecular MX (I03, I24, FMX, MX3) the rest of the fleet carries. The function view below is written before the Method is coined, because it survives the eventual catalog vocabulary choice.
+
+### Single-crystal diffraction
+
+The Newport kappa four-circle goniometer orients a single crystal in the monochromatic or variable-wavelength beam, sweeps reciprocal space, and the Eiger records the scattered intensity as a function of momentum transfer. This is the same diffraction function the magnetic single-crystal stations already do; what differs at i19 is the science the data feed, not the recipe.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Single-crystal diffraction | `diffraction` | reciprocal-space scans on the kappa four-circle with the Eiger; shares the 4-ID / 8-ID / CSX `diffraction` Method, pending (TECH-1) |
+| Variable-wavelength diffraction | `diffraction` | the same Method over a coordinated energy move; a Plan / settings difference, not a new Method (TECH-1) |
+
+This needs the [diffractometer](sample.md) (the kappa four-circle, plus the 2-theta detector arm and det_z), the [Eiger detector](sample.md), and the shared-optics energy control. A few points of intent shape how the Method binds here:
+
+- **Single-crystal diffraction reuses the pending `diffraction` Method.** The prior consumers are the magnetic single-crystal stations (4-ID, 8-ID, CSX); i19 is a fourth consumer of the same recipe. The Method binds a Goniometer that orients the crystal and a Camera that captures the diffracted frames. Chemical crystallography (small-molecule structure solution) versus the magnetic single-crystal science at 4-ID is a **Practice-level** difference, not a Method-level one: the I19_diffraction_practice (pending) is where the chemical adaptation lives, over the portable diffraction Method (TECH-1).
+- **The kappa four-circle is plain Goniometer reuse.** kappa is a setting per the catalog Goniometer note, so the four-circle does not earn a new Family. The larger four-circle (phi / omega / kappa, the 2-theta arm, det_z, sample-centring) is the named-not-built `Assembly(Diffractometer)` composed over that Goniometer (DIFF-1). The reciprocal-space coordination binds `PseudoAxis` (DIFF-2).
+
+### Serial / microfocus fixed-target delivery
+
+i19 carries a serial / microfocus fixed-target arm: a second sample stage (x / y / z / phi) that presents many crystals to a microfocused beam on a fixed target. This is a **delivery sub-mode** of single-crystal diffraction, not a separate technique. It binds the same `diffraction` Method, with the second stage modelled as a second Goniometer (SERIAL-1).
+
+| Delivery | Catalog method | Notes |
+| --- | --- | --- |
+| Fixed-target serial collection | `diffraction` | many crystals on the serial stage; the same Method, a delivery sub-mode (SERIAL-1) |
+
+The one part that reaches past the present catalog is the **raster**: stepping the fixed target through a grid of positions and collecting at each would touch a grid-scan-style Method the catalog does not yet carry. Until that Method exists, the raster is carried as a note on the serial sub-mode, not modelled as its own recipe (SERIAL-1). The microfocused beam is shaped by the [MAPT pinhole and collimator](sample.md), whose aperture sizes are a Capability settings schema (the i03 MAPT precedent) (APERTURE-1).
+
+### Not modelled yet
+
+The concrete acquisition recipes are deferred: oscillation and scan ranges, exposures, the variable-wavelength sequence, and the serial raster pattern are calibration the deployment must supply, and writing them now for an unmodelled beamline would be invention, not record. They join as the deployment approaches the point where CORA drives i19.
+
+Whether the `diffraction` Method (and the grid-scan-style Method the raster would need) enters CORA's catalog at all is an owner-scope decision, recorded on [Model](#model); the raster's catalog gap is SERIAL-1 and the Method-coin question is TECH-1. See [Open questions](#open-questions) for the world-facts to confirm first, including which hutch holds the four-circle (ENC-1).
+
+## Governance
+
+*Who would act at i19 and the trust shape that would gate it. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Not yet instantiated (scaffold).*
+
+Governance at i19 follows the same model as the other Diamond beamlines: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape: a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what. The human roster is not in the dodal module (GOV-1), so the principals below are the design shape, not a registered list.
+
+Because i19 is a scaffold, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety state that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them.
+
+### Who acts
+
+The Diamond operator pool runs an i19 beamtime, with a beamline scientist and a safety reviewer in the facility-wide review chain. These are the Diamond facility principals, carried pending at the [Diamond Site page](../diamond/index.md#safety-and-governance); i19 inherits them rather than coining its own (GOV-1). The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### The trust boundary
+
+i19's boundary is shaped by the Trust BC aggregates (Zone, Conduit, Policy); the [Trust module](../../architecture/modules/trust/index.md) defines what each one is. This page records only the intended i19 instances, all pending until the beamline approaches real scope.
+
+| Zone | Conduit | Endpoints |
+| --- | --- | --- |
+| `i19 Zone` | `i19 Local Conduit` | `i19 Zone` -> `i19 Zone` |
+
+A Policy governs who may issue which command across a Conduit.
+
+| Policy | Permitted principals | Permitted commands |
+| --- | --- | --- |
+| `i19 Operations Policy` | Diamond operator pool (GOV-1) | Operator-driven commands (Equipment, Recipe, Operation, Run, Subject, Dataset, Caution, Clearance, Supply, Campaign) |
+| `i19 Agent Policy` | Diamond agent principals (GOV-1) | Decision family: `RegisterDecision`, `RateDecision`, `AppendInferences` |
+
+### The safety envelope
+
+i19 inherits the Diamond [safety envelope](../diamond/index.md#safety-and-governance). The one safety signal CORA can name today is the dodal interlocked optics shutter (`OpticsShutter`, BL19I-PS-SHTR-01), which is PSS-interlocked and bound to the Shutter family. Beyond that, the PSS search-and-secure permit signals per hutch are pending and are not invented (PSS-1). Clearances are issued at the Diamond Site and the beamline links up to them.
+
+### The active-hutch permit (ACCESS-1)
+
+i19 has two experiment hutches in series, EH1 (`i19-1`) and EH2 (`i19-2`), that share one optics line (`i19-optics`, the shared BL19I optics). This is the i19-specific governance element, and it is the genuine novelty of the deployment: only the **active** hutch may drive the shared optics. A non-active hutch may still observe the shared optics state, but it may not move them.
+
+dodal expresses this with a central arbiter, the i19-blueapi optics service. A hutch reads the shared-optics state directly over EPICS, but its writes (change the energy, operate the experiment shutter, move the attenuator, set a mirror piezo) are posted to the arbiter. The arbiter compares the requesting hutch against the active-hutch readback (BL19I-OP-STAT-01:EHStatus) and runs or rejects.
+
+CORA models this as an **Enclosure-permit plus Trust-gate** over the shared-optics Assets, not as a device family (ACCESS-1):
+
+- The Enclosure-permit is the active-hutch state itself: of the two Enclosures `i19-1` and `i19-2`, the one currently holding the permit is the only one whose commands against the shared `i19-optics` Assets may proceed (ENC-1).
+- The Trust-gate is the Policy condition layered on the shared-optics commands: a command to change energy (`BeamEnergy`, the coordinated DCM plus undulator plus mirror-stripe move, MONO-1), operate the optics shutter (PSS-1), move the attenuator (`Attenuator`, the i03 precedent, ATTN-1), or set a focusing-mirror piezo (`HorizontalFocusingMirror` / `VerticalFocusingMirror`, with its hutch-keyed coating stripe Si 5-10 / Rh 10-20 / Pt 20-30 keV, OPT-1) is admitted only from the hutch that holds the permit.
+- The i19-blueapi arbiter is the **actuate-floor seam** partner, the same "EPICS is the floor" pattern the rest of the Diamond fleet follows, here a blueapi-arbiter floor. CORA's gate decides whether the command is authorized; the arbiter remains the floor that compares the requesting hutch against the active-hutch readback and runs or rejects against EPICS.
+
+The shared-optics devices are single Assets, access-gated rather than duplicated per hutch: the monochromator (DCM, MONO-1), the two focusing mirrors (OPT-1), the attenuator (ATTN-1), the coordinated `BeamEnergy` pseudo-axis (MONO-1), and the optics shutter (PSS-1) all live in `i19-optics` and are reached through the permit. The undulator (`Undulator`, SR19I-MO-SERVC-01) is coordinated with the DCM on an energy move (SRC-1); the storage ring is observe-only machine state (MACHINE-1).
+
+None of this is instantiated yet. The Zone, Conduit, and Policy instances, the Diamond operator pool, and the active-hutch permit gate would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's i19 content lives, why the four-circle is not the novelty and the dual-hutch access-control seam is, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at i19 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy PseudoAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes i19 new (and what does not)
+
+i19 is CORA's first chemical (small-molecule) single-crystal crystallography beamline. The fleet's other diffraction-imaging crystallography is all macromolecular MX (I03, I24, FMX, MX3); i19 solves small-molecule structures on a Newport kappa four-circle goniometer with an Eiger detector, plus a serial / microfocus fixed-target arm.
+
+The honest framing: the instrument is **not** the novelty. The kappa four-circle is plain catalog `Goniometer` reuse:
+
+- The catalog `Goniometer` note states that **chi-versus-kappa and axis-count are a per-Asset setting, not a Family split**. So the phi / omega / kappa sample circles bind the catalog `Goniometer`, exactly as the i03 Smargon and the MX3 mini-kappa do.
+- The larger four-circle (the goniometer plus the 2theta detector arm plus a reciprocal-space axis) composes the catalog `Assembly(Diffractometer)`, the 8-ID / 4-ID / i06-1 pattern, named-not-built in descriptor mode (`DIFF-1`, `DIFF-2`).
+- The single-crystal diffraction technique reuses the pending `diffraction` Method that 4-ID, 8-ID, and CSX already share; chemical-versus-magnetic single crystal is a Practice-level science difference, not a new Method (`TECH-1`).
+
+What **is** genuinely new is the governance seam, below. i19 coins no new Family and changes nothing in the catalog.
+
+### The dual-hutch access-control seam
+
+i19 has two experiment hutches in series (EH1 and EH2) that share one optics line, and only the active hutch may drive the shared optics. dodal expresses this through a central arbiter (the i19-blueapi optics service): a hutch reads the shared-optics state directly over EPICS, but its writes (change energy, operate the experiment shutter, move the attenuator, set a mirror piezo) are posted to the arbiter, which compares the requesting hutch against the active-hutch readback (`BL19I-OP-STAT-01:EHStatus`) and runs or rejects the operation.
+
+CORA models this without a new device family:
+
+- **The shared-optics devices are single Assets** in the `i19-optics` enclosure (the `Monochromator`, `Undulator`, the two `Mirror`s, the `Filter` attenuator, the `Shutter`). A non-active hutch reading them read-only is the same Asset surfaced through a permit, not a second Asset.
+- **The active-hutch permit is an Enclosure-permit + Trust-gate.** EH1 and EH2 are two `Enclosure`s; which one may drive the shared optics now is a permit axis on the Enclosure, governed by Trust authorization. The `BL19I-OP-STAT-01:EHStatus` readback is the read-model of that permit (`ACCESS-1`).
+- **The i19-blueapi arbiter is an actuate-floor seam partner.** It is the same shape as the "EPICS is the floor" seam, here a blueapi-arbiter floor: today it performs the active-hutch arbitration; CORA's edge would conduct the run over its `ControlPort`, either driving through the arbiter or replacing its plan-orchestration per routine, a seam decision not pre-empted here.
+
+This is the design-interesting content of i19: an Enclosure-permit-gated actuate seam, the first dual-hutch shared-optics arbitration in the fleet. The concrete Enclosure-permit, Trust, and seam instances are named, not built, in this scaffold.
+
+### No new families
+
+Beyond the four-circle (Goniometer) and the MAPT aperture (below), the rest reuse the catalog directly: the DCM binds `Monochromator`; the focusing mirrors bind `Mirror` (the coating stripe is a hutch-keyed setting); the attenuator binds `Filter` (the i03 precedent); the undulator binds `InsertionDevice`; the Eiger and the OAV viewing cameras bind `Camera`; the Zebra and PandA hardware triggers bind `TimingController`; the serial / microfocus arm binds a second `Goniometer`; the beamstops bind `BeamStop`; the shutter binds `Shutter`; the incident energy is a `PseudoAxis`. The machine state reuses the loose `StorageRing`.
+
+- **The MAPT pinhole and collimator bind the catalog `Aperture` (`APERTURE-1`).** This follows the i03 ApertureScatterguard-at-MAPT precedent: the consumer-facing beam-defining Asset binds `Aperture`, composing the pinhole and collimator XY stages, with the configuration aperture sizes as a Capability settings schema. The discriminator tension (the catalog `Aperture` describes a fixed code pattern, while the MAPT is a driven, size-selectable opening) is carried as `APERTURE-1`; the i03 sibling, the same controls stack and the same MAPT, already binds `Aperture`, so i19 follows it.
+
+- **The sample backlight binds the catalog `Backlight` Family.** i03, i24, and fmx already bind it; i19 is a further consumer of the illumination affordance now graduated across the MX / imaging fleet (`DET-1`). i19 adds a consumer, not a new Family.
+
+### Deliberately not here yet
+
+- **The Assembly(Diffractometer) and the reciprocal-space rule (`DIFF-1`, `DIFF-2`).** Named, not built, exactly as 4-ID, 8-ID, and i06-1 deferred theirs. The 2theta detector arm is a `RotaryStage` slot of the Assembly; det_z folds as a per-Asset axis on the arm (the i06-1 precedent).
+- **The serial / microfocus raster (`SERIAL-1`).** The fixed-target arm binds a second `Goniometer`; the raster sub-mode (which would touch a grid-scan-style Method that the catalog does not yet carry) is carried as a note, not modelled.
+- **The Enclosure-permit + Trust-gate + actuate seam instances (`ACCESS-1`).** The dual-hutch access-control is described above and is the governance novelty, but the concrete Zone / Conduit / Policy and the arbiter-seam drive-through-versus-replace decision are named, not built, in this scaffold.
+- **The diffraction Method.** Whether single-crystal diffraction enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending, reusing the slug 4-ID / 8-ID / CSX share (`TECH-1`).
+- **The centring image-recognition behaviour and the simulated devices.** The OAV pin-tip recognition is a Method behaviour on the Camera, not a device; no `test_i19_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the i19 team to confirm before the model can be trusted.*
+
+i19 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i19*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology, scope, and the dual-hutch seam
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The EH1 / EH2 grouping: which experiment hutch holds the four-circle and the Eiger, and which holds the on-axis viewing, and how the two hutches sit relative to the shared optics. | A shared `i19-optics` zone feeding two experiment hutches `i19-1` (EH1) and `i19-2` (EH2); the four-circle in EH2. | The Enclosure grouping. |
+| ACCESS-1 | Blocks-go-live | The dual-hutch shared-optics access-control: only the active hutch may drive the shared optics, enforced by the i19-blueapi optics arbiter against the active-hutch readback (`BL19I-OP-STAT-01:EHStatus`). How should CORA represent the active-hutch permit and the arbiter? | An Enclosure-permit + Trust-gate over the shared-optics Assets, with the arbiter as an actuate-floor seam partner (the "EPICS is the floor" pattern). | The governance seam; the CORA modelling is on [Model](#the-dual-hutch-access-control-seam). |
+| SRC-1 | Nice-to-have | The undulator period and type (`SR19I-MO-SERVC-01`). | An undulator coordinated with the DCM on an energy move; period pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state i19 reads (current, fill). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The DCM crystal cut, the energy / wavelength range, and the energy partition rule (the variable-wavelength capability). | A double-crystal `Monochromator`; the energy is a `PseudoAxis` over the DCM and undulator; range pending. | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The focusing-mirror coatings and the stripe energy bands (Si / Rh / Pt), and whether the stripe is hutch-keyed. | Focusing mirrors bound to `Mirror`; coating stripe a hutch-keyed setting (Si 5-10, Rh 10-20, Pt 20-30 keV). | The mirror Asset detail. |
+| ATTN-1 | Nice-to-have | The absorber-wedge attenuator and whether it folds into `Filter` or earns a distinct `Attenuator` kind (the fleet-wide question). | The wedge absorber bound to `Filter` (the i03 precedent). | The attenuator's catalog home. |
+
+### Endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The Newport kappa four-circle circle roles (phi / omega / kappa sample circles, the 2theta detector arm, det_z, the sample centring) and whether they compose an Assembly. | A `Goniometer` (kappa a setting) plus a 2theta detector arm; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the four-circle (the kappa-to-eulerian / hkl rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / i06-1. | The reciprocal-space Asset. |
+| SERIAL-1 | Nice-to-have | The serial / microfocus fixed-target arm (`BL19I-MO-SRL-01`, x / y / z / phi) and its raster sub-mode. | A second `Goniometer` for the serial / microfocus delivery; the fixed-target raster carried as a note. | The serial-arm modelling. |
+| APERTURE-1 | Nice-to-have | The MAPT pinhole + collimator microfocus aperture and whether it binds `Aperture` (the i03 MAPT precedent) despite being a driven, size-selectable opening. | The pinhole + collimator bound to `Aperture`, the configuration sizes a Capability settings schema. | The aperture Family. |
+| DET-1 | Blocks-go-live | The Eiger detector model, the OAV viewing-camera roles, the beamstops, and the backlight. | The Eiger and OAVs bind `Camera`; the beamstops bind `BeamStop`; the backlight binds the catalog `Backlight`. | The detector and viewing modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct, and is the i19-blueapi arbiter the live optics-control path? | The handles in the descriptor are taken from dodal and carried confirm; the arbiter is the actuate seam (ACCESS-1). | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal beyond the interlocked optics shutter). | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent of the shared optics. | Photon beam, cooling water, and vacuum on the optics. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does single-crystal diffraction (chemical crystallography) enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` Method that 4-ID / 8-ID / CSX share; none coined. | The diffraction Capability. |
diff --git a/docs/deployments/i19/questions.md b/docs/deployments/i19/questions.md
deleted file mode 100644
index 32f5ef06322..00000000000
--- a/docs/deployments/i19/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the i19 team to confirm before the model can be trusted.*
-
-i19 was reverse-engineered from the beamline's own bluesky device layer ([DiamondLightSource/dodal](https://github.com/DiamondLightSource/dodal): the `src/dodal/beamlines/i19*.py` factories and the `src/dodal/devices/` classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology, scope, and the dual-hutch seam
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The EH1 / EH2 grouping: which experiment hutch holds the four-circle and the Eiger, and which holds the on-axis viewing, and how the two hutches sit relative to the shared optics. | A shared `i19-optics` zone feeding two experiment hutches `i19-1` (EH1) and `i19-2` (EH2); the four-circle in EH2. | The Enclosure grouping. |
-| ACCESS-1 | Blocks-go-live | The dual-hutch shared-optics access-control: only the active hutch may drive the shared optics, enforced by the i19-blueapi optics arbiter against the active-hutch readback (`BL19I-OP-STAT-01:EHStatus`). How should CORA represent the active-hutch permit and the arbiter? | An Enclosure-permit + Trust-gate over the shared-optics Assets, with the arbiter as an actuate-floor seam partner (the "EPICS is the floor" pattern). | The governance seam; the CORA modelling is on [Model](model.md#the-dual-hutch-access-control-seam). |
-| SRC-1 | Nice-to-have | The undulator period and type (`SR19I-MO-SERVC-01`). | An undulator coordinated with the DCM on an energy move; period pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state i19 reads (current, fill). | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The DCM crystal cut, the energy / wavelength range, and the energy partition rule (the variable-wavelength capability). | A double-crystal `Monochromator`; the energy is a `PseudoAxis` over the DCM and undulator; range pending. | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The focusing-mirror coatings and the stripe energy bands (Si / Rh / Pt), and whether the stripe is hutch-keyed. | Focusing mirrors bound to `Mirror`; coating stripe a hutch-keyed setting (Si 5-10, Rh 10-20, Pt 20-30 keV). | The mirror Asset detail. |
-| ATTN-1 | Nice-to-have | The absorber-wedge attenuator and whether it folds into `Filter` or earns a distinct `Attenuator` kind (the fleet-wide question). | The wedge absorber bound to `Filter` (the i03 precedent). | The attenuator's catalog home. |
-
-## Endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The Newport kappa four-circle circle roles (phi / omega / kappa sample circles, the 2theta detector arm, det_z, the sample centring) and whether they compose an Assembly. | A `Goniometer` (kappa a setting) plus a 2theta detector arm; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| DIFF-2 | Nice-to-have | The reciprocal-space coordination over the four-circle (the kappa-to-eulerian / hkl rule). | A reciprocal-space `PseudoAxis` over the circles, the rule deferred as on 4-ID / 8-ID / i06-1. | The reciprocal-space Asset. |
-| SERIAL-1 | Nice-to-have | The serial / microfocus fixed-target arm (`BL19I-MO-SRL-01`, x / y / z / phi) and its raster sub-mode. | A second `Goniometer` for the serial / microfocus delivery; the fixed-target raster carried as a note. | The serial-arm modelling. |
-| APERTURE-1 | Nice-to-have | The MAPT pinhole + collimator microfocus aperture and whether it binds `Aperture` (the i03 MAPT precedent) despite being a driven, size-selectable opening. | The pinhole + collimator bound to `Aperture`, the configuration sizes a Capability settings schema. | The aperture Family. |
-| DET-1 | Blocks-go-live | The Eiger detector model, the OAV viewing-camera roles, the beamstops, and the backlight. | The Eiger and OAVs bind `Camera`; the beamstops bind `BeamStop`; the backlight binds the catalog `Backlight`. | The detector and viewing modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct, and is the i19-blueapi arbiter the live optics-control path? | The handles in the descriptor are taken from dodal and carried confirm; the arbiter is the actuate seam (ACCESS-1). | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (absent from dodal beyond the interlocked optics shutter). | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent of the shared optics. | Photon beam, cooling water, and vacuum on the optics. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does single-crystal diffraction (chemical crystallography) enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` Method that 4-ID / 8-ID / CSX share; none coined. | The diffraction Capability. |
diff --git a/docs/deployments/i19/techniques.md b/docs/deployments/i19/techniques.md
deleted file mode 100644
index e7be8bf0bf6..00000000000
--- a/docs/deployments/i19/techniques.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Techniques
-
-*What the modelled part of i19 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md#the-techniques-adapted-here) is how a facility adapts it. i19 is CORA's first *chemical* crystallography beamline: small-molecule single-crystal structure solution, distinct from the macromolecular MX (I03, I24, FMX, MX3) the rest of the fleet carries. The function view below is written before the Method is coined, because it survives the eventual catalog vocabulary choice.
-
-## Single-crystal diffraction
-
-The Newport kappa four-circle goniometer orients a single crystal in the monochromatic or variable-wavelength beam, sweeps reciprocal space, and the Eiger records the scattered intensity as a function of momentum transfer. This is the same diffraction function the magnetic single-crystal stations already do; what differs at i19 is the science the data feed, not the recipe.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Single-crystal diffraction | `diffraction` | reciprocal-space scans on the kappa four-circle with the Eiger; shares the 4-ID / 8-ID / CSX `diffraction` Method, pending (TECH-1) |
-| Variable-wavelength diffraction | `diffraction` | the same Method over a coordinated energy move; a Plan / settings difference, not a new Method (TECH-1) |
-
-This needs the [diffractometer](sample.md) (the kappa four-circle, plus the 2-theta detector arm and det_z), the [Eiger detector](sample.md), and the shared-optics energy control. A few points of intent shape how the Method binds here:
-
-- **Single-crystal diffraction reuses the pending `diffraction` Method.** The prior consumers are the magnetic single-crystal stations (4-ID, 8-ID, CSX); i19 is a fourth consumer of the same recipe. The Method binds a Goniometer that orients the crystal and a Camera that captures the diffracted frames. Chemical crystallography (small-molecule structure solution) versus the magnetic single-crystal science at 4-ID is a **Practice-level** difference, not a Method-level one: the I19_diffraction_practice (pending) is where the chemical adaptation lives, over the portable diffraction Method (TECH-1).
-- **The kappa four-circle is plain Goniometer reuse.** kappa is a setting per the catalog Goniometer note, so the four-circle does not earn a new Family. The larger four-circle (phi / omega / kappa, the 2-theta arm, det_z, sample-centring) is the named-not-built `Assembly(Diffractometer)` composed over that Goniometer (DIFF-1). The reciprocal-space coordination binds `PseudoAxis` (DIFF-2).
-
-## Serial / microfocus fixed-target delivery
-
-i19 carries a serial / microfocus fixed-target arm: a second sample stage (x / y / z / phi) that presents many crystals to a microfocused beam on a fixed target. This is a **delivery sub-mode** of single-crystal diffraction, not a separate technique. It binds the same `diffraction` Method, with the second stage modelled as a second Goniometer (SERIAL-1).
-
-| Delivery | Catalog method | Notes |
-| --- | --- | --- |
-| Fixed-target serial collection | `diffraction` | many crystals on the serial stage; the same Method, a delivery sub-mode (SERIAL-1) |
-
-The one part that reaches past the present catalog is the **raster**: stepping the fixed target through a grid of positions and collecting at each would touch a grid-scan-style Method the catalog does not yet carry. Until that Method exists, the raster is carried as a note on the serial sub-mode, not modelled as its own recipe (SERIAL-1). The microfocused beam is shaped by the [MAPT pinhole and collimator](sample.md), whose aperture sizes are a Capability settings schema (the i03 MAPT precedent) (APERTURE-1).
-
-## Not modelled yet
-
-The concrete acquisition recipes are deferred: oscillation and scan ranges, exposures, the variable-wavelength sequence, and the serial raster pattern are calibration the deployment must supply, and writing them now for an unmodelled beamline would be invention, not record. They join as the deployment approaches the point where CORA drives i19.
-
-Whether the `diffraction` Method (and the grid-scan-style Method the raster would need) enters CORA's catalog at all is an owner-scope decision, recorded on [Model](model.md); the raster's catalog gap is SERIAL-1 and the Method-coin question is TECH-1. See [Open questions](questions.md) for the world-facts to confirm first, including which hutch holds the four-circle (ENC-1).
diff --git a/docs/deployments/i20-1/governance.md b/docs/deployments/i20-1/governance.md
deleted file mode 100644
index d0c64f08a69..00000000000
--- a/docs/deployments/i20-1/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at I20-1 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [Diamond Site](../diamond/index.md); on the beamline they surface through the actions they take. The human roster is not in the dodal module (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Diamond Site. An I20-1 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may arm the detector, drive the turbo-slit fly-scan, change the energy selection, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Time-resolved collection
-
-EDE's reason for existing is speed: a full absorption spectrum in sub-second time, so a reaction can be followed as it runs. That makes the unattended, repeated, fast acquisition the place CORA's custody and trust shapes earn their keep, the engine holds the fly-scan and the detector arming while the trust boundary bounds what may change mid-series. If an autonomous Agent were added to trigger collections on a sample-environment cue or decide when a kinetic series is complete, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; with the dispersive detector still an open question (STRIP-1), this stays design intent.
diff --git a/docs/deployments/i20-1/model.md b/docs/deployments/i20-1/model.md
deleted file mode 100644
index 7e00b4caeed..00000000000
--- a/docs/deployments/i20-1/model.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I20-1 content lives. It hosts no content of its own. Design-phase scaffold, deliberately partial.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I20-1 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (I20-1-OH optics, I20-1-EH experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), and a deliberately partial one: the dodal commissioning module is thin. Left out on purpose:
-
-- **The dispersive heart of EDE.** The bent-crystal polychromator (POLY-1) and the position-sensitive strip detector (STRIP-1), the two devices that make the technique energy-dispersive, are not in the public source, so they are named open questions, not modelled. The polychromator would be a genuinely new optic class (an energy-fanning bent crystal, distinct from `Monochromator` / `GratingMonochromator`); CORA would weigh a `Polychromator` Family once it is PV-bound, not before. Coining it from no source PV would be invention.
-- **No new Family, no loose family.** What is modelled reuses existing families only: the turbo slit binds `Slit`, the PMAC `MotionController`, the PandA `TimingController`, the sample stage the graduated `Manipulator`, the Xspress3 the graduated `EnergyDispersiveSpectrometer`.
-- **The mock / skip honesty.** The sample stage is a dodal `mock` (real PVs, motors being reconnected, STAGE-1); the Xspress3 is a dodal `skip` (defined, not loaded by default, DET-1). Both are carried `confirm` and flagged, not asserted live.
-- **The absent source / optics / diagnostics chain.** No source, front-end, primary mirror, attenuator, ion chamber, flux monitor, or beam-position monitor is in the commissioning module; the source is carried PV-less (SRC-1) and the rest are open questions.
-- **No new Capability or Method.** Energy-dispersive EXAFS is a pending Practice on the Site (the dispersive complement to the BMM energy-scan question, TECH-1); MX3-style, the technique is reinforced-and-deferred, not coined.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive, and whose primary detector is not even in source, would be invention; they land when the dispersive devices are PV-bound and the team confirms.
diff --git a/docs/deployments/i20-1/notes.md b/docs/deployments/i20-1/notes.md
new file mode 100644
index 00000000000..4a7db133ce5
--- /dev/null
+++ b/docs/deployments/i20-1/notes.md
@@ -0,0 +1,95 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at I20-1: energy-dispersive EXAFS, a [Catalog](../../catalog/methods.md) Method bound through a [Diamond Practice](../diamond/index.md). It is the dispersive complement to the scanning-XAS axis, and its Capability is deferred, the more so because the dispersive devices are not yet in source.*
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Energy-dispersive EXAFS (EDE) | `energy_dispersive_exafs` | the whole absorption spectrum read in one shot off a polychromatic fan on a strip detector; time-resolved. New Capability, pending (TECH-1); the dispersive polychromator + strip detector are not yet in source (POLY-1 / STRIP-1) |
+| Fluorescence-yield EXAFS | `energy_dispersive_exafs` | the same dispersive acquisition read in fluorescence on the Xspress3, a secondary mode (DET-1) |
+
+The technique is recorded as a pending [Practice](../diamond/index.md) on the Diamond Site.
+
+### Why the Capability is deferred (and the heart is an open question)
+
+EDE is a new science Capability for CORA: scanning XAS (NSLS-II BMM) steps a monochromator through an edge and the per-energy readings are the data, while EDE reads every energy at once off a dispersed fan. CORA carries the EDE Method as pending, the dispersive complement to the energy-scan question BMM opened (TECH-1 / the ENERGY-1 cohort), rather than coining it, the same earn-the-abstraction discipline every new-domain technique follows.
+
+The sharper point at I20-1 is that the two devices the Capability turns on, the bent-crystal polychromator and the position-sensitive strip detector, are not in the public dodal commissioning module. So this is a partial first cut: the technique is named and its periphery modelled (the energy-selecting turbo slit, the fly-scan PMAC and PandA timing, the fluorescence Xspress3), but the dispersive optic and detector are explicit open questions (POLY-1, STRIP-1). The polychromator in particular would be a genuinely new optic class, an energy-fanning bent crystal distinct from a `Monochromator`, that CORA would weigh as a Family once it is PV-bound; coining it now, with no source PV, would be invention.
+
+The spectrum extraction (turning the dispersed strip frame into an absorption spectrum) is `ComputePort` work, not a beamline Method.
+
+## Governance
+
+*Who may act at I20-1 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [Diamond Site](../diamond/index.md); on the beamline they surface through the actions they take. The human roster is not in the dodal module (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Diamond Site. An I20-1 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may arm the detector, drive the turbo-slit fly-scan, change the energy selection, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The Diamond proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Time-resolved collection
+
+EDE's reason for existing is speed: a full absorption spectrum in sub-second time, so a reaction can be followed as it runs. That makes the unattended, repeated, fast acquisition the place CORA's custody and trust shapes earn their keep, the engine holds the fly-scan and the detector arming while the trust boundary bounds what may change mid-series. If an autonomous Agent were added to trigger collections on a sample-environment cue or decide when a kinetic series is complete, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; with the dispersive detector still an open question (STRIP-1), this stays design intent.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I20-1 content lives. It hosts no content of its own. Design-phase scaffold, deliberately partial.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I20-1 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (I20-1-OH optics, I20-1-EH experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), and a deliberately partial one: the dodal commissioning module is thin. Left out on purpose:
+
+- **The dispersive heart of EDE.** The bent-crystal polychromator (POLY-1) and the position-sensitive strip detector (STRIP-1), the two devices that make the technique energy-dispersive, are not in the public source, so they are named open questions, not modelled. The polychromator would be a genuinely new optic class (an energy-fanning bent crystal, distinct from `Monochromator` / `GratingMonochromator`); CORA would weigh a `Polychromator` Family once it is PV-bound, not before. Coining it from no source PV would be invention.
+- **No new Family, no loose family.** What is modelled reuses existing families only: the turbo slit binds `Slit`, the PMAC `MotionController`, the PandA `TimingController`, the sample stage the graduated `Manipulator`, the Xspress3 the graduated `EnergyDispersiveSpectrometer`.
+- **The mock / skip honesty.** The sample stage is a dodal `mock` (real PVs, motors being reconnected, STAGE-1); the Xspress3 is a dodal `skip` (defined, not loaded by default, DET-1). Both are carried `confirm` and flagged, not asserted live.
+- **The absent source / optics / diagnostics chain.** No source, front-end, primary mirror, attenuator, ion chamber, flux monitor, or beam-position monitor is in the commissioning module; the source is carried PV-less (SRC-1) and the rest are open questions.
+- **No new Capability or Method.** Energy-dispersive EXAFS is a pending Practice on the Site (the dispersive complement to the BMM energy-scan question, TECH-1); MX3-style, the technique is reinforced-and-deferred, not coined.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive, and whose primary detector is not even in source, would be invention; they land when the dispersive devices are PV-bound and the team confirms.
+
+## Open questions
+
+*What CORA needs the I20-1 team to confirm. This model is reverse-engineered from the public dodal controls library (`src/dodal/beamlines/p51.py`, the i20-1 commissioning module): the EPICS PVs are read from it, but it is a thin commissioning roster and the dispersive heart of EDE is not in it. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### The dispersive heart (absent from source)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| POLY-1 | Blocks-build | The bent-crystal polychromator that fans the energy band across the sample, the defining EDE optic. It is not in the dodal module (only the turbo slit at the polychromator enclosure `BL51P-OP-PCHRO-01` is). What are its PVs and axes (crystal bend, Bragg, position)? It is a genuinely new optic class (an energy-dispersing bent crystal, distinct from a Monochromator); CORA would weigh a new `Polychromator` Family once it is PV-bound. | Not modelled; named here, no Family coined without a source PV. | The polychromator Asset and a possible new Family. |
+| STRIP-1 | Blocks-build | The position-sensitive strip detector that reads the dispersed absorption spectrum in one shot, the EDE primary detector (e.g. an XH / germanium microstrip). It is not in the dodal module. What is its PV, and does it fit `Camera` (a 1D frame) or warrant a new detector class? | Not modelled; named here, no device coined without a source PV. | The strip-detector Asset and its family. |
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The insertion-device source, front-end, and primary mirror: none is in the commissioning module. The PV root `BL51P` would carry them. | An insertion-device source, identity-only, no PV. | The Source and front-optics Assets. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs (not in the dodal module). | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The hutch layout and names (the dodal module exposes no enclosure structure). | An optics hutch plus an experiment hutch. | The Enclosure set and roles. |
+
+### Sample, detector, controls
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The sample alignment stage axis set and reconnection: the dodal module constructs `alignment_x` / `alignment_y` (`BL51P-MO-STAGE-01:X` / `Y`) as a mock, noting the motors are being reconnected on the beamline. | A `Manipulator` Asset (X / Y); the PVs are real but not yet connected. | The SampleStage axes and live PVs. |
+| DET-1 | Nice-to-have | The Xspress3 fluorescence detector (`BL51P-EA-DET-03:`, 16-channel) is defined but constructed with `skip=True` in dodal (not loaded by default). Is it live, and what is the I0 / It / ion-chamber flux chain (none is in the module)? | One `EnergyDispersiveSpectrometer` Asset; flux chain blank. | The detector roster and flux monitors. |
+| DRIVE-1 | Blocks-go-live | The PMAC trajectory controller (`BL51P-MO-STEP-06:`) and PandA box (`BL51P-EA-PANDA-01/02:`) firmware / IPs. | Families bound (MotionController, TimingController), specifics blank. | The controller Models. |
+| TECH-1 | Blocks-go-live | Does the energy-dispersive-EXAFS Capability enter CORA's catalog, or stay deferred? It is the dispersive complement to the scanning-XAS / energy-scan question (the BMM ENERGY-1 cohort). | The EDE Method is a pending Practice, not yet in the catalog. | The EDE Capability scope. |
diff --git a/docs/deployments/i20-1/questions.md b/docs/deployments/i20-1/questions.md
deleted file mode 100644
index d93a4e93d46..00000000000
--- a/docs/deployments/i20-1/questions.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Open questions
-
-*What CORA needs the I20-1 team to confirm. This model is reverse-engineered from the public dodal controls library (`src/dodal/beamlines/p51.py`, the i20-1 commissioning module): the EPICS PVs are read from it, but it is a thin commissioning roster and the dispersive heart of EDE is not in it. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## The dispersive heart (absent from source)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| POLY-1 | Blocks-build | The bent-crystal polychromator that fans the energy band across the sample, the defining EDE optic. It is not in the dodal module (only the turbo slit at the polychromator enclosure `BL51P-OP-PCHRO-01` is). What are its PVs and axes (crystal bend, Bragg, position)? It is a genuinely new optic class (an energy-dispersing bent crystal, distinct from a Monochromator); CORA would weigh a new `Polychromator` Family once it is PV-bound. | Not modelled; named here, no Family coined without a source PV. | The polychromator Asset and a possible new Family. |
-| STRIP-1 | Blocks-build | The position-sensitive strip detector that reads the dispersed absorption spectrum in one shot, the EDE primary detector (e.g. an XH / germanium microstrip). It is not in the dodal module. What is its PV, and does it fit `Camera` (a 1D frame) or warrant a new detector class? | Not modelled; named here, no device coined without a source PV. | The strip-detector Asset and its family. |
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The insertion-device source, front-end, and primary mirror: none is in the commissioning module. The PV root `BL51P` would carry them. | An insertion-device source, identity-only, no PV. | The Source and front-optics Assets. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs (not in the dodal module). | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The hutch layout and names (the dodal module exposes no enclosure structure). | An optics hutch plus an experiment hutch. | The Enclosure set and roles. |
-
-## Sample, detector, controls
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The sample alignment stage axis set and reconnection: the dodal module constructs `alignment_x` / `alignment_y` (`BL51P-MO-STAGE-01:X` / `Y`) as a mock, noting the motors are being reconnected on the beamline. | A `Manipulator` Asset (X / Y); the PVs are real but not yet connected. | The SampleStage axes and live PVs. |
-| DET-1 | Nice-to-have | The Xspress3 fluorescence detector (`BL51P-EA-DET-03:`, 16-channel) is defined but constructed with `skip=True` in dodal (not loaded by default). Is it live, and what is the I0 / It / ion-chamber flux chain (none is in the module)? | One `EnergyDispersiveSpectrometer` Asset; flux chain blank. | The detector roster and flux monitors. |
-| DRIVE-1 | Blocks-go-live | The PMAC trajectory controller (`BL51P-MO-STEP-06:`) and PandA box (`BL51P-EA-PANDA-01/02:`) firmware / IPs. | Families bound (MotionController, TimingController), specifics blank. | The controller Models. |
-| TECH-1 | Blocks-go-live | Does the energy-dispersive-EXAFS Capability enter CORA's catalog, or stay deferred? It is the dispersive complement to the scanning-XAS / energy-scan question (the BMM ENERGY-1 cohort). | The EDE Method is a pending Practice, not yet in the catalog. | The EDE Capability scope. |
diff --git a/docs/deployments/i20-1/techniques.md b/docs/deployments/i20-1/techniques.md
deleted file mode 100644
index e60a6239ba6..00000000000
--- a/docs/deployments/i20-1/techniques.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Techniques
-
-*What CORA would run at I20-1: energy-dispersive EXAFS, a [Catalog](../../catalog/methods.md) Method bound through a [Diamond Practice](../diamond/index.md). It is the dispersive complement to the scanning-XAS axis, and its Capability is deferred, the more so because the dispersive devices are not yet in source.*
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Energy-dispersive EXAFS (EDE) | `energy_dispersive_exafs` | the whole absorption spectrum read in one shot off a polychromatic fan on a strip detector; time-resolved. New Capability, pending (TECH-1); the dispersive polychromator + strip detector are not yet in source (POLY-1 / STRIP-1) |
-| Fluorescence-yield EXAFS | `energy_dispersive_exafs` | the same dispersive acquisition read in fluorescence on the Xspress3, a secondary mode (DET-1) |
-
-The technique is recorded as a pending [Practice](../diamond/index.md) on the Diamond Site.
-
-## Why the Capability is deferred (and the heart is an open question)
-
-EDE is a new science Capability for CORA: scanning XAS (NSLS-II BMM) steps a monochromator through an edge and the per-energy readings are the data, while EDE reads every energy at once off a dispersed fan. CORA carries the EDE Method as pending, the dispersive complement to the energy-scan question BMM opened (TECH-1 / the ENERGY-1 cohort), rather than coining it, the same earn-the-abstraction discipline every new-domain technique follows.
-
-The sharper point at I20-1 is that the two devices the Capability turns on, the bent-crystal polychromator and the position-sensitive strip detector, are not in the public dodal commissioning module. So this is a partial first cut: the technique is named and its periphery modelled (the energy-selecting turbo slit, the fly-scan PMAC and PandA timing, the fluorescence Xspress3), but the dispersive optic and detector are explicit open questions (POLY-1, STRIP-1). The polychromator in particular would be a genuinely new optic class, an energy-fanning bent crystal distinct from a `Monochromator`, that CORA would weigh as a Family once it is PV-bound; coining it now, with no source PV, would be invention.
-
-The spectrum extraction (turning the dispersed strip frame into an absorption spectrum) is `ComputePort` work, not a beamline Method.
diff --git a/docs/deployments/i22/governance.md b/docs/deployments/i22/governance.md
deleted file mode 100644
index b653d5ce6e9..00000000000
--- a/docs/deployments/i22/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who would act at I22, and the trust shape that would gate it. Design-phase.*
-
-Governance at I22 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-I22 introduces the third Site CORA models, after APS and MAX IV. Unlike 7-BM (which reused the existing APS envelope) and like TomoWISE (which created MAX IV), I22 requires a new Diamond Site: the facility, its operator pool, its safety review structure, and its safety forms are all Diamond-specific and carried pending on the [Diamond Site page](../diamond/index.md) until staff confirm them. None of this is in dodal, which is a controls library, not an organizational record.
-
-Because I22 is a modelling exercise rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed (PSS-1).
-
-One governance note is specific to the off-roadmap nature of this exercise: whether Diamond becomes a real CORA Site at all is itself an open question (SCOPE-1). Until it is answered, the Diamond Site exists as a design-phase fixture that exercises the second-Site machinery (a new Facility, new principals, new clearances) without committing CORA to operate there.
-
-The concrete Zone, Conduit, and Policy instances, and the Diamond operator pool, would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i22/model.md b/docs/deployments/i22/model.md
deleted file mode 100644
index 55f64d4d598..00000000000
--- a/docs/deployments/i22/model.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's I22 content lives, why it earns no catalog kinds and carries real EPICS handles, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at I22 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What is deliberately not here yet
-
-- **New catalog Families, Capabilities, and Methods.** I22 does not earn new catalog kinds in this scaffold. An adversarial new-kind review refuted all five proposed device anatomies as catalog Families on the strength of I22 alone; four (`TemperatureController`, `FluxMonitor`, `Transfocator`, `FlowController`) have since graduated to the catalog once a rule-of-three across deployments settled them, and the remaining one (`StorageRing`) is still carried as a loose family with a tracking question. The new scattering Capabilities are carried as pending Practices. A kind is added to the catalog only when a confirmed device or technique and the naming review settle it. This follows the "pilots earn the abstractions" rule, and I22 is explicitly not a pilot (SCOPE-1).
-- **Integration scenarios.** No `test_i22_*.py` registers I22 Assets into the event store. Hard-registering a design-phase, off-roadmap beamline would commit speculative structure.
-- **Vendor Models.** No catalog Model is bound. The hardware dodal names (Dectris, AVT, Watson-Marlow, Linkam) is recorded in the descriptor notes, not bound.
-- **Operations and experiment views.** A runbook and live experiment view for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
-- **Detector assemblies.** The two detectors are left as plain `Camera` devices. Whether the SAXS detector composes an Assembly with its beamstops and base is deferred (GROUP-1).
-
-What is genuinely new here versus the other scaffolds: the descriptor carries real EPICS control handles (from dodal), and the open questions are about the layers dodal cannot reach (calibration, safety, technique), not about the PVs.
diff --git a/docs/deployments/i22/notes.md b/docs/deployments/i22/notes.md
new file mode 100644
index 00000000000..2b81389a7f3
--- /dev/null
+++ b/docs/deployments/i22/notes.md
@@ -0,0 +1,111 @@
+# Notes
+
+## Techniques
+
+*What I22 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I22 is the first scattering beamline CORA has looked at, so its techniques are the first that do not reduce to the existing tomography and acquisition Capabilities. Which scattering Capabilities and Methods the catalog earns is itself an open question (TECH-1); the function view below survives the eventual vocabulary choices, which is why it can be written before the catalog is extended.
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Small-angle scattering (SAXS) | monochromatic, KB-focused | `SaxsDetector` (Pilatus3 2M, long camera length) | new Capability, pending (TECH-1) |
+| Wide-angle scattering (WAXS) | monochromatic, KB-focused | `WaxsDetector` (Pilatus3 2M, short camera length) | new Capability, pending (TECH-1) |
+| Simultaneous SAXS+WAXS | monochromatic, KB-focused | both detectors at once | coordinated Runs, the routine mode, pending (TECH-1) |
+| Time-resolved SAXS/WAXS | monochromatic | both detectors, PandA-gated | new acquisition Method, deferred until confirmed |
+
+A few points of intent shape the model:
+
+- **The Capabilities are genuinely new.** Tomography reduces to the `tomography` and `acquisition` Capabilities the catalog already carries; SAXS and WAXS do not. They are the cleanest test of whether CORA's Capability layer generalizes past imaging. They are carried as pending Practices on the [Diamond Site](../diamond/index.md), not minted into the catalog, until the technique enters a real scope (TECH-1). A beamline that is a modelling exercise does not get to mint cross-facility vocabulary.
+- **Simultaneous acquisition is coordinated Runs, not a combined technique.** The routine I22 mode reads the SAXS and WAXS detectors at once. CORA models that as coordinated Runs under one Campaign over a shared trigger, the same way 7-BM models energy-dispersive diffraction running alongside tomography, not as a third combined technique.
+- **The detector Roles already exist.** Both detectors present the existing Detector Role; the flux monitors present the existing Sensor Role. No new Role is needed for scattering, only new science Capabilities. The device anatomy generalized cleanly; the technique vocabulary is what is new.
+- **Beam mode is one focused, monochromatic path.** The undulator feeds the double-crystal monochromator and the KB mirror pair; SAXS and WAXS share that one conditioned beam, distinguished by detector position, not beam mode.
+
+The concrete acquisition recipes (q-ranges, camera lengths, exposure, time-resolved sequences) are not written: they are calibration the deployment must supply. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who would act at I22, and the trust shape that would gate it. Design-phase.*
+
+Governance at I22 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+I22 introduces the third Site CORA models, after APS and MAX IV. Unlike 7-BM (which reused the existing APS envelope) and like TomoWISE (which created MAX IV), I22 requires a new Diamond Site: the facility, its operator pool, its safety review structure, and its safety forms are all Diamond-specific and carried pending on the [Diamond Site page](../diamond/index.md) until staff confirm them. None of this is in dodal, which is a controls library, not an organizational record.
+
+Because I22 is a modelling exercise rather than a pilot, the concrete trust shape is not instantiated. What is already settled is the boundary, the same as for every deployment: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them rather than restating them. The Diamond personnel safety system (PSS) clearance is carried pending because its form names are not confirmed (PSS-1).
+
+One governance note is specific to the off-roadmap nature of this exercise: whether Diamond becomes a real CORA Site at all is itself an open question (SCOPE-1). Until it is answered, the Diamond Site exists as a design-phase fixture that exercises the second-Site machinery (a new Facility, new principals, new clearances) without committing CORA to operate there.
+
+The concrete Zone, Conduit, and Policy instances, and the Diamond operator pool, would land if and when the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's I22 content lives, why it earns no catalog kinds and carries real EPICS handles, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at I22 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What is deliberately not here yet
+
+- **New catalog Families, Capabilities, and Methods.** I22 does not earn new catalog kinds in this scaffold. An adversarial new-kind review refuted all five proposed device anatomies as catalog Families on the strength of I22 alone; four (`TemperatureController`, `FluxMonitor`, `Transfocator`, `FlowController`) have since graduated to the catalog once a rule-of-three across deployments settled them, and the remaining one (`StorageRing`) is still carried as a loose family with a tracking question. The new scattering Capabilities are carried as pending Practices. A kind is added to the catalog only when a confirmed device or technique and the naming review settle it. This follows the "pilots earn the abstractions" rule, and I22 is explicitly not a pilot (SCOPE-1).
+- **Integration scenarios.** No `test_i22_*.py` registers I22 Assets into the event store. Hard-registering a design-phase, off-roadmap beamline would commit speculative structure.
+- **Vendor Models.** No catalog Model is bound. The hardware dodal names (Dectris, AVT, Watson-Marlow, Linkam) is recorded in the descriptor notes, not bound.
+- **Operations and experiment views.** A runbook and live experiment view for an unmodelled beamline would be invention; see the note on the [index](index.md#not-yet-documented).
+- **Detector assemblies.** The two detectors are left as plain `Camera` devices. Whether the SAXS detector composes an Assembly with its beamstops and base is deferred (GROUP-1).
+
+What is genuinely new here versus the other scaffolds: the descriptor carries real EPICS control handles (from dodal), and the open questions are about the layers dodal cannot reach (calibration, safety, technique), not about the PVs.
+
+## Open questions
+
+*What CORA needs the I22 team (and Diamond's documentation) to confirm before the model can be trusted.*
+
+I22 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles at high confidence; it does not give the calibrated numbers, the hutch/safety structure, the passive beam-path tier, or the technique binding. This page collects what dodal cannot supply. Each row is a fact the beamline team (or a Diamond drawing / the published I22 beamline paper) owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
+
+Note on what dodal already settled, so it is **not** a question here: the EPICS PV prefix for every device is recorded in the descriptor (this is the one thing I22 has that the TomoWISE scaffold did not), and the device-to-Family mapping is high-confidence. The questions below are the layers above that.
+
+A note on what I22 tests that the tomography pilots did not: I22 is a SAXS/WAXS scattering beamline, so its science Capabilities are new, it runs two detectors simultaneously, and it carries quantitative flux monitors and sample-environment actuators. The questions concentrate on those new shapes.
+
+### Scope and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is I22 (or any Diamond beamline) actually intended to enter CORA scope, or is this purely a generalization exercise against an open controls source? | A generalization exercise: I22 proves the dodal-seed to intentional-model pipeline and stresses the non-tomography axis; it is not on the pilot roadmap. | Whether Diamond becomes a real Site or stays a modelling fixture. |
+| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the optics and experiment hutches? | Both hutches exist with permit signals to be named; dodal does not carry them. | The Enclosure permit signals. |
+| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones (OP, MO, EA, DI), not the access-gated hutch or its safety meaning. | The standard Diamond optics + experiment hutch split, with conditioning optics upstream and sample + detectors downstream. | The per-device Enclosure assignment. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the undulator energy range, period, minimum gap, and gap-to-energy curve? dodal carries only 80 poles and 2.0 m length, plus a lookup-table path on the Diamond filesystem. | An undulator source with the dodal poles/length; the energy range and curve are calibration to supply. | The `Undulator` parameters and the beamline energy range. |
+| MACHINE-1 | Nice-to-have | How should the machine-level storage-ring state (ring current, fill mode, top-up countdown) be modelled: a loose `StorageRing` source, an observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, mirroring the loose beam-source representation the APS deployments use. | The machine-state modelling boundary. |
+| OPT-1 | Nice-to-have | What are the mirror coatings/stripes, the DCM crystal d-spacing and thermal model, and the bimorph channel calibration? dodal exposes the axes and the Si(111) crystal and channel counts, but not the calibrated optic settings. | The optic internals are per-Asset settings or a bound Model on the existing `Mirror` / `Monochromator` Families, not new Families. | Which optic internals are modelled and where they live. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Are the SAXS and WAXS camera lengths fixed mounts or settable axes (a movable detector / flight tube)? dodal carries a single distance snapshot for each. | The two detectors are one `Camera` Family at two positions; whether distance is a settable axis (warranting a detector-translation `LinearStage` Asset) is open. | Whether a detector-translation Asset is modelled. |
+| DET-2 | Blocks-go-live | What are the Pilatus threshold energy and the per-detector beam-center? Both are `None` in dodal and are required for SAXS/WAXS data reduction. | Not modelled until supplied; these are calibrated, beam-energy-dependent values. | The detector calibration the data reduction needs. |
+| OAV-1 | Blocks-go-live | What are the on-axis-view camera working distance and effective pixel size? dodal carries a sentinel distance (-1.0 m) and a pixel size flagged "double check". | Not modelled; both depend on viewing optics dodal does not model. | The OAV geometry. |
+
+### Sample environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| FLUX-1 | Blocks-go-live | How are the incident and transmitted ion chambers (I0 / It) modelled: a new `FluxMonitor` Family, or the existing Sensor Role with a deployment-local device? And is the incident-vs-transmitted distinction a placement setting? | The existing Sensor Role (whose docstring names ion chambers), now via the graduated `FluxMonitor` catalog Family (rule-of-three i22/i03/i15-1); incident vs transmitted is placement, not a Family split. | The flux-monitor modelling boundary. |
+| ENV-1 | Blocks-go-live | Must CORA command the sample-environment setpoints (the Linkam temperature controller, the peristaltic pump), or only read them back? | The settable-actuator shape is now settled: the Linkam binds the graduated `TemperatureController` Family (presents `Regulator`, requires `Settable`); the pump binds the graduated `FlowController` Family (presents `Regulator`, the `TemperatureController` sibling, earned across i22 / 7-BM / LIX / XFP). What is open is whether CORA commands the setpoints. | The command-vs-read decision (shared with 7-BM FLOW-1). |
+
+### Techniques and identity
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Which scattering Capabilities and Methods are in scope (small-angle, wide-angle, simultaneous SAXS+WAXS, time-resolved), and how is a simultaneous SAXS+WAXS acquisition represented? | SAXS and WAXS are new Capabilities not yet in the catalog; simultaneous acquisition is coordinated Runs, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
+| TRIG-1 | Nice-to-have | How do the PandABox FPGA boxes bind to the detectors and flux monitors (trigger fan-out, gating, the master clock)? | One or two `TimingController` devices carry the scheme, mirroring the 2-BM Timing device; the detector/flux binding is a Method concern. | The triggering-subsystem binding. |
+| GROUP-1 | Nice-to-have | Does the SAXS detector share an Assembly with its beamstops and base stage, or are they independent devices? dodal models them separately. | Independent devices in this scaffold; an Assembly is earned only when a feature must act on the whole. | The `parent_id` / Assembly grouping. |
+| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags) for the devices? dodal carries none. | Assets carry no part/serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i22/questions.md b/docs/deployments/i22/questions.md
deleted file mode 100644
index fb102929739..00000000000
--- a/docs/deployments/i22/questions.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Open questions
-
-*What CORA needs the I22 team (and Diamond's documentation) to confirm before the model can be trusted.*
-
-I22 is modelled from Diamond's open [`dodal`](https://github.com/DiamondLightSource/dodal) controls library, treated as a dry, correct DATA source. dodal gives the device shape and the EPICS PV handles at high confidence; it does not give the calibrated numbers, the hutch/safety structure, the passive beam-path tier, or the technique binding. This page collects what dodal cannot supply. Each row is a fact the beamline team (or a Diamond drawing / the published I22 beamline paper) owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
-
-Note on what dodal already settled, so it is **not** a question here: the EPICS PV prefix for every device is recorded in the descriptor (this is the one thing I22 has that the TomoWISE scaffold did not), and the device-to-Family mapping is high-confidence. The questions below are the layers above that.
-
-A note on what I22 tests that the tomography pilots did not: I22 is a SAXS/WAXS scattering beamline, so its science Capabilities are new, it runs two detectors simultaneously, and it carries quantitative flux monitors and sample-environment actuators. The questions concentrate on those new shapes.
-
-## Scope and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is I22 (or any Diamond beamline) actually intended to enter CORA scope, or is this purely a generalization exercise against an open controls source? | A generalization exercise: I22 proves the dodal-seed to intentional-model pipeline and stresses the non-tomography axis; it is not on the pilot roadmap. | Whether Diamond becomes a real Site or stays a modelling fixture. |
-| PSS-1 | Blocks-build | What are the Diamond PSS search-and-secure permit signals for the optics and experiment hutches? | Both hutches exist with permit signals to be named; dodal does not carry them. | The Enclosure permit signals. |
-| ENC-1 | Blocks-build | Which hutch does each device sit in? dodal PV prefixes encode functional zones (OP, MO, EA, DI), not the access-gated hutch or its safety meaning. | The standard Diamond optics + experiment hutch split, with conditioning optics upstream and sample + detectors downstream. | The per-device Enclosure assignment. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the undulator energy range, period, minimum gap, and gap-to-energy curve? dodal carries only 80 poles and 2.0 m length, plus a lookup-table path on the Diamond filesystem. | An undulator source with the dodal poles/length; the energy range and curve are calibration to supply. | The `Undulator` parameters and the beamline energy range. |
-| MACHINE-1 | Nice-to-have | How should the machine-level storage-ring state (ring current, fill mode, top-up countdown) be modelled: a loose `StorageRing` source, an observe-only `GenericProbe`, or a facility-shared read model? | A loose `StorageRing` family bound observe-only, mirroring the loose beam-source representation the APS deployments use. | The machine-state modelling boundary. |
-| OPT-1 | Nice-to-have | What are the mirror coatings/stripes, the DCM crystal d-spacing and thermal model, and the bimorph channel calibration? dodal exposes the axes and the Si(111) crystal and channel counts, but not the calibrated optic settings. | The optic internals are per-Asset settings or a bound Model on the existing `Mirror` / `Monochromator` Families, not new Families. | Which optic internals are modelled and where they live. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Are the SAXS and WAXS camera lengths fixed mounts or settable axes (a movable detector / flight tube)? dodal carries a single distance snapshot for each. | The two detectors are one `Camera` Family at two positions; whether distance is a settable axis (warranting a detector-translation `LinearStage` Asset) is open. | Whether a detector-translation Asset is modelled. |
-| DET-2 | Blocks-go-live | What are the Pilatus threshold energy and the per-detector beam-center? Both are `None` in dodal and are required for SAXS/WAXS data reduction. | Not modelled until supplied; these are calibrated, beam-energy-dependent values. | The detector calibration the data reduction needs. |
-| OAV-1 | Blocks-go-live | What are the on-axis-view camera working distance and effective pixel size? dodal carries a sentinel distance (-1.0 m) and a pixel size flagged "double check". | Not modelled; both depend on viewing optics dodal does not model. | The OAV geometry. |
-
-## Sample environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| FLUX-1 | Blocks-go-live | How are the incident and transmitted ion chambers (I0 / It) modelled: a new `FluxMonitor` Family, or the existing Sensor Role with a deployment-local device? And is the incident-vs-transmitted distinction a placement setting? | The existing Sensor Role (whose docstring names ion chambers), now via the graduated `FluxMonitor` catalog Family (rule-of-three i22/i03/i15-1); incident vs transmitted is placement, not a Family split. | The flux-monitor modelling boundary. |
-| ENV-1 | Blocks-go-live | Must CORA command the sample-environment setpoints (the Linkam temperature controller, the peristaltic pump), or only read them back? | The settable-actuator shape is now settled: the Linkam binds the graduated `TemperatureController` Family (presents `Regulator`, requires `Settable`); the pump binds the graduated `FlowController` Family (presents `Regulator`, the `TemperatureController` sibling, earned across i22 / 7-BM / LIX / XFP). What is open is whether CORA commands the setpoints. | The command-vs-read decision (shared with 7-BM FLOW-1). |
-
-## Techniques and identity
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Which scattering Capabilities and Methods are in scope (small-angle, wide-angle, simultaneous SAXS+WAXS, time-resolved), and how is a simultaneous SAXS+WAXS acquisition represented? | SAXS and WAXS are new Capabilities not yet in the catalog; simultaneous acquisition is coordinated Runs, carried pending on the [Diamond Practices](../diamond/index.md). | Which Capabilities and Methods the catalog earns. |
-| TRIG-1 | Nice-to-have | How do the PandABox FPGA boxes bind to the detectors and flux monitors (trigger fan-out, gating, the master clock)? | One or two `TimingController` devices carry the scheme, mirroring the 2-BM Timing device; the detector/flux binding is a Method concern. | The triggering-subsystem binding. |
-| GROUP-1 | Nice-to-have | Does the SAXS detector share an Assembly with its beamstops and base stage, or are they independent devices? dodal models them separately. | Independent devices in this scaffold; an Assembly is earned only when a feature must act on the whole. | The `parent_id` / Assembly grouping. |
-| ID-1 | Nice-to-have | What are the hardware identities (serial numbers, asset tags) for the devices? dodal carries none. | Assets carry no part/serial identity until supplied. | The Asset hardware-identity fields. |
diff --git a/docs/deployments/i22/techniques.md b/docs/deployments/i22/techniques.md
deleted file mode 100644
index c1df233b1ef..00000000000
--- a/docs/deployments/i22/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What I22 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. I22 is the first scattering beamline CORA has looked at, so its techniques are the first that do not reduce to the existing tomography and acquisition Capabilities. Which scattering Capabilities and Methods the catalog earns is itself an open question (TECH-1); the function view below survives the eventual vocabulary choices, which is why it can be written before the catalog is extended.
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Small-angle scattering (SAXS) | monochromatic, KB-focused | `SaxsDetector` (Pilatus3 2M, long camera length) | new Capability, pending (TECH-1) |
-| Wide-angle scattering (WAXS) | monochromatic, KB-focused | `WaxsDetector` (Pilatus3 2M, short camera length) | new Capability, pending (TECH-1) |
-| Simultaneous SAXS+WAXS | monochromatic, KB-focused | both detectors at once | coordinated Runs, the routine mode, pending (TECH-1) |
-| Time-resolved SAXS/WAXS | monochromatic | both detectors, PandA-gated | new acquisition Method, deferred until confirmed |
-
-A few points of intent shape the model:
-
-- **The Capabilities are genuinely new.** Tomography reduces to the `tomography` and `acquisition` Capabilities the catalog already carries; SAXS and WAXS do not. They are the cleanest test of whether CORA's Capability layer generalizes past imaging. They are carried as pending Practices on the [Diamond Site](../diamond/index.md), not minted into the catalog, until the technique enters a real scope (TECH-1). A beamline that is a modelling exercise does not get to mint cross-facility vocabulary.
-- **Simultaneous acquisition is coordinated Runs, not a combined technique.** The routine I22 mode reads the SAXS and WAXS detectors at once. CORA models that as coordinated Runs under one Campaign over a shared trigger, the same way 7-BM models energy-dispersive diffraction running alongside tomography, not as a third combined technique.
-- **The detector Roles already exist.** Both detectors present the existing Detector Role; the flux monitors present the existing Sensor Role. No new Role is needed for scattering, only new science Capabilities. The device anatomy generalized cleanly; the technique vocabulary is what is new.
-- **Beam mode is one focused, monochromatic path.** The undulator feeds the double-crystal monochromator and the KB mirror pair; SAXS and WAXS share that one conditioned beam, distinguished by detector position, not beam mode.
-
-The concrete acquisition recipes (q-ranges, camera lengths, exposure, time-resolved sequences) are not written: they are calibration the deployment must supply. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/i24/governance.md b/docs/deployments/i24/governance.md
deleted file mode 100644
index 44db991e048..00000000000
--- a/docs/deployments/i24/governance.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Governance
-
-*Who would act at i24, and the trust shape that would gate it. Design-phase.*
-
-Governance at i24 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-i24 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the Diamond operator pool, the safety review structure, and the safety forms are facility-wide and inherited. i24 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md). The operator pool and safety-review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline (GOV-1). This is the same reuse pattern 7-BM follows at APS, the opposite of the new-Site work I22 did.
-
-Because i24 is a modelling exercise, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them. The Diamond PSS clearance is carried pending because its form names are not confirmed.
-
-The safety tier behind the beam is the personnel safety system. The hutch photon shutter is dodal's interlocked hutch shutter, which sits behind a PSS interlock; the search-and-secure permit signals are the leaves that must be satisfied before the beam can enter the enclosure. CORA reads the shutter as a `Shutter` Asset, but the PSS permit leaves are not named in the descriptor and are not invented here, so the Enclosure permit signals are carried pending (PSS-1).
-
-One hazard is sharper at i24 than at the rotation-MX siblings. The fixed-target serial collection rasters an addressable chip of thousands of static crystals across the chip stage, and the PMAC motion controller fires lasers on encoder edges during the raster. Whether those lasers are an excitation source CORA should model as a device or only a trigger setting with a Clearance hazard is deferred (LASER-1). If they are a hazard, the laser interlock would be gated by a Clearance issued after a separate safety review, the same shape the other deployments reserve for unattended or hazardous operation. None of that is built yet; the seam is reserved, not invented. Unlike the rotation-MX siblings, i24 has no sample-changing robot, so there is no autonomous-loading Clearance to model here.
-
-The off-roadmap question of whether Diamond becomes a real CORA Site is unanswered. The concrete Zone, Conduit, and Policy instances, the operator pool, and any laser Clearance would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/i24/model.md b/docs/deployments/i24/model.md
deleted file mode 100644
index 1f23cab38d8..00000000000
--- a/docs/deployments/i24/model.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's i24 content lives, why this first serial-crystallography deployment coins no new vocabulary, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at i24 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes i24 new
-
-i24 is CORA's first serial / fixed-target crystallography. Unlike I03 rotation MX (one crystal, a continuous omega sweep), i24 raster-scans a fixed-target chip holding thousands of static crystals, taking one diffraction snapshot per addressable window, hardware-sequenced on the PMAC motion controller with Zebra TTL gating and no goniometer rotation. The novelty is the acquisition shape, a triggered chip-raster fly-collection over a sample grid, which is a new Capability deferred as a question (SSX-1). It forces no new device Family.
-
-## No new families
-
-i24 introduces no new device class. Every device reuses an existing catalog or loose Family, which is the strongest possible outcome for the families-only descriptor mode:
-
-- The vertical pin goniometer reuses the catalog `Goniometer`, the Family I03 graduated.
-- The fixed-target chip stage (dodal's PMAC, an XYZ stage) reuses `LinearStage`. The serial raster trajectory, the encoder position-compare, and the laser triggers run on the PMAC controller; they are the orchestration seam CORA's edge replaces, not a device Family.
-- The Eiger and Jungfrau detectors reuse `Camera` (Detector Role); the on-axis viewer reuses `Camera`; the Zebra reuses `TimingController`; the DCM reuses `Monochromator`; the focusing mirrors reuse `Mirror`; the attenuator reuses `Filter` (the I03 / i15-1 precedent, not a new Attenuator kind); the aperture, beamstop, and detector / chip stages reuse `Aperture` / `BeamStop` / `LinearStage`; the shutters reuse `Shutter`.
-- The dual backlight binds the catalog `Backlight` Family (graduated across the MX / imaging fleet); the machine source state reuses the loose `StorageRing`. No new loose family either.
-
-## Deliberately not here yet
-
-- **The fixed-target chip as a Fixture / Subject grid (`CHIP-1`).** The chip is a holder of thousands of static crystals that the stage rasters one window at a time. The chip stage is a `LinearStage` Asset; the chip itself (the addressable grid, the well / aperture map) is a Fixture, and the crystals are Subjects, a CORA modelling decision. The grid map lives in beamline software, not a PV, so it is carried as the open `CHIP-1` rather than modelled now. Whether the chip windows are Subjects in a custody grid is the load-bearing question for the serial Subject thread.
-
-- **The serial-crystallography Capability (`SSX-1`).** The chip-raster fly-collection (set a window, gate the exposure, step to the next) is a new acquisition Capability. Whether it enters CORA's catalog as a Method is an owner decision; the Practice renders unlinked, pending. i24 is the first synchrotron consumer; the SLAC LCLS-MFX XFEL deployment carries the same Method pending, so the second consumer is the graduation watch-item.
-
-- **The PMAC laser triggers (`LASER-1`).** The PMAC fires lasers via M-variables on rising / falling encoder edges. Whether these are a pump-probe excitation source CORA should model as a device, or only a trigger setting and a Clearance hazard, is deferred.
-
-- **The collection-Assembly question.** Whether the goniometer, chip stage, and detector compose an Assembly is deferred, as the other Diamond deployments deferred their Assemblies in descriptor mode; the first cut is flat Assets.
-
-- **The simulated devices and full asset-tree scenarios.** No `test_i24_*.py` registers the i24 asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/i24/notes.md b/docs/deployments/i24/notes.md
new file mode 100644
index 00000000000..7de7baae9de
--- /dev/null
+++ b/docs/deployments/i24/notes.md
@@ -0,0 +1,133 @@
+# Notes
+
+## Techniques
+
+*What i24 is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. i24 is the first serial / fixed-target macromolecular-crystallography beamline CORA has looked at, so its technique is a new acquisition shape over the spine, not a recipe over Methods that already exist. Whether it enters the catalog as a Capability is an open question (SSX-1); the function view below survives the eventual vocabulary choice.
+
+| Technique | Beam | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Fixed-target serial crystallography | monochromatic, focused | `Eiger` (Detector Role) | a new `serial_crystallography` Capability binding the chip stage + Eiger + sample shutter + Zebra, deferred (SSX-1) |
+| Chip raster fly-collection | monochromatic, focused | `Eiger` + `OnAxisViewer` | the acquisition primitive of the technique above: window-addressed, Zebra-gated, no rotation (SSX-1, CHIP-1) |
+| Pump-probe excitation | monochromatic, focused | `Eiger` | PMAC-fired lasers on encoder edges; modelled as a trigger setting or a hazard, deferred (LASER-1) |
+| Jungfrau commissioning collection | monochromatic, focused | `Jungfrau` (Detector Role) | the same shape on the commissioning detector; carried pending (DET-1) |
+
+A few points of intent shape the model:
+
+- **Serial collection is a new acquisition shape, not a new device.** Rotation MX at I03 sweeps the goniometer omega while the Eiger captures frames through a continuous oscillation: one crystal, one trajectory of angles. i24 does the opposite. The chip stage rasters a fixed-target chip of thousands of static crystals across the beam, and the detector takes one diffraction snapshot per addressable window, with no goniometer rotation at all. The dataset is many single-orientation patterns, indexed and merged downstream, rather than one rotation sweep. The device Roles already exist (the chip stage presents Positioner, the Eiger presents Detector, the Zebra presents the timing surface); what is new is the recipe that binds them as a window-by-window fly-collection.
+
+- **The catalog has no Method that fits, so i24 earns a Capability.** The tomography Methods bind RotaryStage + Camera + Scintillator over a rotation trajectory, and the I03 rotation MX Methods are a continuous omega sweep over a single crystal; neither matches a triggered raster over a grid of static samples. So serial crystallography is a new `serial_crystallography` Capability rather than a Method under an existing one. Whether it enters CORA's catalog is an owner decision, so the Practice renders pending (SSX-1). i24 is the first synchrotron consumer; the SLAC LCLS-MFX XFEL deployment already carries the same Method pending, so the second consumer is the graduation watch-item.
+
+- **The chip raster is hardware-sequenced, and that sequencing is the seam CORA's edge replaces.** The serial trajectory (set a window, gate the exposure, step to the next) runs on the PMAC motion controller, with the Zebra FPGA TTL-gating the detector and the fast sample shutter per window off encoder position-compare. CORA does not model the PMAC motion program or the Zebra trigger graph as devices; it drives them through EPICS as the orchestration the edge conducts. The detailed raster pattern, the per-window dwell, and the trigger timing are calibration the deployment must supply (SSX-1).
+
+- **The fixed-target chip is a Fixture and a Subject grid, not a PV.** The chip itself is the addressable holder the stage rasters one window at a time, and the crystals it carries are Subjects. The chip stage is a `LinearStage` Asset, but the grid geometry and the well / aperture map live in beamline software, not on a PV, so the chip-as-Fixture and the Subject grid are deferred as a CORA modelling decision (CHIP-1). Whether the chip windows are Subjects in a custody grid is the load-bearing question for the serial Subject thread.
+
+- **There is no sample-exchange loop to model.** Rotation MX at I03 leans on an autonomous robot that loads pins one crystal at a time, which becomes a Procedure plus a Subject custody thread. i24 has no robot and no per-crystal exchange: one chip carries thousands of crystals, loaded once and rastered as a unit. The custody thread is over the chip and its grid, not over a stream of mounted pins.
+
+The concrete recipe (the raster pattern, the per-window dwell, the laser and Zebra trigger timing, the chip grid map) is calibration the deployment must supply. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who would act at i24, and the trust shape that would gate it. Design-phase.*
+
+Governance at i24 follows the same model as the CORA pilots: people and autonomous agents are facility principals at the [Diamond Site](../diamond/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+i24 is a further beamline at the Diamond Site, so it reuses the Diamond facility envelope rather than creating a new one: the Diamond operator pool, the safety review structure, and the safety forms are facility-wide and inherited. i24 adds only its own beamline-bound principals, carried pending on the [Diamond Site page](../diamond/index.md). The operator pool and safety-review structure are site-level and shared across the beamlines, so they are not yet instantiated per beamline (GOV-1). This is the same reuse pattern 7-BM follows at APS, the opposite of the new-Site work I22 did.
+
+Because i24 is a modelling exercise, the concrete trust shape is not instantiated. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the Diamond Site, not on the beamline, and the beamline links up to them. The Diamond PSS clearance is carried pending because its form names are not confirmed.
+
+The safety tier behind the beam is the personnel safety system. The hutch photon shutter is dodal's interlocked hutch shutter, which sits behind a PSS interlock; the search-and-secure permit signals are the leaves that must be satisfied before the beam can enter the enclosure. CORA reads the shutter as a `Shutter` Asset, but the PSS permit leaves are not named in the descriptor and are not invented here, so the Enclosure permit signals are carried pending (PSS-1).
+
+One hazard is sharper at i24 than at the rotation-MX siblings. The fixed-target serial collection rasters an addressable chip of thousands of static crystals across the chip stage, and the PMAC motion controller fires lasers on encoder edges during the raster. Whether those lasers are an excitation source CORA should model as a device or only a trigger setting with a Clearance hazard is deferred (LASER-1). If they are a hazard, the laser interlock would be gated by a Clearance issued after a separate safety review, the same shape the other deployments reserve for unattended or hazardous operation. None of that is built yet; the seam is reserved, not invented. Unlike the rotation-MX siblings, i24 has no sample-changing robot, so there is no autonomous-loading Clearance to model here.
+
+The off-roadmap question of whether Diamond becomes a real CORA Site is unanswered. The concrete Zone, Conduit, and Policy instances, the operator pool, and any laser Clearance would land if the beamline approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's i24 content lives, why this first serial-crystallography deployment coins no new vocabulary, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at i24 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes i24 new
+
+i24 is CORA's first serial / fixed-target crystallography. Unlike I03 rotation MX (one crystal, a continuous omega sweep), i24 raster-scans a fixed-target chip holding thousands of static crystals, taking one diffraction snapshot per addressable window, hardware-sequenced on the PMAC motion controller with Zebra TTL gating and no goniometer rotation. The novelty is the acquisition shape, a triggered chip-raster fly-collection over a sample grid, which is a new Capability deferred as a question (SSX-1). It forces no new device Family.
+
+### No new families
+
+i24 introduces no new device class. Every device reuses an existing catalog or loose Family, which is the strongest possible outcome for the families-only descriptor mode:
+
+- The vertical pin goniometer reuses the catalog `Goniometer`, the Family I03 graduated.
+- The fixed-target chip stage (dodal's PMAC, an XYZ stage) reuses `LinearStage`. The serial raster trajectory, the encoder position-compare, and the laser triggers run on the PMAC controller; they are the orchestration seam CORA's edge replaces, not a device Family.
+- The Eiger and Jungfrau detectors reuse `Camera` (Detector Role); the on-axis viewer reuses `Camera`; the Zebra reuses `TimingController`; the DCM reuses `Monochromator`; the focusing mirrors reuse `Mirror`; the attenuator reuses `Filter` (the I03 / i15-1 precedent, not a new Attenuator kind); the aperture, beamstop, and detector / chip stages reuse `Aperture` / `BeamStop` / `LinearStage`; the shutters reuse `Shutter`.
+- The dual backlight binds the catalog `Backlight` Family (graduated across the MX / imaging fleet); the machine source state reuses the loose `StorageRing`. No new loose family either.
+
+### Deliberately not here yet
+
+- **The fixed-target chip as a Fixture / Subject grid (`CHIP-1`).** The chip is a holder of thousands of static crystals that the stage rasters one window at a time. The chip stage is a `LinearStage` Asset; the chip itself (the addressable grid, the well / aperture map) is a Fixture, and the crystals are Subjects, a CORA modelling decision. The grid map lives in beamline software, not a PV, so it is carried as the open `CHIP-1` rather than modelled now. Whether the chip windows are Subjects in a custody grid is the load-bearing question for the serial Subject thread.
+
+- **The serial-crystallography Capability (`SSX-1`).** The chip-raster fly-collection (set a window, gate the exposure, step to the next) is a new acquisition Capability. Whether it enters CORA's catalog as a Method is an owner decision; the Practice renders unlinked, pending. i24 is the first synchrotron consumer; the SLAC LCLS-MFX XFEL deployment carries the same Method pending, so the second consumer is the graduation watch-item.
+
+- **The PMAC laser triggers (`LASER-1`).** The PMAC fires lasers via M-variables on rising / falling encoder edges. Whether these are a pump-probe excitation source CORA should model as a device, or only a trigger setting and a Clearance hazard, is deferred.
+
+- **The collection-Assembly question.** Whether the goniometer, chip stage, and detector compose an Assembly is deferred, as the other Diamond deployments deferred their Assemblies in descriptor mode; the first cut is flat Assets.
+
+- **The simulated devices and full asset-tree scenarios.** No `test_i24_*.py` registers the i24 asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the i24 team to confirm before the model can be trusted.*
+
+i24 was reverse-engineered from Diamond's open controls library ([dodal](https://github.com/DiamondLightSource/dodal), `src/dodal/beamlines/i24.py` and its device classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the source rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The i24 insertion-device source (gap, type), which dodal does not expose as a device here. | An undulator source; only the Synchrotron machine state is read. | The source Asset detail. |
+| ENC-1 | Blocks-go-live | Is i24 one optics hutch plus one experiment hutch, or a different enclosure split? | Two enclosures: i24-optics and i24-experiment. | The Enclosure grouping. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The machine source state i24 reads (ring current, top-up, mode) and its PVs. | Observe-only via dodal's Synchrotron device, a loose `StorageRing`. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The DCM crystal cut, d-spacing, and incident-energy range. | A double-crystal monochromator on `BL24I-MO-DCM-01:`; values pending. | The monochromator Asset. |
+| OPT-1 | Nice-to-have | The focusing-mirror coatings and the selectable focus modes. | Focusing mirrors bound to `Mirror` (dodal FocusMirrorsMode); modes pending. | The mirror Asset detail. |
+| ATTN-1 | Nice-to-have | The attenuator filter set and transmission levels. | A filter-based attenuator bound to `Filter`, not a new kind (the I03 / i15-1 precedent). | The attenuator Asset. |
+| OPT-2 | Nice-to-have | The aperture, beamstop, and detector-stage axis roles. | Beam-defining aperture / positioned beamstop / detector translation; axes pending. | The optic Asset detail. |
+
+### Sample and serial collection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The vertical goniometer circle and pin-translation axes. | A vertical pin goniometer bound to the catalog `Goniometer`; axes pending. | The goniometer Asset. |
+| CHIP-1 | Blocks-build | How is the fixed-target chip addressed: the grid geometry, the well / aperture layout, and how a collection window maps to a stage position? | An addressable chip on the XYZ chip stage; the grid map lives in beamline software, not a PV. | The chip addressing; the CORA Fixture / Subject-grid modelling is on [Model](#deliberately-not-here-yet). |
+| SSX-1 | Blocks-go-live | The serial-collection sequence: the raster pattern, the per-window dwell, and the laser / Zebra trigger timing. Does serial crystallography enter CORA's catalog as a Capability? | A triggered chip-raster fly-collection; the Capability is deferred, the Practice rendered pending. | The serial-collection shape; the CORA Capability is on [Model](#deliberately-not-here-yet). |
+| LASER-1 | Nice-to-have | The PMAC-controlled lasers: are they a pump-probe excitation source CORA should model, or only a trigger setting and a hazard? | Carried as a trigger setting on the chip-collection seam, not a device; modelling deferred. | The laser model or hazard treatment. |
+| BACKLIGHT-1 | Nice-to-have | The dual backlight PV root and its positions. | Binds the catalog `Backlight` Family; the root `BL24I` and positions pending. | The backlight Asset. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector configuration: the Eiger as the production detector, the Jungfrau as commissioning, and the beam-centre. | Eiger is the primary `Camera` (Detector Role); Jungfrau carried as commissioning. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals behind the interlocked hutch shutter. | The hutch shutter is dodal's InterlockedHutchShutter; the permit leaves are to be named, not invented here. | The Enclosure permit signals. |
+| SUP-1 | Nice-to-have | The vacuum extent and the facility supplies a run draws on. | Photon beam, cooling water, and vacuum on the optics path. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/i24/questions.md b/docs/deployments/i24/questions.md
deleted file mode 100644
index 72dcca3cacf..00000000000
--- a/docs/deployments/i24/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the i24 team to confirm before the model can be trusted.*
-
-i24 was reverse-engineered from Diamond's open controls library ([dodal](https://github.com/DiamondLightSource/dodal), `src/dodal/beamlines/i24.py` and its device classes), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the source rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The i24 insertion-device source (gap, type), which dodal does not expose as a device here. | An undulator source; only the Synchrotron machine state is read. | The source Asset detail. |
-| ENC-1 | Blocks-go-live | Is i24 one optics hutch plus one experiment hutch, or a different enclosure split? | Two enclosures: i24-optics and i24-experiment. | The Enclosure grouping. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The machine source state i24 reads (ring current, top-up, mode) and its PVs. | Observe-only via dodal's Synchrotron device, a loose `StorageRing`. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The DCM crystal cut, d-spacing, and incident-energy range. | A double-crystal monochromator on `BL24I-MO-DCM-01:`; values pending. | The monochromator Asset. |
-| OPT-1 | Nice-to-have | The focusing-mirror coatings and the selectable focus modes. | Focusing mirrors bound to `Mirror` (dodal FocusMirrorsMode); modes pending. | The mirror Asset detail. |
-| ATTN-1 | Nice-to-have | The attenuator filter set and transmission levels. | A filter-based attenuator bound to `Filter`, not a new kind (the I03 / i15-1 precedent). | The attenuator Asset. |
-| OPT-2 | Nice-to-have | The aperture, beamstop, and detector-stage axis roles. | Beam-defining aperture / positioned beamstop / detector translation; axes pending. | The optic Asset detail. |
-
-## Sample and serial collection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The vertical goniometer circle and pin-translation axes. | A vertical pin goniometer bound to the catalog `Goniometer`; axes pending. | The goniometer Asset. |
-| CHIP-1 | Blocks-build | How is the fixed-target chip addressed: the grid geometry, the well / aperture layout, and how a collection window maps to a stage position? | An addressable chip on the XYZ chip stage; the grid map lives in beamline software, not a PV. | The chip addressing; the CORA Fixture / Subject-grid modelling is on [Model](model.md#deliberately-not-here-yet). |
-| SSX-1 | Blocks-go-live | The serial-collection sequence: the raster pattern, the per-window dwell, and the laser / Zebra trigger timing. Does serial crystallography enter CORA's catalog as a Capability? | A triggered chip-raster fly-collection; the Capability is deferred, the Practice rendered pending. | The serial-collection shape; the CORA Capability is on [Model](model.md#deliberately-not-here-yet). |
-| LASER-1 | Nice-to-have | The PMAC-controlled lasers: are they a pump-probe excitation source CORA should model, or only a trigger setting and a hazard? | Carried as a trigger setting on the chip-collection seam, not a device; modelling deferred. | The laser model or hazard treatment. |
-| BACKLIGHT-1 | Nice-to-have | The dual backlight PV root and its positions. | Binds the catalog `Backlight` Family; the root `BL24I` and positions pending. | The backlight Asset. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector configuration: the Eiger as the production detector, the Jungfrau as commissioning, and the beam-centre. | Eiger is the primary `Camera` (Detector Role); Jungfrau carried as commissioning. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from dodal current and correct? | The handles in the descriptor are taken from dodal and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals behind the interlocked hutch shutter. | The hutch shutter is dodal's InterlockedHutchShutter; the permit leaves are to be named, not invented here. | The Enclosure permit signals. |
-| SUP-1 | Nice-to-have | The vacuum extent and the facility supplies a run draws on. | Photon beam, cooling water, and vacuum on the optics path. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Diamond operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the Diamond Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/i24/techniques.md b/docs/deployments/i24/techniques.md
deleted file mode 100644
index 1e4c596981a..00000000000
--- a/docs/deployments/i24/techniques.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Techniques
-
-*What i24 is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../diamond/index.md) is how a facility adapts it. i24 is the first serial / fixed-target macromolecular-crystallography beamline CORA has looked at, so its technique is a new acquisition shape over the spine, not a recipe over Methods that already exist. Whether it enters the catalog as a Capability is an open question (SSX-1); the function view below survives the eventual vocabulary choice.
-
-| Technique | Beam | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Fixed-target serial crystallography | monochromatic, focused | `Eiger` (Detector Role) | a new `serial_crystallography` Capability binding the chip stage + Eiger + sample shutter + Zebra, deferred (SSX-1) |
-| Chip raster fly-collection | monochromatic, focused | `Eiger` + `OnAxisViewer` | the acquisition primitive of the technique above: window-addressed, Zebra-gated, no rotation (SSX-1, CHIP-1) |
-| Pump-probe excitation | monochromatic, focused | `Eiger` | PMAC-fired lasers on encoder edges; modelled as a trigger setting or a hazard, deferred (LASER-1) |
-| Jungfrau commissioning collection | monochromatic, focused | `Jungfrau` (Detector Role) | the same shape on the commissioning detector; carried pending (DET-1) |
-
-A few points of intent shape the model:
-
-- **Serial collection is a new acquisition shape, not a new device.** Rotation MX at I03 sweeps the goniometer omega while the Eiger captures frames through a continuous oscillation: one crystal, one trajectory of angles. i24 does the opposite. The chip stage rasters a fixed-target chip of thousands of static crystals across the beam, and the detector takes one diffraction snapshot per addressable window, with no goniometer rotation at all. The dataset is many single-orientation patterns, indexed and merged downstream, rather than one rotation sweep. The device Roles already exist (the chip stage presents Positioner, the Eiger presents Detector, the Zebra presents the timing surface); what is new is the recipe that binds them as a window-by-window fly-collection.
-
-- **The catalog has no Method that fits, so i24 earns a Capability.** The tomography Methods bind RotaryStage + Camera + Scintillator over a rotation trajectory, and the I03 rotation MX Methods are a continuous omega sweep over a single crystal; neither matches a triggered raster over a grid of static samples. So serial crystallography is a new `serial_crystallography` Capability rather than a Method under an existing one. Whether it enters CORA's catalog is an owner decision, so the Practice renders pending (SSX-1). i24 is the first synchrotron consumer; the SLAC LCLS-MFX XFEL deployment already carries the same Method pending, so the second consumer is the graduation watch-item.
-
-- **The chip raster is hardware-sequenced, and that sequencing is the seam CORA's edge replaces.** The serial trajectory (set a window, gate the exposure, step to the next) runs on the PMAC motion controller, with the Zebra FPGA TTL-gating the detector and the fast sample shutter per window off encoder position-compare. CORA does not model the PMAC motion program or the Zebra trigger graph as devices; it drives them through EPICS as the orchestration the edge conducts. The detailed raster pattern, the per-window dwell, and the trigger timing are calibration the deployment must supply (SSX-1).
-
-- **The fixed-target chip is a Fixture and a Subject grid, not a PV.** The chip itself is the addressable holder the stage rasters one window at a time, and the crystals it carries are Subjects. The chip stage is a `LinearStage` Asset, but the grid geometry and the well / aperture map live in beamline software, not on a PV, so the chip-as-Fixture and the Subject grid are deferred as a CORA modelling decision (CHIP-1). Whether the chip windows are Subjects in a custody grid is the load-bearing question for the serial Subject thread.
-
-- **There is no sample-exchange loop to model.** Rotation MX at I03 leans on an autonomous robot that loads pins one crystal at a time, which becomes a Procedure plus a Subject custody thread. i24 has no robot and no per-crystal exchange: one chip carries thousands of crystals, loaded once and rastered as a unit. The custody thread is over the chip and its grid, not over a stream of mounted pins.
-
-The concrete recipe (the raster pattern, the per-window dwell, the laser and Zebra trigger timing, the chip grid map) is calibration the deployment must supply. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/id16b/governance.md b/docs/deployments/id16b/governance.md
deleted file mode 100644
index dc4b2a21547..00000000000
--- a/docs/deployments/id16b/governance.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Governance
-
-*Who may act at ID16B and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
-
-People and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the BLISS config (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as ID19 and the other beamlines.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the ESRF Site. An ID16B beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The ESRF operator pool and review structure are site-level and shared across the beamlines (ID19 and ID16B both inherit them), so they are not instantiated per beamline; they are carried pending on the [ESRF Site page](../esrf/index.md#safety-and-governance) (GOV-1).
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive the [sample rotation](sample.md) through a tomographic scan, raster the [piezo scanner](sample.md) for an XRF map, arm the [FalconX detector](detector.md) or an area detector, move the KB nanofocus or the monochromator, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The ESRF proposal and cycle are a fact CORA's Campaign uses for custody.
-
-Because ID16B is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zones grouping the optics and endstation resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-
-## The Enclosures ID16B gates
-
-This cut covers two enclosures, the grouping CORA's Zones would follow (ENC-1):
-
-| Enclosure | Role | What it holds |
-| --- | --- | --- |
-| `id16b-optics` | optics hutch | the U205 undulator source, the Kohzu DCM, the primary / secondary slits, the beam monitors, and the shutters |
-| `id16b-experiment` | experiment hutch | the KB nanofocus mirrors, the sample-side slits, the sample rotation / coarse / piezo-scanner stack, the FalconX XRF detector, the optical spectrometer, and the area detectors |
-
-## The safety tier behind the beam
-
-The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the shutters are what those leaves gate. The shutter handles are known from the config (the front-end and `fshut` fast shutter), but the PSS permit signals behind them are not in the config, so CORA does not name them and does not invent them: the Enclosure permit signals are carried pending (PSS-1). When staff confirm the permit signal handles, they bind to the Enclosure as the permit leaves. No interlock or PSS tier is invented in the meantime.
-
-Clearances (the safety forms that must be active to start) are issued at the ESRF Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The ESRF PSS clearance is carried pending because its form names are not confirmed (PSS-1).
-
-## Nano-analysis under custody
-
-ID16B's reason for existing is nano-analysis: KB-focused nano-tomography and nano-XRF mapping. In CORA's model these are the existing `tomography` and `scanning_fluorescence_microscopy` Methods, not new techniques (TECH-1, METHOD-1); the devices they gate are `RotaryStage`, `LinearStage`, `Mirror`, `EnergyDispersiveSpectrometer`, and `Camera` Assets (SAMPLE-1, DET-1), and the reconstructions (the tomographic volume and the XRF map fitting) are `ComputePort` work, not beamline devices. That makes the repeated nano-acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the nanofocus and arm the detectors, and the Campaign and Subject shapes carry the sample's custody and the data record.
-
-The governance shape is the same CORA brings to every beamline; what is different at ID16B is the control floor (BLISS / Tango, not EPICS, see [Controls](controls.md)) and the nanoprobe device set. The trust boundary is control-floor-agnostic and device-agnostic: it gates commands by Actor and state regardless.
-
-If an autonomous Agent were added (for example to centre the sample on the nanoprobe or decide when an XRF map is complete), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; this stays design intent.
-
-## What is deliberately not modelled
-
-- **The PSS permit signals (PSS-1).** The shutter handles are known; the permit signals behind them are not in the config, carried pending, not invented.
-- **The ESRF operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the ESRF Site.
-- **The sample environments (ENV-1).** The cryostream, furnace, and xeol environments are noted, not modelled in this cut.
-- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The full delete-on-answer queue is on [Open questions](questions.md); where each device and Method lands is on [Model](model.md).
diff --git a/docs/deployments/id16b/model.md b/docs/deployments/id16b/model.md
deleted file mode 100644
index 6225ac34df9..00000000000
--- a/docs/deployments/id16b/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ID16B content lives, why this nanoprobe deployment coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ID16B |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes ID16B new
-
-ID16B is CORA's **third non-EPICS deployment** (after ID32 and ID19) and the fleet's **first KB nanoprobe with XRF**. The novelty sits on two axes, both below the technique layer:
-
-- **A second BLISS / Tango floor.** ID16B confirms the ID19 seam pattern is repeatable: motion stages are BLISS axes (IcePAP racks, PI piezo scanners, etel Tango motors), the fluorescence detector is a MOSCA / FalconX Tango device, the area detectors are Lima device servers, and CORA's edge conducts over the `ControlPort` against that floor (CTRL-1, see [Controls](controls.md)).
-- **The first KB nanoprobe with XRF.** The Kirkpatrick-Baez mirror pair focuses the beam to a nanoprobe, and an energy-dispersive fluorescence detector reads a spectrum per raster point. This device combination is new to the fleet, but every part binds an existing Family.
-
-## No new families, two reused methods
-
-ID16B holds the vocabulary constant; that is deliberate, so the new axes (floor, nanoprobe device set) are isolated.
-
-- **The KB mirrors bind the catalog `Mirror`.** The Kirkpatrick-Baez focusing pair is the nanoprobe; a focusing mirror is what `Mirror` is (OPT-1).
-- **The fluorescence detector binds the catalog `EnergyDispersiveSpectrometer`.** ID16B's FalconX silicon-drift detector reads a per-point energy spectrum, a Sensor not a 2D Frame, the same shape as the XFM Xspress3 and the 2-ID / SRX detectors (DET-1). The optical spectrometer (QEPro / Hamamatsu) reuses the same Family (DET-2).
-- **The area detectors bind the catalog `Camera`, which presents the Detector Role.** The PCO and Zyla indirect-detection cameras for nano-tomography are thin `Camera` instances (DET-1).
-- **The stages bind `RotaryStage` and `LinearStage`.** Sample rotation (the tomo / fluo-tomo master motion), coarse positioning, and the PI piezo raster scanner (the nano-XRF mapping motion) (SAMPLE-1).
-- **The optics bind existing Families.** `Monochromator` (the Kohzu DCM), `Slit` (primary / secondary / sample-side), `FluxMonitor` (the EBV beam monitors), `Shutter` (the fast shutter), `InsertionDevice` (the U205 undulator).
-- **The Methods are reused.** Nano-tomography is the existing `tomography` Method; nano-XRF mapping is the pending `scanning_fluorescence_microscopy` Method (2-ID / XFM / LIX). ID16B is a further consumer of each (TECH-1, METHOD-1).
-
-ID16B coins no new Family, nothing graduates, and the catalog is unchanged.
-
-## Deliberately not here yet
-
-- **The sample environments (`ENV-1`).** The config carries a cryostream, a furnace, and a xeol environment with Eurotherm / nanodac regulation. A `Cryostat` Family is not yet in the catalog; the sample environment is deferred to keep this cut vocabulary-neutral. It is the natural first candidate for a future cut (and a rule-of-three watch for a sample-environment Family across ID16B, the 4-ID magnet / temperature stack, and others).
-- **The PSS permit signals (`PSS-1`).** The shutter handles are known; the permit signals behind them are not in the config; carried pending, not invented.
-- **Vendor models, serials, focal-spot sizes, and physical positions.** Not in the config; carried confirm.
-- **The simulated devices and full asset-tree scenarios.** No `test_id16b_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/id16b/notes.md b/docs/deployments/id16b/notes.md
new file mode 100644
index 00000000000..3c6982e21d0
--- /dev/null
+++ b/docs/deployments/id16b/notes.md
@@ -0,0 +1,175 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at ID16B: KB-focused hard X-ray nano-tomography and nano-XRF (fluorescence) mapping, two [Catalog](../../catalog/methods.md) Methods bound through [ESRF Practices](../esrf/index.md#the-techniques-adapted-here). Both are reused, not new; ID16B's novelty is the nanoprobe-on-BLISS combination, not the techniques.*
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| KB-focused nano-tomography | `tomography` | the sample is spun through the nanofocused beam while an area detector records a projection stack; a real-space volume is reconstructed downstream. The existing Method ID19 / 2-BM / TomoWise carry; ID16B is a further consumer (TECH-1) |
+| Nano-XRF mapping (incl. fluorescence-tomography) | `scanning_fluorescence_microscopy` | the sample is rastered through the nanoprobe on a piezo scanner while an energy-dispersive detector reads a fluorescence spectrum per point, building an element map; fluorescence-tomography adds a rotation axis. The pending Method 2-ID / XFM / LIX carry; ID16B is a further consumer (METHOD-1) |
+
+The techniques are recorded as pending [Practices](../esrf/index.md#the-techniques-adapted-here) on the ESRF Site: `ID16B_nanotomography_practice` and `ID16B_scanning_fluorescence_microscopy_practice` (TECH-1, METHOD-1).
+
+### The two acquisition shapes
+
+Both are acquisition shapes CORA already models; ID16B runs them through one KB nanofocus.
+
+- **Nano-tomography.** The [rotation stage](sample.md) spins the sample through the nanofocused beam; the [area detector](detector.md) records a projection at each angle; the projection stack reconstructs to a volume. Same shape as ID19, at nanoscale resolution.
+- **Nano-XRF mapping.** The [piezo raster scanner](sample.md) steps the sample through the nanoprobe point by point; at each point the [fluorescence detector](detector.md) reads an energy-dispersive spectrum, and the element maps are fit downstream. Adding the rotation axis turns this into fluorescence-tomography (a 3D element map).
+
+The parts are a `RotaryStage` (the tomo spin / fluo-tomo rotation), `LinearStage`s (coarse positioning and the PI piezo raster scanner), `Mirror`s (the KB nanofocus), an `EnergyDispersiveSpectrometer` (the FalconX XRF detector), and a `Camera` (the area detector). None is new. The reconstructions, both the tomographic volume and the XRF map fitting, are `ComputePort` work, not beamline devices.
+
+### Why the techniques are not the novelty
+
+CORA already models tomography (ID19, 2-BM) and scanning fluorescence microscopy (2-ID, XFM, LIX). ID16B is a further consumer of both, so the Practices are carried pending only because ID16B is not yet driven by CORA, not because the Methods are new.
+
+The novelty at ID16B is the combination and the floor: it is the fleet's first KB nanoprobe with an energy-dispersive fluorescence detector, and a further beamline on the BLISS / Tango control floor. Both are device-and-control concerns ([Model](#model), [Controls](controls.md)), not technique concerns. Holding the Methods constant is the point: it isolates what is genuinely new.
+
+### Not modelled yet
+
+This cut models the source, optics, KB nanofocus, sample stack, and detection. The sample environments present in the config are noted, not modelled:
+
+- The cryostream, furnace, and xeol sample environments (`EH/cryo`, `EH/furnace`, `EH/xeol`) and their Eurotherm / nanodac regulation. A `Cryostat` Family is not yet in the catalog, so the sample environment is deferred to keep this cut vocabulary-neutral (ENV-1).
+- The `mapping` / `oda` / `taurus` / `webui` software layers (not beamline devices).
+
+Each is named on the [Open questions](#open-questions) page rather than modelled speculatively. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
+
+## Governance
+
+*Who may act at ID16B and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
+
+People and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the BLISS config (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as ID19 and the other beamlines.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the ESRF Site. An ID16B beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The ESRF operator pool and review structure are site-level and shared across the beamlines (ID19 and ID16B both inherit them), so they are not instantiated per beamline; they are carried pending on the [ESRF Site page](../esrf/index.md#safety-and-governance) (GOV-1).
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive the [sample rotation](sample.md) through a tomographic scan, raster the [piezo scanner](sample.md) for an XRF map, arm the [FalconX detector](detector.md) or an area detector, move the KB nanofocus or the monochromator, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The ESRF proposal and cycle are a fact CORA's Campaign uses for custody.
+
+Because ID16B is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zones grouping the optics and endstation resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+
+### The Enclosures ID16B gates
+
+This cut covers two enclosures, the grouping CORA's Zones would follow (ENC-1):
+
+| Enclosure | Role | What it holds |
+| --- | --- | --- |
+| `id16b-optics` | optics hutch | the U205 undulator source, the Kohzu DCM, the primary / secondary slits, the beam monitors, and the shutters |
+| `id16b-experiment` | experiment hutch | the KB nanofocus mirrors, the sample-side slits, the sample rotation / coarse / piezo-scanner stack, the FalconX XRF detector, the optical spectrometer, and the area detectors |
+
+### The safety tier behind the beam
+
+The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the shutters are what those leaves gate. The shutter handles are known from the config (the front-end and `fshut` fast shutter), but the PSS permit signals behind them are not in the config, so CORA does not name them and does not invent them: the Enclosure permit signals are carried pending (PSS-1). When staff confirm the permit signal handles, they bind to the Enclosure as the permit leaves. No interlock or PSS tier is invented in the meantime.
+
+Clearances (the safety forms that must be active to start) are issued at the ESRF Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The ESRF PSS clearance is carried pending because its form names are not confirmed (PSS-1).
+
+### Nano-analysis under custody
+
+ID16B's reason for existing is nano-analysis: KB-focused nano-tomography and nano-XRF mapping. In CORA's model these are the existing `tomography` and `scanning_fluorescence_microscopy` Methods, not new techniques (TECH-1, METHOD-1); the devices they gate are `RotaryStage`, `LinearStage`, `Mirror`, `EnergyDispersiveSpectrometer`, and `Camera` Assets (SAMPLE-1, DET-1), and the reconstructions (the tomographic volume and the XRF map fitting) are `ComputePort` work, not beamline devices. That makes the repeated nano-acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the nanofocus and arm the detectors, and the Campaign and Subject shapes carry the sample's custody and the data record.
+
+The governance shape is the same CORA brings to every beamline; what is different at ID16B is the control floor (BLISS / Tango, not EPICS, see [Controls](controls.md)) and the nanoprobe device set. The trust boundary is control-floor-agnostic and device-agnostic: it gates commands by Actor and state regardless.
+
+If an autonomous Agent were added (for example to centre the sample on the nanoprobe or decide when an XRF map is complete), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; this stays design intent.
+
+### What is deliberately not modelled
+
+- **The PSS permit signals (PSS-1).** The shutter handles are known; the permit signals behind them are not in the config, carried pending, not invented.
+- **The ESRF operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the ESRF Site.
+- **The sample environments (ENV-1).** The cryostream, furnace, and xeol environments are noted, not modelled in this cut.
+- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The full delete-on-answer queue is on [Open questions](#open-questions); where each device and Method lands is on [Model](#model).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ID16B content lives, why this nanoprobe deployment coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ID16B |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes ID16B new
+
+ID16B is CORA's **third non-EPICS deployment** (after ID32 and ID19) and the fleet's **first KB nanoprobe with XRF**. The novelty sits on two axes, both below the technique layer:
+
+- **A second BLISS / Tango floor.** ID16B confirms the ID19 seam pattern is repeatable: motion stages are BLISS axes (IcePAP racks, PI piezo scanners, etel Tango motors), the fluorescence detector is a MOSCA / FalconX Tango device, the area detectors are Lima device servers, and CORA's edge conducts over the `ControlPort` against that floor (CTRL-1, see [Controls](controls.md)).
+- **The first KB nanoprobe with XRF.** The Kirkpatrick-Baez mirror pair focuses the beam to a nanoprobe, and an energy-dispersive fluorescence detector reads a spectrum per raster point. This device combination is new to the fleet, but every part binds an existing Family.
+
+### No new families, two reused methods
+
+ID16B holds the vocabulary constant; that is deliberate, so the new axes (floor, nanoprobe device set) are isolated.
+
+- **The KB mirrors bind the catalog `Mirror`.** The Kirkpatrick-Baez focusing pair is the nanoprobe; a focusing mirror is what `Mirror` is (OPT-1).
+- **The fluorescence detector binds the catalog `EnergyDispersiveSpectrometer`.** ID16B's FalconX silicon-drift detector reads a per-point energy spectrum, a Sensor not a 2D Frame, the same shape as the XFM Xspress3 and the 2-ID / SRX detectors (DET-1). The optical spectrometer (QEPro / Hamamatsu) reuses the same Family (DET-2).
+- **The area detectors bind the catalog `Camera`, which presents the Detector Role.** The PCO and Zyla indirect-detection cameras for nano-tomography are thin `Camera` instances (DET-1).
+- **The stages bind `RotaryStage` and `LinearStage`.** Sample rotation (the tomo / fluo-tomo master motion), coarse positioning, and the PI piezo raster scanner (the nano-XRF mapping motion) (SAMPLE-1).
+- **The optics bind existing Families.** `Monochromator` (the Kohzu DCM), `Slit` (primary / secondary / sample-side), `FluxMonitor` (the EBV beam monitors), `Shutter` (the fast shutter), `InsertionDevice` (the U205 undulator).
+- **The Methods are reused.** Nano-tomography is the existing `tomography` Method; nano-XRF mapping is the pending `scanning_fluorescence_microscopy` Method (2-ID / XFM / LIX). ID16B is a further consumer of each (TECH-1, METHOD-1).
+
+ID16B coins no new Family, nothing graduates, and the catalog is unchanged.
+
+### Deliberately not here yet
+
+- **The sample environments (`ENV-1`).** The config carries a cryostream, a furnace, and a xeol environment with Eurotherm / nanodac regulation. A `Cryostat` Family is not yet in the catalog; the sample environment is deferred to keep this cut vocabulary-neutral. It is the natural first candidate for a future cut (and a rule-of-three watch for a sample-environment Family across ID16B, the 4-ID magnet / temperature stack, and others).
+- **The PSS permit signals (`PSS-1`).** The shutter handles are known; the permit signals behind them are not in the config; carried pending, not invented.
+- **Vendor models, serials, focal-spot sizes, and physical positions.** Not in the config; carried confirm.
+- **The simulated devices and full asset-tree scenarios.** No `test_id16b_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the ID16B team to confirm before the model can be trusted.*
+
+ID16B was reverse-engineered from the beamline's own public BLISS Beacon device database ([`gitlab.esrf.fr/id16b/beamline_configuration`](https://gitlab.esrf.fr/id16b/beamline_configuration)), so the control handles on the [device pages](index.md) are the beamline's real BLISS object and Tango device names, read from the config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Control and the BLISS / Tango floor
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the BLISS object and Tango device handles read from the public config current and correct against the live system? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
+| CTRL-2 | Nice-to-have | Which BLISS scan procedures ID16B uses per mode (daiquiri_tomo vs daiquiri_fluo / fluo3d), and which the CORA edge drives through versus replaces. | A continuous-rotation tomo scan and a piezo raster fluo scan; the conduct-versus-replace split is per routine. | The orchestration seam over the `ControlPort`. |
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and one experiment hutch holding the nanofocus and sample? | One `id16b-optics` and one `id16b-experiment` enclosure. | The Enclosure grouping. |
+| ENV-1 | Nice-to-have | The sample environments (cryostream, furnace, xeol) in the config: do they enter a later cut, and as which Family? | Noted, not modelled in this cut; no `Cryostat` Family yet. | The sample-environment roster. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The U205 undulator energy reach and gap mapping. | An undulator source feeding the DCM; energy reach to confirm. | The source Asset. |
+| OPT-1 | Blocks-go-live | The Kohzu crystal-pair selection per energy, and the KB focal spot / working distance. | Kohzu Si111 / Si333 / Si311; KB mirrors as the nanofocus. | The optics and nanofocus modelling. |
+
+### Sample and detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The operative rotation / coarse / piezo-scanner axis set per mode (tomo vs fluo). | Rotation (srot) + coarse (sx/sy/sz) + PI piezo scanner (sampy/sampz); rotation is the tomo master motion, the piezo scanner the fluo raster. | The sample-stage modelling. |
+| DET-1 | Blocks-go-live | The operative XRF detector and area detector per mode, and the detector-stage axes. | FalconX silicon-drift for nano-XRF (EnergyDispersiveSpectrometer); PCO / Zyla for nano-tomography (Camera). | The detector modelling. |
+| DET-2 | Nice-to-have | The role of the optical spectrometer (QEPro / Hamamatsu): xeol, beam diagnostics, or a science channel? | An optical-emission spectrometer reusing EnergyDispersiveSpectrometer. | The optical-spectrometer modelling. |
+
+### Safety and resources
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| PSS-1 | Blocks-go-live | The ESRF PSS permit signals behind the front-end / fast shutters (not in the config). | Permit leaves to be named; the shutter handles are known, the permit signals are not. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent of the beam path and the cooling-water / beam supplies a run draws on. | Photon beam, cooling water, and vacuum, carried pending. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level, shared across beamlines). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do nano-tomography and nano-XRF map cleanly onto the existing `tomography` and `scanning_fluorescence_microscopy` Methods? | Both reused as pending Practices; ID16B is a further consumer of each. | The two Practices. |
diff --git a/docs/deployments/id16b/questions.md b/docs/deployments/id16b/questions.md
deleted file mode 100644
index 228dda4418b..00000000000
--- a/docs/deployments/id16b/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the ID16B team to confirm before the model can be trusted.*
-
-ID16B was reverse-engineered from the beamline's own public BLISS Beacon device database ([`gitlab.esrf.fr/id16b/beamline_configuration`](https://gitlab.esrf.fr/id16b/beamline_configuration)), so the control handles on the [device pages](index.md) are the beamline's real BLISS object and Tango device names, read from the config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Control and the BLISS / Tango floor
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the BLISS object and Tango device handles read from the public config current and correct against the live system? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle. |
-| CTRL-2 | Nice-to-have | Which BLISS scan procedures ID16B uses per mode (daiquiri_tomo vs daiquiri_fluo / fluo3d), and which the CORA edge drives through versus replaces. | A continuous-rotation tomo scan and a piezo raster fluo scan; the conduct-versus-replace split is per routine. | The orchestration seam over the `ControlPort`. |
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and one experiment hutch holding the nanofocus and sample? | One `id16b-optics` and one `id16b-experiment` enclosure. | The Enclosure grouping. |
-| ENV-1 | Nice-to-have | The sample environments (cryostream, furnace, xeol) in the config: do they enter a later cut, and as which Family? | Noted, not modelled in this cut; no `Cryostat` Family yet. | The sample-environment roster. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The U205 undulator energy reach and gap mapping. | An undulator source feeding the DCM; energy reach to confirm. | The source Asset. |
-| OPT-1 | Blocks-go-live | The Kohzu crystal-pair selection per energy, and the KB focal spot / working distance. | Kohzu Si111 / Si333 / Si311; KB mirrors as the nanofocus. | The optics and nanofocus modelling. |
-
-## Sample and detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The operative rotation / coarse / piezo-scanner axis set per mode (tomo vs fluo). | Rotation (srot) + coarse (sx/sy/sz) + PI piezo scanner (sampy/sampz); rotation is the tomo master motion, the piezo scanner the fluo raster. | The sample-stage modelling. |
-| DET-1 | Blocks-go-live | The operative XRF detector and area detector per mode, and the detector-stage axes. | FalconX silicon-drift for nano-XRF (EnergyDispersiveSpectrometer); PCO / Zyla for nano-tomography (Camera). | The detector modelling. |
-| DET-2 | Nice-to-have | The role of the optical spectrometer (QEPro / Hamamatsu): xeol, beam diagnostics, or a science channel? | An optical-emission spectrometer reusing EnergyDispersiveSpectrometer. | The optical-spectrometer modelling. |
-
-## Safety and resources
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| PSS-1 | Blocks-go-live | The ESRF PSS permit signals behind the front-end / fast shutters (not in the config). | Permit leaves to be named; the shutter handles are known, the permit signals are not. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent of the beam path and the cooling-water / beam supplies a run draws on. | Photon beam, cooling water, and vacuum, carried pending. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level, shared across beamlines). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do nano-tomography and nano-XRF map cleanly onto the existing `tomography` and `scanning_fluorescence_microscopy` Methods? | Both reused as pending Practices; ID16B is a further consumer of each. | The two Practices. |
diff --git a/docs/deployments/id16b/techniques.md b/docs/deployments/id16b/techniques.md
deleted file mode 100644
index 30f196391e6..00000000000
--- a/docs/deployments/id16b/techniques.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Techniques
-
-*What CORA would run at ID16B: KB-focused hard X-ray nano-tomography and nano-XRF (fluorescence) mapping, two [Catalog](../../catalog/methods.md) Methods bound through [ESRF Practices](../esrf/index.md#the-techniques-adapted-here). Both are reused, not new; ID16B's novelty is the nanoprobe-on-BLISS combination, not the techniques.*
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| KB-focused nano-tomography | `tomography` | the sample is spun through the nanofocused beam while an area detector records a projection stack; a real-space volume is reconstructed downstream. The existing Method ID19 / 2-BM / TomoWise carry; ID16B is a further consumer (TECH-1) |
-| Nano-XRF mapping (incl. fluorescence-tomography) | `scanning_fluorescence_microscopy` | the sample is rastered through the nanoprobe on a piezo scanner while an energy-dispersive detector reads a fluorescence spectrum per point, building an element map; fluorescence-tomography adds a rotation axis. The pending Method 2-ID / XFM / LIX carry; ID16B is a further consumer (METHOD-1) |
-
-The techniques are recorded as pending [Practices](../esrf/index.md#the-techniques-adapted-here) on the ESRF Site: `ID16B_nanotomography_practice` and `ID16B_scanning_fluorescence_microscopy_practice` (TECH-1, METHOD-1).
-
-## The two acquisition shapes
-
-Both are acquisition shapes CORA already models; ID16B runs them through one KB nanofocus.
-
-- **Nano-tomography.** The [rotation stage](sample.md) spins the sample through the nanofocused beam; the [area detector](detector.md) records a projection at each angle; the projection stack reconstructs to a volume. Same shape as ID19, at nanoscale resolution.
-- **Nano-XRF mapping.** The [piezo raster scanner](sample.md) steps the sample through the nanoprobe point by point; at each point the [fluorescence detector](detector.md) reads an energy-dispersive spectrum, and the element maps are fit downstream. Adding the rotation axis turns this into fluorescence-tomography (a 3D element map).
-
-The parts are a `RotaryStage` (the tomo spin / fluo-tomo rotation), `LinearStage`s (coarse positioning and the PI piezo raster scanner), `Mirror`s (the KB nanofocus), an `EnergyDispersiveSpectrometer` (the FalconX XRF detector), and a `Camera` (the area detector). None is new. The reconstructions, both the tomographic volume and the XRF map fitting, are `ComputePort` work, not beamline devices.
-
-## Why the techniques are not the novelty
-
-CORA already models tomography (ID19, 2-BM) and scanning fluorescence microscopy (2-ID, XFM, LIX). ID16B is a further consumer of both, so the Practices are carried pending only because ID16B is not yet driven by CORA, not because the Methods are new.
-
-The novelty at ID16B is the combination and the floor: it is the fleet's first KB nanoprobe with an energy-dispersive fluorescence detector, and a further beamline on the BLISS / Tango control floor. Both are device-and-control concerns ([Model](model.md), [Controls](controls.md)), not technique concerns. Holding the Methods constant is the point: it isolates what is genuinely new.
-
-## Not modelled yet
-
-This cut models the source, optics, KB nanofocus, sample stack, and detection. The sample environments present in the config are noted, not modelled:
-
-- The cryostream, furnace, and xeol sample environments (`EH/cryo`, `EH/furnace`, `EH/xeol`) and their Eurotherm / nanodac regulation. A `Cryostat` Family is not yet in the catalog, so the sample environment is deferred to keep this cut vocabulary-neutral (ENV-1).
-- The `mapping` / `oda` / `taurus` / `webui` software layers (not beamline devices).
-
-Each is named on the [Open questions](questions.md) page rather than modelled speculatively. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
diff --git a/docs/deployments/id19/governance.md b/docs/deployments/id19/governance.md
deleted file mode 100644
index a811dad05b9..00000000000
--- a/docs/deployments/id19/governance.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Governance
-
-*Who may act at ID19 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
-
-People and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the BLISS config (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as the other beamlines.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the ESRF Site. An ID19 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The ESRF operator pool and review structure are site-level and shared across the beamlines, so they are not instantiated per beamline; they are carried pending on the [ESRF Site page](../esrf/index.md#safety-and-governance) (GOV-1). None of this is in the BLISS config, which is a controls device database, not an organizational record.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive a [rotation stage](sample.md) through a tomographic scan, arm a [detector](detector.md) to record the projection stack, move the monochromator or open a shutter, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The ESRF proposal and cycle are a fact CORA's Campaign uses for custody.
-
-Because ID19 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zones grouping the optics and endstation resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
-
-## The Enclosures ID19 gates
-
-This cut covers two enclosures, the grouping CORA's Zones would follow (ENC-1):
-
-| Enclosure | Role | What it holds |
-| --- | --- | --- |
-| `id19-optics` | optics hutch | the insertion-device source, the TripleMono, the primary / secondary slits, the transfocator, the attenuators, and the front-end / beam shutters |
-| `id19-experiment` | experiment hutch | the MR and HR tomographic rotation stages, their sample positioning stacks, the Lima area detectors, and the detector propagation stages |
-
-A shared optics hutch feeding two tomography endstations in one experiment hutch is the governance shape: which endstation is taking beam, and who may drive the shared optics, is the kind of question the Zone and Policy answer.
-
-## The safety tier behind the beam
-
-The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the shutters are what those leaves gate. The shutter handles are known from the config (`frontend`, `id19/bsh/1`, `id19/bsh/2`, all TangoShutters), but the PSS permit signals behind them are not in the config, so CORA does not name them and does not invent them: the Enclosure permit signals are carried pending (PSS-1). When staff confirm the permit signal handles, they bind to the Enclosure as the permit leaves the way the operating siblings carry theirs. No interlock or PSS tier is invented in the meantime.
-
-Clearances (the safety forms that must be active to start) are issued at the ESRF Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The ESRF PSS clearance is carried pending because its form names are not confirmed (PSS-1).
-
-## Microtomography under custody
-
-ID19's reason for existing is microtomography: a tomographic acquisition spins the sample through the beam and records a stack of projection radiographs, and a real-space volume is reconstructed from that stack. In CORA's model this is the existing `tomography` Method, not a new technique (TECH-1); the devices it gates are `RotaryStage`, `LinearStage`, and `Camera` Assets (SAMPLE-1, DET-1), and the reconstruction is `ComputePort` work, not a beamline device. That makes the repeated tomographic acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the rotation and arm the detector, and the Campaign and Subject shapes carry the sample's custody and the projection record.
-
-The governance shape is the same CORA brings to every beamline; what is different at ID19 is one layer down, in the control floor (BLISS / Tango, not EPICS, see [Controls](controls.md)). The trust boundary is control-floor-agnostic: it gates commands by Actor and state regardless of whether the floor underneath is EPICS or BLISS.
-
-If an autonomous Agent were added (for example to centre the sample or decide when a scan is complete), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; this stays design intent.
-
-## What is deliberately not modelled
-
-- **The PSS permit signals (PSS-1).** The shutter handles are known; the permit signals behind them are not in the config, carried pending, not invented.
-- **The ESRF operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the ESRF Site, not instantiated per beamline.
-- **The further endstations (ENDSTATION-1).** MH, MED, laminography, radiography, and PCO are noted, not modelled in this cut.
-- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The full delete-on-answer queue is on [Open questions](questions.md); where each device and Method lands is on [Model](model.md).
diff --git a/docs/deployments/id19/model.md b/docs/deployments/id19/model.md
deleted file mode 100644
index 23376adef9e..00000000000
--- a/docs/deployments/id19/model.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ID19 content lives, why this BLISS-floor imaging deployment coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ID19 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes ID19 new
-
-ID19 is CORA's first imaging beamline on a **non-EPICS control floor**. Most of the fleet is EPICS (APS, Diamond, NSLS-II, SLAC, all ophyd / bluesky / dodal / pcdshub). ESRF runs BLISS, a Tango-based control system; its soft X-ray sibling ID32 opened the BLISS floor for CORA, and ID19 is the first to bring it to tomographic imaging. That is the novelty, and it is a **control-plane** concern, not a device or technique concern.
-
-The seam model that today reads "EPICS is the floor" generalizes at ID19 to "BLISS / Tango is the floor". CORA's edge conducts the tomographic scan over its `ControlPort` against BLISS scan procedures and Lima detector servers, rather than EPICS IOCs. The test ID19 poses is that the `ControlPort` and the conduct-versus-drive-through seam are genuinely control-system-agnostic, not secretly EPICS-shaped (see [Controls](controls.md), CTRL-1).
-
-## No new families, no new methods
-
-ID19 is a microtomography beamline, and CORA already models microtomography. So holding the device families and the technique constant is deliberate: it isolates the control-plane axis as the only new thing.
-
-- **The rotation stages bind the catalog `RotaryStage`.** `mrsrot` (MR) and `hrsrot` (HR) are the tomographic spins, the master motions of each scan, expected to clock the detector triggering (SAMPLE-1).
-- **The sample and detector positioning stages bind the catalog `LinearStage`.** Sample centring (with the `XYOnRotation` pseudo-axis keeping the sample on the rotation axis) and the detector propagation distance are plain linear motion (SAMPLE-1, DET-1).
-- **The detectors bind the catalog `Camera`, which presents the Detector Role.** ID19's indirect-detection area detectors (interchangeable Frelon CCD, PCO 4k, PCO Dimax high-speed, and Basler Lima cameras) are thin `Camera` instances (DET-1).
-- **The optics bind existing Families.** `Monochromator` (the TripleMono), `Slit` (primary / secondary), `Transfocator` (the white-beam Be-lens transfocator), `Filter` (the attenuator banks, folding in per the i03 precedent rather than a new `Attenuator` Family), `Shutter` (front-end and beam shutters), and `InsertionDevice` (the undulator / wiggler set).
-- **The technique is the existing `tomography` Method.** ID19 is a further consumer of the Method the 2-BM pilot and TomoWise carry; the Practice `ID19_microtomography_practice` is carried pending only because ID19 is not yet driven by CORA (TECH-1).
-
-ID19 coins no new Family, nothing graduates, and the catalog is unchanged.
-
-## Two endstations
-
-MR (micro-resolution) and HR (high-resolution) are distinct BLISS sessions (`MRTOMO`, `HRTOMO`) sharing the source and optics. CORA models each as its own sample and detection group under the shared experiment hutch: same Families, same `tomography` Method, different stage stack and magnification optic. This is a Practice-and-settings difference, not new vocabulary.
-
-## Deliberately not here yet
-
-- **The further endstations (`ENDSTATION-1`).** The config carries MH, MED, laminography (LATOMO, a MicosAnka-over-TCP controller with a tilt-transformation pusher), RADIO, PCOTOMO, the SmarAct multi-tower stack, and the FalconX / Mercury fluorescence MCAs. This cut models MR and HR, the two main tomography stations; the rest are noted, not modelled.
-- **The PSS permit signals (`PSS-1`).** The TangoShutter handles (`frontend`, `id19/bsh/1`, `id19/bsh/2`) are known, but the personnel-safety permit signals behind them are not in the config; carried pending, not invented.
-- **Vendor models, serials, and physical positions.** Not in the config; carried confirm.
-- **The simulated devices and full asset-tree scenarios.** No `test_id19_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/id19/notes.md b/docs/deployments/id19/notes.md
new file mode 100644
index 00000000000..eaa18ec6046
--- /dev/null
+++ b/docs/deployments/id19/notes.md
@@ -0,0 +1,178 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at ID19: hard X-ray parallel-beam microtomography, radiography, and propagation phase-contrast imaging, a [Catalog](../../catalog/methods.md) Method bound through an [ESRF Practice](../esrf/index.md#the-techniques-adapted-here). The technique is plain tomography reuse; the genuine novelty at ID19 is the control floor, not the science.*
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Parallel-beam microtomography / radiography / phase-contrast imaging | `tomography` | the sample is spun through the beam while an area detector records a stack of projection radiographs; a real-space volume is reconstructed downstream. The existing Method the 2-BM pilot and MAX IV TomoWise carry; ID19 is a further consumer (TECH-1) |
+
+The technique is recorded as a pending [Practice](../esrf/index.md#the-techniques-adapted-here) on the ESRF Site, `ID19_microtomography_practice` (TECH-1).
+
+### The acquisition shape
+
+Microtomography is an acquisition shape CORA already models. The [rotation stage](sample.md) spins the sample through the beam; the [detector](detector.md) records a projection radiograph at each angle; and the stack of projections, together with the known rotation angles, is enough to reconstruct a real-space volume of the sample. ID19's long source-to-sample distance gives the beam high spatial coherence, so a settable sample-to-detector distance turns the same acquisition into propagation phase-contrast imaging (DET-1). The reconstruction, turning the projection stack into a volume, is `ComputePort` work, not a beamline device, the same reconstruction leg the other imaging beamlines carry.
+
+ID19 runs this acquisition at two endstations sharing one source and optics: the micro-resolution (MR) station for large-field, high-throughput tomography, and the high-resolution (HR) station for small-field, high-resolution tomography. Both are the same Method; the difference is the stage stack and the magnification optic, a Practice-and-settings difference, not a new technique.
+
+So the parts are a `RotaryStage` (the tomographic spin, the master motion, SAMPLE-1), a `LinearStage` for sample centring (SAMPLE-1), a `Camera` as the area detector (interchangeable Frelon / PCO / Basler Lima cameras, DET-1), and a `LinearStage` setting the detector propagation distance (DET-1). None is new; ID19 reuses the existing tomography device shapes exactly.
+
+### Why the technique is not the novelty
+
+ID19 is a microtomography beamline, and CORA already models microtomography at the 2-BM operational pilot and the MAX IV TomoWise design scaffold. The `tomography` Method, its Capability, and the device families it binds are all in place. ID19 is a further consumer of that Method, not a new technique, so the Practice is carried pending only because ID19 is not yet driven by CORA, not because the Method is new (TECH-1).
+
+The genuine novelty at ID19 is one layer down, in the control plane: ESRF runs BLISS (a Tango-based control system), not EPICS, and ID19 is the first to bring that BLISS floor to tomographic imaging (its ESRF sibling ID32 opened it for soft X-ray RIXS). That is a [Controls](controls.md) and seam concern, not a technique concern. Holding the technique constant is the point: it isolates the control-plane axis so the BLISS / Tango floor is the only thing that is new (see [Model](#model)).
+
+### Not modelled yet
+
+This cut models the source, the optics, and the two main tomography endstations (MR and HR). The further endstations present in the ID19 config are noted but not modelled:
+
+- The MH and MED tomography endstations, their own BLISS sessions with their own stage stacks (ENDSTATION-1).
+- The LATOMO laminography endstation, which runs a MicosAnka controller over TCP plus a tilt-transformation pusher, a distinct acquisition geometry (ENDSTATION-1).
+- The RADIO (radiography) and PCOTOMO (PCO high-speed tomography) sessions (ENDSTATION-1).
+- The SmarAct multi-tower sample stack and the FalconX / Mercury fluorescence MCAs (ENDSTATION-1).
+
+Each is named on the [Open questions](#open-questions) page rather than modelled speculatively. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
+
+## Governance
+
+*Who may act at ID19 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority. Scaffold, not yet instantiated.*
+
+People and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the BLISS config (GOV-1), so the principals are the design shape, not a registered list. This page follows the same model as the other beamlines.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the ESRF Site. An ID19 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. The ESRF operator pool and review structure are site-level and shared across the beamlines, so they are not instantiated per beamline; they are carried pending on the [ESRF Site page](../esrf/index.md#safety-and-governance) (GOV-1). None of this is in the BLISS config, which is a controls device database, not an organizational record.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may drive a [rotation stage](sample.md) through a tomographic scan, arm a [detector](detector.md) to record the projection stack, move the monochromator or open a shutter, override a caution, or commit an alignment. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The ESRF proposal and cycle are a fact CORA's Campaign uses for custody.
+
+Because ID19 is a reverse-engineered scaffold rather than a pilot, the concrete trust shape (the Zones grouping the optics and endstation resources, the Conduit binding the surfaces that may issue commands, and the Policies that say who may do what) is named here, not built. It would land, following the [2-BM governance](../2-bm/governance.md) shape, if and when the deployment approaches real scope.
+
+### The Enclosures ID19 gates
+
+This cut covers two enclosures, the grouping CORA's Zones would follow (ENC-1):
+
+| Enclosure | Role | What it holds |
+| --- | --- | --- |
+| `id19-optics` | optics hutch | the insertion-device source, the TripleMono, the primary / secondary slits, the transfocator, the attenuators, and the front-end / beam shutters |
+| `id19-experiment` | experiment hutch | the MR and HR tomographic rotation stages, their sample positioning stacks, the Lima area detectors, and the detector propagation stages |
+
+A shared optics hutch feeding two tomography endstations in one experiment hutch is the governance shape: which endstation is taking beam, and who may drive the shared optics, is the kind of question the Zone and Policy answer.
+
+### The safety tier behind the beam
+
+The safety tier behind the beam is the personnel safety system. The leaves that must be satisfied before the beam can enter an enclosure are the PSS search-and-secure permit signals, and the shutters are what those leaves gate. The shutter handles are known from the config (`frontend`, `id19/bsh/1`, `id19/bsh/2`, all TangoShutters), but the PSS permit signals behind them are not in the config, so CORA does not name them and does not invent them: the Enclosure permit signals are carried pending (PSS-1). When staff confirm the permit signal handles, they bind to the Enclosure as the permit leaves the way the operating siblings carry theirs. No interlock or PSS tier is invented in the meantime.
+
+Clearances (the safety forms that must be active to start) are issued at the ESRF Site, not on the beamline, and the beamline links up to them rather than restating them (GOV-1). The ESRF PSS clearance is carried pending because its form names are not confirmed (PSS-1).
+
+### Microtomography under custody
+
+ID19's reason for existing is microtomography: a tomographic acquisition spins the sample through the beam and records a stack of projection radiographs, and a real-space volume is reconstructed from that stack. In CORA's model this is the existing `tomography` Method, not a new technique (TECH-1); the devices it gates are `RotaryStage`, `LinearStage`, and `Camera` Assets (SAMPLE-1, DET-1), and the reconstruction is `ComputePort` work, not a beamline device. That makes the repeated tomographic acquisition the place CORA's custody and trust shapes would earn their keep: the trust boundary bounds who may drive the rotation and arm the detector, and the Campaign and Subject shapes carry the sample's custody and the projection record.
+
+The governance shape is the same CORA brings to every beamline; what is different at ID19 is one layer down, in the control floor (BLISS / Tango, not EPICS, see [Controls](controls.md)). The trust boundary is control-floor-agnostic: it gates commands by Actor and state regardless of whether the floor underneath is EPICS or BLISS.
+
+If an autonomous Agent were added (for example to centre the sample or decide when a scan is complete), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet; this stays design intent.
+
+### What is deliberately not modelled
+
+- **The PSS permit signals (PSS-1).** The shutter handles are known; the permit signals behind them are not in the config, carried pending, not invented.
+- **The ESRF operator pool and review structure (GOV-1).** Site-level and shared across the beamlines, carried pending on the ESRF Site, not instantiated per beamline.
+- **The further endstations (ENDSTATION-1).** MH, MED, laminography, radiography, and PCO are noted, not modelled in this cut.
+- **The concrete Zone, Conduit, and Policy instances.** Named as the trust shape, not built; they would land if and when the deployment approaches real scope, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The full delete-on-answer queue is on [Open questions](#open-questions); where each device and Method lands is on [Model](#model).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ID19 content lives, why this BLISS-floor imaging deployment coins no new family, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ID19 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes ID19 new
+
+ID19 is CORA's first imaging beamline on a **non-EPICS control floor**. Most of the fleet is EPICS (APS, Diamond, NSLS-II, SLAC, all ophyd / bluesky / dodal / pcdshub). ESRF runs BLISS, a Tango-based control system; its soft X-ray sibling ID32 opened the BLISS floor for CORA, and ID19 is the first to bring it to tomographic imaging. That is the novelty, and it is a **control-plane** concern, not a device or technique concern.
+
+The seam model that today reads "EPICS is the floor" generalizes at ID19 to "BLISS / Tango is the floor". CORA's edge conducts the tomographic scan over its `ControlPort` against BLISS scan procedures and Lima detector servers, rather than EPICS IOCs. The test ID19 poses is that the `ControlPort` and the conduct-versus-drive-through seam are genuinely control-system-agnostic, not secretly EPICS-shaped (see [Controls](controls.md), CTRL-1).
+
+### No new families, no new methods
+
+ID19 is a microtomography beamline, and CORA already models microtomography. So holding the device families and the technique constant is deliberate: it isolates the control-plane axis as the only new thing.
+
+- **The rotation stages bind the catalog `RotaryStage`.** `mrsrot` (MR) and `hrsrot` (HR) are the tomographic spins, the master motions of each scan, expected to clock the detector triggering (SAMPLE-1).
+- **The sample and detector positioning stages bind the catalog `LinearStage`.** Sample centring (with the `XYOnRotation` pseudo-axis keeping the sample on the rotation axis) and the detector propagation distance are plain linear motion (SAMPLE-1, DET-1).
+- **The detectors bind the catalog `Camera`, which presents the Detector Role.** ID19's indirect-detection area detectors (interchangeable Frelon CCD, PCO 4k, PCO Dimax high-speed, and Basler Lima cameras) are thin `Camera` instances (DET-1).
+- **The optics bind existing Families.** `Monochromator` (the TripleMono), `Slit` (primary / secondary), `Transfocator` (the white-beam Be-lens transfocator), `Filter` (the attenuator banks, folding in per the i03 precedent rather than a new `Attenuator` Family), `Shutter` (front-end and beam shutters), and `InsertionDevice` (the undulator / wiggler set).
+- **The technique is the existing `tomography` Method.** ID19 is a further consumer of the Method the 2-BM pilot and TomoWise carry; the Practice `ID19_microtomography_practice` is carried pending only because ID19 is not yet driven by CORA (TECH-1).
+
+ID19 coins no new Family, nothing graduates, and the catalog is unchanged.
+
+### Two endstations
+
+MR (micro-resolution) and HR (high-resolution) are distinct BLISS sessions (`MRTOMO`, `HRTOMO`) sharing the source and optics. CORA models each as its own sample and detection group under the shared experiment hutch: same Families, same `tomography` Method, different stage stack and magnification optic. This is a Practice-and-settings difference, not new vocabulary.
+
+### Deliberately not here yet
+
+- **The further endstations (`ENDSTATION-1`).** The config carries MH, MED, laminography (LATOMO, a MicosAnka-over-TCP controller with a tilt-transformation pusher), RADIO, PCOTOMO, the SmarAct multi-tower stack, and the FalconX / Mercury fluorescence MCAs. This cut models MR and HR, the two main tomography stations; the rest are noted, not modelled.
+- **The PSS permit signals (`PSS-1`).** The TangoShutter handles (`frontend`, `id19/bsh/1`, `id19/bsh/2`) are known, but the personnel-safety permit signals behind them are not in the config; carried pending, not invented.
+- **Vendor models, serials, and physical positions.** Not in the config; carried confirm.
+- **The simulated devices and full asset-tree scenarios.** No `test_id19_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the ID19 team to confirm before the model can be trusted.*
+
+ID19 was reverse-engineered from the beamline's own public BLISS Beacon device database ([`gitlab.esrf.fr/id19/beamline_configuration`](https://gitlab.esrf.fr/id19/beamline_configuration)), so the control handles on the [device pages](index.md) are the beamline's real BLISS object and Tango device names, read from the config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Control and the BLISS / Tango floor
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the BLISS object and Tango device handles read from the public config current and correct against the live system? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle on the BLISS floor. |
+| CTRL-2 | Nice-to-have | Which BLISS scan procedure(s) ID19 uses per endstation (continuous / fly versus step), and which the CORA edge drives through versus replaces. | A continuous-rotation scan clocked by the rotation stage; the conduct-versus-replace split is per routine. | The orchestration seam over the `ControlPort`. |
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and one experiment hutch holding both endstations, or a finer split? | One `id19-optics` and one `id19-experiment` enclosure. | The Enclosure grouping. |
+| ENDSTATION-1 | Nice-to-have | The further endstations in the config (MH, MED, laminography LATOMO, RADIO, PCOTOMO, the SmarAct towers, the fluorescence MCAs): are they distinct endstations CORA should model? | Noted, not modelled in this cut; MR and HR are the two main tomography stations. | The remaining endstation roster. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | Which insertion device(s) feed which endstation / mode, and the energy reach. | The undulators (u13a/u32a/u17-6c/u32c) and the w150b wiggler, selected per mode; the wiggler drives white-beam tomography. | The source Asset and mode mapping. |
+| OPT-1 | Blocks-go-live | The TripleMono crystal-pair / Laue / multilayer mode mapping, the transfocator lens recipe per energy, and the attenuator foil set. | TripleMono Bragg 17-99 keV plus Laue / multilayer; 8 Be transfocator lenses; Cu/Al attenuator banks folding into Filter. | The optics modelling. |
+
+### Endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The operative rotation and sample-positioning axis set per endstation (the config carries spare / commented axes). | MR: mrsrot + mrsx/mrsy/mrxc/mryc; HR: hrsrot + hrsx/hrsy/hrsz/hrz0; XYOnRotation centring on each. | The sample-stage modelling. |
+| DET-1 | Blocks-go-live | The operative Lima detector(s) and the indirect-detection optics per endstation, and the propagation-stage axes. | Interchangeable Frelon / PCO / Basler Lima cameras bound to `Camera`; the propagation stage binds `LinearStage`. | The detector modelling. |
+
+### Safety and resources
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| PSS-1 | Blocks-go-live | The ESRF PSS search-and-secure permit signals behind the frontend / bsh shutters (not in the config). | Permit leaves to be named; the TangoShutter handles are known, the permit signals are not. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent of the beam path and the cooling-water / beam supplies a run draws on. | Photon beam, cooling water, and vacuum, carried pending. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level, shared across beamlines). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does ID19 microtomography map cleanly onto the existing `tomography` Method, or does parallel-beam / phase-contrast imaging want a distinct Method? | The existing `tomography` Method, a further consumer; carried as a pending Practice. | The microtomography Practice. |
diff --git a/docs/deployments/id19/questions.md b/docs/deployments/id19/questions.md
deleted file mode 100644
index 59d24c6266c..00000000000
--- a/docs/deployments/id19/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the ID19 team to confirm before the model can be trusted.*
-
-ID19 was reverse-engineered from the beamline's own public BLISS Beacon device database ([`gitlab.esrf.fr/id19/beamline_configuration`](https://gitlab.esrf.fr/id19/beamline_configuration)), so the control handles on the [device pages](index.md) are the beamline's real BLISS object and Tango device names, read from the config rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Control and the BLISS / Tango floor
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the BLISS object and Tango device handles read from the public config current and correct against the live system? | The handles in the descriptor are taken from the config and carried confirm. | Verifying each Asset's control handle on the BLISS floor. |
-| CTRL-2 | Nice-to-have | Which BLISS scan procedure(s) ID19 uses per endstation (continuous / fly versus step), and which the CORA edge drives through versus replaces. | A continuous-rotation scan clocked by the rotation stage; the conduct-versus-replace split is per routine. | The orchestration seam over the `ControlPort`. |
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and one experiment hutch holding both endstations, or a finer split? | One `id19-optics` and one `id19-experiment` enclosure. | The Enclosure grouping. |
-| ENDSTATION-1 | Nice-to-have | The further endstations in the config (MH, MED, laminography LATOMO, RADIO, PCOTOMO, the SmarAct towers, the fluorescence MCAs): are they distinct endstations CORA should model? | Noted, not modelled in this cut; MR and HR are the two main tomography stations. | The remaining endstation roster. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | Which insertion device(s) feed which endstation / mode, and the energy reach. | The undulators (u13a/u32a/u17-6c/u32c) and the w150b wiggler, selected per mode; the wiggler drives white-beam tomography. | The source Asset and mode mapping. |
-| OPT-1 | Blocks-go-live | The TripleMono crystal-pair / Laue / multilayer mode mapping, the transfocator lens recipe per energy, and the attenuator foil set. | TripleMono Bragg 17-99 keV plus Laue / multilayer; 8 Be transfocator lenses; Cu/Al attenuator banks folding into Filter. | The optics modelling. |
-
-## Endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The operative rotation and sample-positioning axis set per endstation (the config carries spare / commented axes). | MR: mrsrot + mrsx/mrsy/mrxc/mryc; HR: hrsrot + hrsx/hrsy/hrsz/hrz0; XYOnRotation centring on each. | The sample-stage modelling. |
-| DET-1 | Blocks-go-live | The operative Lima detector(s) and the indirect-detection optics per endstation, and the propagation-stage axes. | Interchangeable Frelon / PCO / Basler Lima cameras bound to `Camera`; the propagation stage binds `LinearStage`. | The detector modelling. |
-
-## Safety and resources
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| PSS-1 | Blocks-go-live | The ESRF PSS search-and-secure permit signals behind the frontend / bsh shutters (not in the config). | Permit leaves to be named; the TangoShutter handles are known, the permit signals are not. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent of the beam path and the cooling-water / beam supplies a run draws on. | Photon beam, cooling water, and vacuum, carried pending. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level, shared across beamlines). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does ID19 microtomography map cleanly onto the existing `tomography` Method, or does parallel-beam / phase-contrast imaging want a distinct Method? | The existing `tomography` Method, a further consumer; carried as a pending Practice. | The microtomography Practice. |
diff --git a/docs/deployments/id19/techniques.md b/docs/deployments/id19/techniques.md
deleted file mode 100644
index 4c0d5562618..00000000000
--- a/docs/deployments/id19/techniques.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Techniques
-
-*What CORA would run at ID19: hard X-ray parallel-beam microtomography, radiography, and propagation phase-contrast imaging, a [Catalog](../../catalog/methods.md) Method bound through an [ESRF Practice](../esrf/index.md#the-techniques-adapted-here). The technique is plain tomography reuse; the genuine novelty at ID19 is the control floor, not the science.*
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Parallel-beam microtomography / radiography / phase-contrast imaging | `tomography` | the sample is spun through the beam while an area detector records a stack of projection radiographs; a real-space volume is reconstructed downstream. The existing Method the 2-BM pilot and MAX IV TomoWise carry; ID19 is a further consumer (TECH-1) |
-
-The technique is recorded as a pending [Practice](../esrf/index.md#the-techniques-adapted-here) on the ESRF Site, `ID19_microtomography_practice` (TECH-1).
-
-## The acquisition shape
-
-Microtomography is an acquisition shape CORA already models. The [rotation stage](sample.md) spins the sample through the beam; the [detector](detector.md) records a projection radiograph at each angle; and the stack of projections, together with the known rotation angles, is enough to reconstruct a real-space volume of the sample. ID19's long source-to-sample distance gives the beam high spatial coherence, so a settable sample-to-detector distance turns the same acquisition into propagation phase-contrast imaging (DET-1). The reconstruction, turning the projection stack into a volume, is `ComputePort` work, not a beamline device, the same reconstruction leg the other imaging beamlines carry.
-
-ID19 runs this acquisition at two endstations sharing one source and optics: the micro-resolution (MR) station for large-field, high-throughput tomography, and the high-resolution (HR) station for small-field, high-resolution tomography. Both are the same Method; the difference is the stage stack and the magnification optic, a Practice-and-settings difference, not a new technique.
-
-So the parts are a `RotaryStage` (the tomographic spin, the master motion, SAMPLE-1), a `LinearStage` for sample centring (SAMPLE-1), a `Camera` as the area detector (interchangeable Frelon / PCO / Basler Lima cameras, DET-1), and a `LinearStage` setting the detector propagation distance (DET-1). None is new; ID19 reuses the existing tomography device shapes exactly.
-
-## Why the technique is not the novelty
-
-ID19 is a microtomography beamline, and CORA already models microtomography at the 2-BM operational pilot and the MAX IV TomoWise design scaffold. The `tomography` Method, its Capability, and the device families it binds are all in place. ID19 is a further consumer of that Method, not a new technique, so the Practice is carried pending only because ID19 is not yet driven by CORA, not because the Method is new (TECH-1).
-
-The genuine novelty at ID19 is one layer down, in the control plane: ESRF runs BLISS (a Tango-based control system), not EPICS, and ID19 is the first to bring that BLISS floor to tomographic imaging (its ESRF sibling ID32 opened it for soft X-ray RIXS). That is a [Controls](controls.md) and seam concern, not a technique concern. Holding the technique constant is the point: it isolates the control-plane axis so the BLISS / Tango floor is the only thing that is new (see [Model](model.md)).
-
-## Not modelled yet
-
-This cut models the source, the optics, and the two main tomography endstations (MR and HR). The further endstations present in the ID19 config are noted but not modelled:
-
-- The MH and MED tomography endstations, their own BLISS sessions with their own stage stacks (ENDSTATION-1).
-- The LATOMO laminography endstation, which runs a MicosAnka controller over TCP plus a tilt-transformation pusher, a distinct acquisition geometry (ENDSTATION-1).
-- The RADIO (radiography) and PCOTOMO (PCO high-speed tomography) sessions (ENDSTATION-1).
-- The SmarAct multi-tower sample stack and the FalconX / Mercury fluorescence MCAs (ENDSTATION-1).
-
-Each is named on the [Open questions](questions.md) page rather than modelled speculatively. The source walk that grounds what is and is not present is the generated [beamline](source.md) view.
diff --git a/docs/deployments/id28/governance.md b/docs/deployments/id28/governance.md
deleted file mode 100644
index f1426dc31be..00000000000
--- a/docs/deployments/id28/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at ID28, and the trust shape that will gate it. First cut.*
-
-Governance at ID28 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-ID28 is CORA's second ESRF beamline, so the ESRF Site already exists (established with ID32): the operator pool and the safety-review structure are carried pending on the [ESRF Site](../esrf/index.md#safety-and-governance), shared across the facility's beamlines, until ESRF staff confirm them (`GOV-1`). ID28 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives ID28, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The ESRF personnel-safety permit signals and the photon and front-end shutters are absent from the BLISS Beacon config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ESRF Site](../esrf/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-ID28 adds the hazard classes that come with its endstation: a cryogenic sample environment (the 10 K displex cryostat and the cryogens it draws on) and a hard X-ray beam. Those land with the instruments that bring them, and an experiment Clearance would carry them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ID28, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/id28/model.md b/docs/deployments/id28/model.md
deleted file mode 100644
index e19e3d05056..00000000000
--- a/docs/deployments/id28/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ID28 content lives, why it coins no new family and adds a further SpectrometerArm consumer, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ID28 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy PseudoAxis, realized over the F700 temperature controller) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes ID28 new
-
-ID28 is CORA's second ESRF beamline (after ID32), and it deepens the fleet's inelastic-scattering coverage with a distinct flavor: **momentum-resolved hard X-ray inelastic scattering (IXS)**. A high-resolution backscattering monochromator sets a meV-resolution incident energy, the sample scatters, and a multi-analyzer crystal spectrometer on a two-theta arm energy-analyzes the scattered beam in backscattering, mapping phonon and collective-excitation dispersions across momentum transfer. The fleet already has soft RIXS (SIX, ID32) and the NSLS-II IXS beamline; ID28 is the ESRF hard X-ray IXS instrument, reusing the pending `inelastic_x_ray_scattering` Method as the second consumer (`TECH-1`).
-
-The second value is the Site re-test: ID28 exercises the ESRF Site and the BLISS / Tango / IcePAP control plane a second time, confirming the ID32 house-style modelling generalizes within the facility.
-
-A modelling note worth surfacing: ID28's incident energy is **not** scanned by a Bragg angle. The high-resolution backscattering monochromator selects energy by the silicon crystal's lattice spacing, which is tuned by **temperature** (the ASL F700 controller carries a paired `monot` setpoint / `deltae` energy axis). CORA still models the incident energy as a `PseudoAxis`, but it is realized over the F700 temperature controller rather than a goniometer, so the `Monochromator` Asset and the `BeamEnergy` `PseudoAxis` are decoupled in a way an angle-scanned beamline's are not. This is the kind of mechanism the descriptor records (read from the config) so the model is intentional, not a mirror of an angular-mono assumption.
-
-## A further SpectrometerArm consumer, held
-
-ID28's IXS spectrometer is a `TwoThetaMultilayer` two-theta arm carrying an array of inclined analyzer crystals (`a2_inca` / `a3_inca` / `a4_inca`, each with chi / th), which binds the `SpectrometerArm` Family. This is a **further consumer** of the family that SIX coined and ID32 brought to a rule-of-three (SIX RIXS arm + ID32 RIXS arm + ID32 XES arm). ID28 is a further sighting that reinforced it, and the family has since **graduated** into the catalog (`RIXS-1`); ID28's arm binds it like any catalog Family, so this scaffold makes no catalog change of its own.
-
-`SpectrometerArm` is the right home: it is an arm that **positions** an energy-dispersing element (here a crystal array, at SIX / ID32 a grating) and **carries** a detector, presenting the `Positioner` Role, which is why it never fit the point-Sensor families.
-
-## No new families
-
-Beyond the graduated `SpectrometerArm`, ID28 reuses the catalog throughout: the backscattering monochromator binds `Monochromator` (the meV backscattering reflection is a per-Asset setting); the HFM / VFM benders bind `Mirror`; the beam-defining slits bind `Slit`; the two in-vacuum undulators bind `InsertionDevice`; the incident energy is a `PseudoAxis` realized over the ASL F700 backscattering-crystal temperature controller (`monot` / `deltae`), not over a Bragg angle; the Basler / PCO detectors bind `Camera`; the sample-temperature environments (the 10 K displex LakeShore 340, the Oxford 700, the nanodac gas blower) bind `TemperatureController`; the oh2 Elettra beam-position monitor binds the graduated catalog `PositionMonitor` (presenting the `Sensor` Role, distinct from `FluxMonitor` by measuring beam position rather than flux); the front-end shutter binds `Shutter`; and the machine state binds the loose `StorageRing` via the BLISS MachInfo.
-
-## Deliberately not here yet
-
-- **The analyzer-crystal array identity (`IXS-1`).** The multi-analyzer arm carries an array of inclined analyzer crystals, each with its own chi / th and cylinder slit. The config provisions nine analyzer-slit positions (`a1h..a9h` / `a1v..a9v`) and `inca` controllers for `a2` / `a3` / `a4`; how many crystals are populated is `IXS-1`. The first cut carries the array as a per-Asset setting on the one `SpectrometerArm` Asset; promoting each crystal to a child Asset via `parent_id` is the nested-component-identity convention, itself at a rule-of-three gate (the IXS 10-ID diced-crystal `XTAL-1` question is the sibling), so ID28 flags it rather than asserting it.
-- **The SpectrometerArm graduation (`RIXS-1`).** Landed; the family graduated into the catalog (SIX + ID32 RIXS/XES + ID28), so ID28's arm binds it directly. Only the per-Asset arm geometry stays pending.
-- **The exact sample-stage and per-analyzer-detector handles (`SAMPLE-1`, `DET-1`).** Carried confirm-pending; the spectrometer arm, mono, mirrors, and sample cryostats carry their real BLISS handles.
-- **The IXS Method.** Whether momentum-resolved IXS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the NSLS-II IXS slug (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_id28_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/id28/notes.md b/docs/deployments/id28/notes.md
new file mode 100644
index 00000000000..cd63ce88420
--- /dev/null
+++ b/docs/deployments/id28/notes.md
@@ -0,0 +1,129 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of ID28 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../esrf/index.md#the-techniques-adapted-here) is how a facility adapts it. ID28 runs momentum-resolved hard X-ray inelastic scattering, a Method not yet in CORA's catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Momentum-resolved inelastic X-ray scattering
+
+ID28 sets a meV-resolution incident energy with the high-resolution backscattering monochromator (scanned by tuning the crystal temperature, not a Bragg angle), places the multi-analyzer spectrometer arm at a scattering angle that selects the momentum transfer, and scans the incident energy against the fixed-angle analyzer crystals, counting the energy-analyzed scattered photons. The measurement is the intensity surface I(Q, energy-loss): how much energy the sample exchanges with the photon at a chosen momentum transfer, the signature of phonons and collective excitations.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Momentum-resolved inelastic X-ray scattering | `inelastic_x_ray_scattering` | the momentum transfer Q is set by the [spectrometer-arm two-theta](detector.md); the meV incident energy is scanned on the [backscattering monochromator](source.md) against the fixed-angle [multi-analyzer crystals](detector.md); the energy-analyzed signal is counted per analyzer; reuses the NSLS-II IXS Method, the second consumer; Method not yet in catalog |
+
+It needs the [incident-energy chain](source.md) (the backscattering mono for the meV resolution), the [sample stage and its temperature environment](sample.md), and the [multi-analyzer spectrometer arm and its detectors](detector.md). The arm scattering angle sets the magnitude of the momentum transfer; the analyzer crystals fix the analyzed energy so the incident-energy scan reads out the energy loss.
+
+### The same inelastic axis, in the hard X-ray regime
+
+ID28 is the fleet's hard X-ray IXS instrument. The catalog already anticipates inelastic scattering (the SIX soft RIXS arm, the NSLS-II IXS beamline, the ID32 soft RIXS / XES arms), and ID28 reuses the `inelastic_x_ray_scattering` Method the NSLS-II IXS beamline left pending as the second consumer, deepening the case for that Capability without coining anything. The device that ties the inelastic beamlines together is the dispersive spectrometer arm: ID28's multi-analyzer crystal arm is a further consumer of the `SpectrometerArm` family, the sighting that reinforced the graduation earned at ID32, now landed as a catalog Family (see [Model](#a-further-spectrometerarm-consumer-held)).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the per-Q energy scans, the analyzer alignment, the counting times, the analyzer-crystal array calibration) are not written yet; they join as the deployment approaches the point where CORA drives ID28. Whether momentum-resolved IXS enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at ID28, and the trust shape that will gate it. First cut.*
+
+Governance at ID28 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+ID28 is CORA's second ESRF beamline, so the ESRF Site already exists (established with ID32): the operator pool and the safety-review structure are carried pending on the [ESRF Site](../esrf/index.md#safety-and-governance), shared across the facility's beamlines, until ESRF staff confirm them (`GOV-1`). ID28 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives ID28, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The ESRF personnel-safety permit signals and the photon and front-end shutters are absent from the BLISS Beacon config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ESRF Site](../esrf/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+ID28 adds the hazard classes that come with its endstation: a cryogenic sample environment (the 10 K displex cryostat and the cryogens it draws on) and a hard X-ray beam. Those land with the instruments that bring them, and an experiment Clearance would carry them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ID28, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ID28 content lives, why it coins no new family and adds a further SpectrometerArm consumer, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ID28 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy PseudoAxis, realized over the F700 temperature controller) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes ID28 new
+
+ID28 is CORA's second ESRF beamline (after ID32), and it deepens the fleet's inelastic-scattering coverage with a distinct flavor: **momentum-resolved hard X-ray inelastic scattering (IXS)**. A high-resolution backscattering monochromator sets a meV-resolution incident energy, the sample scatters, and a multi-analyzer crystal spectrometer on a two-theta arm energy-analyzes the scattered beam in backscattering, mapping phonon and collective-excitation dispersions across momentum transfer. The fleet already has soft RIXS (SIX, ID32) and the NSLS-II IXS beamline; ID28 is the ESRF hard X-ray IXS instrument, reusing the pending `inelastic_x_ray_scattering` Method as the second consumer (`TECH-1`).
+
+The second value is the Site re-test: ID28 exercises the ESRF Site and the BLISS / Tango / IcePAP control plane a second time, confirming the ID32 house-style modelling generalizes within the facility.
+
+A modelling note worth surfacing: ID28's incident energy is **not** scanned by a Bragg angle. The high-resolution backscattering monochromator selects energy by the silicon crystal's lattice spacing, which is tuned by **temperature** (the ASL F700 controller carries a paired `monot` setpoint / `deltae` energy axis). CORA still models the incident energy as a `PseudoAxis`, but it is realized over the F700 temperature controller rather than a goniometer, so the `Monochromator` Asset and the `BeamEnergy` `PseudoAxis` are decoupled in a way an angle-scanned beamline's are not. This is the kind of mechanism the descriptor records (read from the config) so the model is intentional, not a mirror of an angular-mono assumption.
+
+### A further SpectrometerArm consumer, held
+
+ID28's IXS spectrometer is a `TwoThetaMultilayer` two-theta arm carrying an array of inclined analyzer crystals (`a2_inca` / `a3_inca` / `a4_inca`, each with chi / th), which binds the `SpectrometerArm` Family. This is a **further consumer** of the family that SIX coined and ID32 brought to a rule-of-three (SIX RIXS arm + ID32 RIXS arm + ID32 XES arm). ID28 is a further sighting that reinforced it, and the family has since **graduated** into the catalog (`RIXS-1`); ID28's arm binds it like any catalog Family, so this scaffold makes no catalog change of its own.
+
+`SpectrometerArm` is the right home: it is an arm that **positions** an energy-dispersing element (here a crystal array, at SIX / ID32 a grating) and **carries** a detector, presenting the `Positioner` Role, which is why it never fit the point-Sensor families.
+
+### No new families
+
+Beyond the graduated `SpectrometerArm`, ID28 reuses the catalog throughout: the backscattering monochromator binds `Monochromator` (the meV backscattering reflection is a per-Asset setting); the HFM / VFM benders bind `Mirror`; the beam-defining slits bind `Slit`; the two in-vacuum undulators bind `InsertionDevice`; the incident energy is a `PseudoAxis` realized over the ASL F700 backscattering-crystal temperature controller (`monot` / `deltae`), not over a Bragg angle; the Basler / PCO detectors bind `Camera`; the sample-temperature environments (the 10 K displex LakeShore 340, the Oxford 700, the nanodac gas blower) bind `TemperatureController`; the oh2 Elettra beam-position monitor binds the graduated catalog `PositionMonitor` (presenting the `Sensor` Role, distinct from `FluxMonitor` by measuring beam position rather than flux); the front-end shutter binds `Shutter`; and the machine state binds the loose `StorageRing` via the BLISS MachInfo.
+
+### Deliberately not here yet
+
+- **The analyzer-crystal array identity (`IXS-1`).** The multi-analyzer arm carries an array of inclined analyzer crystals, each with its own chi / th and cylinder slit. The config provisions nine analyzer-slit positions (`a1h..a9h` / `a1v..a9v`) and `inca` controllers for `a2` / `a3` / `a4`; how many crystals are populated is `IXS-1`. The first cut carries the array as a per-Asset setting on the one `SpectrometerArm` Asset; promoting each crystal to a child Asset via `parent_id` is the nested-component-identity convention, itself at a rule-of-three gate (the IXS 10-ID diced-crystal `XTAL-1` question is the sibling), so ID28 flags it rather than asserting it.
+- **The SpectrometerArm graduation (`RIXS-1`).** Landed; the family graduated into the catalog (SIX + ID32 RIXS/XES + ID28), so ID28's arm binds it directly. Only the per-Asset arm geometry stays pending.
+- **The exact sample-stage and per-analyzer-detector handles (`SAMPLE-1`, `DET-1`).** Carried confirm-pending; the spectrometer arm, mono, mirrors, and sample cryostats carry their real BLISS handles.
+- **The IXS Method.** Whether momentum-resolved IXS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the NSLS-II IXS slug (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_id28_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the ID28 team to confirm before the model can be trusted.*
+
+ID28 was reverse-engineered from the ESRF's open BLISS Beacon device database ([gitlab.esrf.fr/id28/beamline_configuration](https://gitlab.esrf.fr/id28/beamline_configuration), a git mirror of the live config), so the control handles on the [device pages](index.md) are the beamline's real BLISS / Tango / IcePAP addresses, read from the config rather than confirmed by staff (the ID32 house-style precedent). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics zone (oh1 / oh2 / oh3) feeding the eh1 spectrometer endstation, or a different layout? | A shared `id28-optics` zone and the `id28-eh1` experiment hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The period and segment count of the two in-vacuum undulators (`u22gap` IVU22a, `u133gap` IVU13-3c). | Two in-vacuum undulators on the ESRF_Undulator device server; the names imply 22 mm and 13 mm periods, segment detail pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The ESRF-EBS storage-ring state ID28 reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The backscattering crystal / reflection, the meV energy resolution, the energy-scan partition rule, and the premono (OH1) / postmono (OH2) roles ahead of the main mono (OH3). | A `Monochromator` on the PI E518 piezo (`pimth` / `pimchi`); the meV energy is scanned by the ASL F700 crystal-temperature axis (`monot` / `deltae`), not a Bragg angle; energy is a `PseudoAxis` over the F700. | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The HFM / VFM mirror coatings and bender mechanics. | Two-bender focusing mirrors bound to `Mirror`. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis map of the primary, mono, and sample slits. | Beam-defining `Slit` Assets (BLISS `slits_ph` / `slits_pv` / `slits_mx` / `slits_sh` / `slits_sv`); each with horizontal / vertical gap and offset. | The slit Asset detail. |
+| DIAG-1 | Nice-to-have | The oh2 Elettra beam-position monitor channel map: it binds the graduated catalog `PositionMonitor` (position-measuring), distinct from `FluxMonitor`; the per-Asset position-vs-flux channel detail is the residual. | The graduated catalog `PositionMonitor` (presenting `Sensor`); channel map pending. | The beam-position channel map. |
+
+### The IXS spectrometer endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| RIXS-1 | Blocks-go-live | The multi-analyzer spectrometer arm (the `TwoThetaMultilayer` two-theta arm carrying the inclined analyzer crystals): the per-Asset arm geometry and axis map. | The arm binds the catalog `SpectrometerArm` Family (graduated across SIX + ID32 RIXS/XES + ID28); the per-Asset geometry stays pending. | The spectrometer-arm geometry; the family graduation is settled (see [Model](#a-further-spectrometerarm-consumer-held)). |
+| IXS-1 | Blocks-go-live | The analyzer-crystal array: the config shows analyzer slits a1..a9 and inclined-analyzer (`inca`) controllers for a2 / a3 / a4 (each with chi / th); how many crystals are populated, and whether they are one arm Asset or identity-bearing child Assets. | One `SpectrometerArm` Asset carrying the crystal array as a per-Asset setting, not child Assets. | The analyzer-array modelling; the CORA structural choice is on [Model](#deliberately-not-here-yet). |
+| SAMPLE-1 | Blocks-go-live | The IXS sample-positioning stage axes: which of the scattering-geometry axes (`sax` / `say` / `saz`, `th` / `sphi` / `chi`), the eh1_ss `iceid285` (`phi` / `omega` / `sz`), and the SmarAct fine stage make up the modelled stage. | A `LinearStage`; axis set pending. | The sample-stage modelling. |
+| TEMP-1 | Nice-to-have | The sample-temperature environments (the 10 K displex LakeShore 340, the Oxford 700 cryostream, the nanodac gas blower) and which is the default. | `TemperatureController` Assets presenting the `Regulator` Role. | The temperature-control modelling. |
+| DET-1 | Blocks-go-live | The per-analyzer IXS photon detectors and the Basler / PCO imaging cameras: how the `deta1..deta9` P201 counters and the `izero` / `ione` monitors map to the analyzer crystals. | The Basler and PCO bind `Camera`; the per-analyzer `deta1..deta9` counters and the `izero` / `ione` beam monitors are read from the config, the crystal map pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the BLISS / Tango / IcePAP handles read from the public Beacon config current and correct? | The handles in the descriptor are taken from the BLISS config and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The ESRF personnel-safety permit signals behind the shutters. The config exposes the front-end shutter (`fe`) and the vacuum beam shutters (`bsh1` / `bsh2` / `bsh3` on `id28/v-bsh/0..2`), but not the PSS permit leaves. | The shutters are modelled (`FrontEndShutter`, the `bsh*` leaves carried on the enclosures); the permit signals behind them are to be named, not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the displex cryostat cryogen supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does momentum-resolved IXS enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `inelastic_x_ray_scattering` Method NSLS-II IXS left pending, the second consumer; none coined. | The IXS Capability. |
diff --git a/docs/deployments/id28/questions.md b/docs/deployments/id28/questions.md
deleted file mode 100644
index fe2aee60c1e..00000000000
--- a/docs/deployments/id28/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the ID28 team to confirm before the model can be trusted.*
-
-ID28 was reverse-engineered from the ESRF's open BLISS Beacon device database ([gitlab.esrf.fr/id28/beamline_configuration](https://gitlab.esrf.fr/id28/beamline_configuration), a git mirror of the live config), so the control handles on the [device pages](index.md) are the beamline's real BLISS / Tango / IcePAP addresses, read from the config rather than confirmed by staff (the ID32 house-style precedent). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics zone (oh1 / oh2 / oh3) feeding the eh1 spectrometer endstation, or a different layout? | A shared `id28-optics` zone and the `id28-eh1` experiment hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The period and segment count of the two in-vacuum undulators (`u22gap` IVU22a, `u133gap` IVU13-3c). | Two in-vacuum undulators on the ESRF_Undulator device server; the names imply 22 mm and 13 mm periods, segment detail pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The ESRF-EBS storage-ring state ID28 reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The backscattering crystal / reflection, the meV energy resolution, the energy-scan partition rule, and the premono (OH1) / postmono (OH2) roles ahead of the main mono (OH3). | A `Monochromator` on the PI E518 piezo (`pimth` / `pimchi`); the meV energy is scanned by the ASL F700 crystal-temperature axis (`monot` / `deltae`), not a Bragg angle; energy is a `PseudoAxis` over the F700. | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The HFM / VFM mirror coatings and bender mechanics. | Two-bender focusing mirrors bound to `Mirror`. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis map of the primary, mono, and sample slits. | Beam-defining `Slit` Assets (BLISS `slits_ph` / `slits_pv` / `slits_mx` / `slits_sh` / `slits_sv`); each with horizontal / vertical gap and offset. | The slit Asset detail. |
-| DIAG-1 | Nice-to-have | The oh2 Elettra beam-position monitor channel map: it binds the graduated catalog `PositionMonitor` (position-measuring), distinct from `FluxMonitor`; the per-Asset position-vs-flux channel detail is the residual. | The graduated catalog `PositionMonitor` (presenting `Sensor`); channel map pending. | The beam-position channel map. |
-
-## The IXS spectrometer endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| RIXS-1 | Blocks-go-live | The multi-analyzer spectrometer arm (the `TwoThetaMultilayer` two-theta arm carrying the inclined analyzer crystals): the per-Asset arm geometry and axis map. | The arm binds the catalog `SpectrometerArm` Family (graduated across SIX + ID32 RIXS/XES + ID28); the per-Asset geometry stays pending. | The spectrometer-arm geometry; the family graduation is settled (see [Model](model.md#a-further-spectrometerarm-consumer-held)). |
-| IXS-1 | Blocks-go-live | The analyzer-crystal array: the config shows analyzer slits a1..a9 and inclined-analyzer (`inca`) controllers for a2 / a3 / a4 (each with chi / th); how many crystals are populated, and whether they are one arm Asset or identity-bearing child Assets. | One `SpectrometerArm` Asset carrying the crystal array as a per-Asset setting, not child Assets. | The analyzer-array modelling; the CORA structural choice is on [Model](model.md#deliberately-not-here-yet). |
-| SAMPLE-1 | Blocks-go-live | The IXS sample-positioning stage axes: which of the scattering-geometry axes (`sax` / `say` / `saz`, `th` / `sphi` / `chi`), the eh1_ss `iceid285` (`phi` / `omega` / `sz`), and the SmarAct fine stage make up the modelled stage. | A `LinearStage`; axis set pending. | The sample-stage modelling. |
-| TEMP-1 | Nice-to-have | The sample-temperature environments (the 10 K displex LakeShore 340, the Oxford 700 cryostream, the nanodac gas blower) and which is the default. | `TemperatureController` Assets presenting the `Regulator` Role. | The temperature-control modelling. |
-| DET-1 | Blocks-go-live | The per-analyzer IXS photon detectors and the Basler / PCO imaging cameras: how the `deta1..deta9` P201 counters and the `izero` / `ione` monitors map to the analyzer crystals. | The Basler and PCO bind `Camera`; the per-analyzer `deta1..deta9` counters and the `izero` / `ione` beam monitors are read from the config, the crystal map pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the BLISS / Tango / IcePAP handles read from the public Beacon config current and correct? | The handles in the descriptor are taken from the BLISS config and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The ESRF personnel-safety permit signals behind the shutters. The config exposes the front-end shutter (`fe`) and the vacuum beam shutters (`bsh1` / `bsh2` / `bsh3` on `id28/v-bsh/0..2`), but not the PSS permit leaves. | The shutters are modelled (`FrontEndShutter`, the `bsh*` leaves carried on the enclosures); the permit signals behind them are to be named, not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the displex cryostat cryogen supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does momentum-resolved IXS enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `inelastic_x_ray_scattering` Method NSLS-II IXS left pending, the second consumer; none coined. | The IXS Capability. |
diff --git a/docs/deployments/id28/techniques.md b/docs/deployments/id28/techniques.md
deleted file mode 100644
index 14a0d810633..00000000000
--- a/docs/deployments/id28/techniques.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Techniques
-
-*What the modelled part of ID28 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../esrf/index.md#the-techniques-adapted-here) is how a facility adapts it. ID28 runs momentum-resolved hard X-ray inelastic scattering, a Method not yet in CORA's catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Momentum-resolved inelastic X-ray scattering
-
-ID28 sets a meV-resolution incident energy with the high-resolution backscattering monochromator (scanned by tuning the crystal temperature, not a Bragg angle), places the multi-analyzer spectrometer arm at a scattering angle that selects the momentum transfer, and scans the incident energy against the fixed-angle analyzer crystals, counting the energy-analyzed scattered photons. The measurement is the intensity surface I(Q, energy-loss): how much energy the sample exchanges with the photon at a chosen momentum transfer, the signature of phonons and collective excitations.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Momentum-resolved inelastic X-ray scattering | `inelastic_x_ray_scattering` | the momentum transfer Q is set by the [spectrometer-arm two-theta](detector.md); the meV incident energy is scanned on the [backscattering monochromator](source.md) against the fixed-angle [multi-analyzer crystals](detector.md); the energy-analyzed signal is counted per analyzer; reuses the NSLS-II IXS Method, the second consumer; Method not yet in catalog |
-
-It needs the [incident-energy chain](source.md) (the backscattering mono for the meV resolution), the [sample stage and its temperature environment](sample.md), and the [multi-analyzer spectrometer arm and its detectors](detector.md). The arm scattering angle sets the magnitude of the momentum transfer; the analyzer crystals fix the analyzed energy so the incident-energy scan reads out the energy loss.
-
-## The same inelastic axis, in the hard X-ray regime
-
-ID28 is the fleet's hard X-ray IXS instrument. The catalog already anticipates inelastic scattering (the SIX soft RIXS arm, the NSLS-II IXS beamline, the ID32 soft RIXS / XES arms), and ID28 reuses the `inelastic_x_ray_scattering` Method the NSLS-II IXS beamline left pending as the second consumer, deepening the case for that Capability without coining anything. The device that ties the inelastic beamlines together is the dispersive spectrometer arm: ID28's multi-analyzer crystal arm is a further consumer of the `SpectrometerArm` family, the sighting that reinforced the graduation earned at ID32, now landed as a catalog Family (see [Model](model.md#a-further-spectrometerarm-consumer-held)).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the per-Q energy scans, the analyzer alignment, the counting times, the analyzer-crystal array calibration) are not written yet; they join as the deployment approaches the point where CORA drives ID28. Whether momentum-resolved IXS enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/id32/governance.md b/docs/deployments/id32/governance.md
deleted file mode 100644
index 23726ff47df..00000000000
--- a/docs/deployments/id32/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at ID32, and the trust shape that will gate it. First cut.*
-
-Governance at ID32 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-ID32 is CORA's first ESRF deployment, so the ESRF is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ESRF Site](../esrf/index.md#safety-and-governance), shared across the facility's beamlines, until ESRF staff confirm them (`GOV-1`). ID32 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives ID32, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The ESRF personnel-safety permit signals and the photon and front-end shutters are absent from the BLISS Beacon config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ESRF Site](../esrf/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-ID32 adds the hazard classes that come with its endstations: a 9 Tesla superconducting magnet and its liquid-helium cryogen plant at the XMCD endstation, and an intense polarized soft X-ray beam. Those land with the instruments that bring them, and an experiment Clearance would carry them; the magnet and its cryogens are modelled as hazards on the experiment, not as Assets CORA drives for safety (the LASER-1 / sample-environment precedent).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ID32, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/id32/model.md b/docs/deployments/id32/model.md
deleted file mode 100644
index 1d6a1f41f5a..00000000000
--- a/docs/deployments/id32/model.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ID32 content lives, the graduations it earns, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ID32 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes ID32 new
-
-ID32 is two things the fleet has not had: a new Site and a new controls house-style. It is CORA's **seventh Site** (the ESRF, Grenoble), the biggest re-test of the Site and Federation kernel a single deployment can be, and the **first BLISS / Beacon / Tango / IcePAP** control plane CORA models (the rest are EPICS, or Tango / Sardana at MAX IV). Its science is soft X-ray resonant inelastic scattering (RIXS) with a ~5 m dispersive spectrometer arm, and X-ray magnetic dichroism (XMCD) plus X-ray emission spectroscopy (XES) at a 9 Tesla high-field-magnet endstation, all fed by twin APPLE-II undulators through a soft X-ray plane-grating monochromator.
-
-ID32 coins no new Family. The twin APPLE-II undulators bind the catalog `InsertionDevice`, and the polarization is a `PseudoAxis` over the undulator phase, exactly as i06 and i10 modelled their APPLE-II sources; the PGM binds `GratingMonochromator`; the 4-circle diffractometer binds `Goniometer` with a reciprocal-space `PseudoAxis` (the Assembly named, not built, DIFF-1 / DIFF-2); the Andor CCDs bind `Camera`; the LakeShore VTI and coil-diagnostic controllers bind `TemperatureController`; the XMCD sample stage binds `LinearStage`; the machine state binds the loose `StorageRing`.
-
-## Loose families brought to a rule-of-three (all since graduated)
-
-ID32 pushed three loose families to a genuine rule-of-three. Per the owner decision (2026-06-27) each graduation is a dedicated, gated catalog PR rather than bundled into this scaffold; all three have since **graduated**.
-
-| Loose family | Sightings with ID32 | ID32 binding | Status |
-| --- | --- | --- | --- |
-| `SpectrometerArm` | SIX + ID32 RIXS arm + ID32 XES arm + ID28 | the two dispersive spectrometer arms (the same `SpectrometerArmsController` class instantiated twice) | **graduated**: earned across SIX + ID32 RIXS/XES + ID28; presents the `Positioner` Role |
-| `Magnet` | 4-ID + i10-1 + ID32 | the 9 T / 4 T XMCD split-coil magnet | **graduated**: earned across 4-ID + i10-1 + ID32; presents the `Regulator` Role, the field a settable process variable (`MAG-1` now covers only the per-Asset field detail) |
-| `PolarizationAnalyzer` | 4-ID + i10 + ID32 + P09 | the RIXS scattered-beam polarimeter | **graduated** (`POL-2`): catalog Family across 4-ID / i10 / ID32 / P09, presents Positioner |
-
-Keeping each graduation as its own PR keeps the scaffold clean and lets each get its own naming-r3 and gate-review. `SpectrometerArm` was the clearest: it presents the `Positioner` Role (an arm that positions a grating and carries a `Camera` at its focus), which is exactly why it never fit the point-Sensor families (`FluxMonitor` / `EnergyDispersiveSpectrometer`) and was coined loose at SIX.
-
-## The BLISS / Tango control plane
-
-ID32 is the first non-EPICS, non-Sardana controls house-style in the fleet: BLISS / Beacon (a YAML device database) over Tango and IcePAP. CORA models the control handles as opaque edge strings regardless of transport, the way the MX3 heterogeneous-control precedent does: a Tango device URL (`id32/limaccds/andor_1`), an IcePAP host+address (`iceid324`), or a BLISS axis name is the handle, carried confirm (`CTRL-1`). The RIXS / XMCD / XES acquisition runs through BLISS sequences; that orchestration is the seam CORA's edge replaces, conducting over Tango / IcePAP rather than replacing BLISS.
-
-## Deliberately not here yet
-
-- **The graduations (`RIXS-1`, `MAG-1`, `POL-2`).** All three families ID32 brought to a rule-of-three, `SpectrometerArm`, `Magnet`, and `PolarizationAnalyzer`, have since graduated into the catalog via their dedicated gated PRs.
-- **The exact optics handles (`MONO-1`, `OPT-1`, `OPT-2`, `DIFF-1`, `SAMPLE-1`).** The PGM, mirrors, slits, diffractometer axes, and XMCD sample stage are carried confirm-pending; the decision-critical devices (the arms, the magnet, the LakeShores, the CCDs, the undulator) carry their real BLISS addresses.
-- **The Assembly(Diffractometer) and the reciprocal-space rule (`DIFF-1`, `DIFF-2`).** Named, not built, as the other diffractometer beamlines deferred theirs.
-- **The RIXS / XMCD / XES Methods.** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the SIX RIXS, the 4-ID / i06 / i10 XMCD, and the xas_spectroscopy XES slugs (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_id32_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/id32/notes.md b/docs/deployments/id32/notes.md
new file mode 100644
index 00000000000..30fc71ba3e5
--- /dev/null
+++ b/docs/deployments/id32/notes.md
@@ -0,0 +1,143 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of ID32 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../esrf/index.md#the-techniques-adapted-here) is how a facility adapts it. ID32 runs three soft X-ray techniques, all new to CORA's catalog, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### Resonant inelastic X-ray scattering, magnetic dichroism, emission
+
+ID32 sets the X-ray energy and polarization with the twin APPLE-II undulators and the plane-grating monochromator, then either disperses the inelastically scattered beam on a long spectrometer arm (RIXS), or measures the absorption asymmetry between polarizations in a high magnetic field (XMCD), or disperses the emitted beam (XES).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | the roughly 5 m dispersive [spectrometer arm](detector.md) on the RIXS endstation, scanned in energy against the [incident-energy axis](source.md); reuses the SIX RIXS Method, the second consumer; Method not yet in the catalog |
+| X-ray magnetic dichroism | `xmcd` | absorption asymmetry in the 9 T [XMCD magnet](sample.md) between circular / linear polarizations set on the [APPLE-II](source.md); reuses the 4-ID / i06 / i10 dichroism Method; pending |
+| X-ray emission spectroscopy | `xas_spectroscopy` | the [XES Rowland arm](detector.md) at the XMCD endstation; reuses the `xas_spectroscopy` Method that ISS / LCLS-MFX left pending for XES; pending |
+
+RIXS needs the [incident-energy and polarization axes](source.md), the [RIXS diffractometer](sample.md) to set the scattering geometry, and the [dispersive spectrometer arm and its CCD](detector.md). XMCD needs the polarization axis, the [9 T magnet and its VTI](sample.md), and a detection channel. XES needs the [emission spectrometer arm](detector.md).
+
+### A new operating axis for the fleet, on familiar vocabulary
+
+RIXS at ID32 is the fleet's second soft X-ray RIXS after SIX, and the dispersive spectrometer arm is the device that ties them together: the same `SpectrometerArmsController` anatomy that SIX coined loose, sighted three times across two sites (the ID32 RIXS arm, the ID32 XES arm, and SIX). That rule-of-three earned the graduation of the `SpectrometerArm` Family, which has since landed as a catalog Family (SIX + ID32 RIXS/XES + ID28; see [Model](#loose-families-brought-to-a-rule-of-three-all-since-graduated)). XMCD and XES likewise reuse the dichroism and emission Methods the fleet already carries pending; none forces a new device family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the RIXS energy maps and arm alignment, the XMCD field-and-polarization sequences, the XES scans, and the counting times) are not written yet; they join as the deployment approaches the point where CORA drives ID32. Whether RIXS, XMCD, and XES enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at ID32, and the trust shape that will gate it. First cut.*
+
+Governance at ID32 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [ESRF Site](../esrf/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+ID32 is CORA's first ESRF deployment, so the ESRF is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [ESRF Site](../esrf/index.md#safety-and-governance), shared across the facility's beamlines, until ESRF staff confirm them (`GOV-1`). ID32 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives ID32, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The ESRF personnel-safety permit signals and the photon and front-end shutters are absent from the BLISS Beacon config, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [ESRF Site](../esrf/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+ID32 adds the hazard classes that come with its endstations: a 9 Tesla superconducting magnet and its liquid-helium cryogen plant at the XMCD endstation, and an intense polarized soft X-ray beam. Those land with the instruments that bring them, and an experiment Clearance would carry them; the magnet and its cryogens are modelled as hazards on the experiment, not as Assets CORA drives for safety (the LASER-1 / sample-environment precedent).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives ID32, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ID32 content lives, the graduations it earns, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ID32 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the polarization PseudoAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes ID32 new
+
+ID32 is two things the fleet has not had: a new Site and a new controls house-style. It is CORA's **seventh Site** (the ESRF, Grenoble), the biggest re-test of the Site and Federation kernel a single deployment can be, and the **first BLISS / Beacon / Tango / IcePAP** control plane CORA models (the rest are EPICS, or Tango / Sardana at MAX IV). Its science is soft X-ray resonant inelastic scattering (RIXS) with a ~5 m dispersive spectrometer arm, and X-ray magnetic dichroism (XMCD) plus X-ray emission spectroscopy (XES) at a 9 Tesla high-field-magnet endstation, all fed by twin APPLE-II undulators through a soft X-ray plane-grating monochromator.
+
+ID32 coins no new Family. The twin APPLE-II undulators bind the catalog `InsertionDevice`, and the polarization is a `PseudoAxis` over the undulator phase, exactly as i06 and i10 modelled their APPLE-II sources; the PGM binds `GratingMonochromator`; the 4-circle diffractometer binds `Goniometer` with a reciprocal-space `PseudoAxis` (the Assembly named, not built, DIFF-1 / DIFF-2); the Andor CCDs bind `Camera`; the LakeShore VTI and coil-diagnostic controllers bind `TemperatureController`; the XMCD sample stage binds `LinearStage`; the machine state binds the loose `StorageRing`.
+
+### Loose families brought to a rule-of-three (all since graduated)
+
+ID32 pushed three loose families to a genuine rule-of-three. Per the owner decision (2026-06-27) each graduation is a dedicated, gated catalog PR rather than bundled into this scaffold; all three have since **graduated**.
+
+| Loose family | Sightings with ID32 | ID32 binding | Status |
+| --- | --- | --- | --- |
+| `SpectrometerArm` | SIX + ID32 RIXS arm + ID32 XES arm + ID28 | the two dispersive spectrometer arms (the same `SpectrometerArmsController` class instantiated twice) | **graduated**: earned across SIX + ID32 RIXS/XES + ID28; presents the `Positioner` Role |
+| `Magnet` | 4-ID + i10-1 + ID32 | the 9 T / 4 T XMCD split-coil magnet | **graduated**: earned across 4-ID + i10-1 + ID32; presents the `Regulator` Role, the field a settable process variable (`MAG-1` now covers only the per-Asset field detail) |
+| `PolarizationAnalyzer` | 4-ID + i10 + ID32 + P09 | the RIXS scattered-beam polarimeter | **graduated** (`POL-2`): catalog Family across 4-ID / i10 / ID32 / P09, presents Positioner |
+
+Keeping each graduation as its own PR keeps the scaffold clean and lets each get its own naming-r3 and gate-review. `SpectrometerArm` was the clearest: it presents the `Positioner` Role (an arm that positions a grating and carries a `Camera` at its focus), which is exactly why it never fit the point-Sensor families (`FluxMonitor` / `EnergyDispersiveSpectrometer`) and was coined loose at SIX.
+
+### The BLISS / Tango control plane
+
+ID32 is the first non-EPICS, non-Sardana controls house-style in the fleet: BLISS / Beacon (a YAML device database) over Tango and IcePAP. CORA models the control handles as opaque edge strings regardless of transport, the way the MX3 heterogeneous-control precedent does: a Tango device URL (`id32/limaccds/andor_1`), an IcePAP host+address (`iceid324`), or a BLISS axis name is the handle, carried confirm (`CTRL-1`). The RIXS / XMCD / XES acquisition runs through BLISS sequences; that orchestration is the seam CORA's edge replaces, conducting over Tango / IcePAP rather than replacing BLISS.
+
+### Deliberately not here yet
+
+- **The graduations (`RIXS-1`, `MAG-1`, `POL-2`).** All three families ID32 brought to a rule-of-three, `SpectrometerArm`, `Magnet`, and `PolarizationAnalyzer`, have since graduated into the catalog via their dedicated gated PRs.
+- **The exact optics handles (`MONO-1`, `OPT-1`, `OPT-2`, `DIFF-1`, `SAMPLE-1`).** The PGM, mirrors, slits, diffractometer axes, and XMCD sample stage are carried confirm-pending; the decision-critical devices (the arms, the magnet, the LakeShores, the CCDs, the undulator) carry their real BLISS addresses.
+- **The Assembly(Diffractometer) and the reciprocal-space rule (`DIFF-1`, `DIFF-2`).** Named, not built, as the other diffractometer beamlines deferred theirs.
+- **The RIXS / XMCD / XES Methods.** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the SIX RIXS, the 4-ID / i06 / i10 XMCD, and the xas_spectroscopy XES slugs (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_id32_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the ID32 team to confirm before the model can be trusted.*
+
+ID32 was reverse-engineered from the ESRF's open BLISS Beacon device database ([gitlab.esrf.fr/id32/beamline_configuration](https://gitlab.esrf.fr/id32/beamline_configuration), a git mirror of the live Beacon config), so the control handles on the [device pages](index.md) are the beamline's real Tango / IcePAP / BLISS addresses, read from the config rather than confirmed by staff. This is CORA's first ESRF Site and first BLISS / Tango / IcePAP controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics zone feeding the RIXS and XMCD endstations, or a different layout? | A shared `id32-optics` zone and the `id32-rixs` and `id32-xmcd` experiment hutches. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The APPLE-II undulator period and segment count. | An APPLE-II undulator source on the `id/master/id32` device server; period pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The ESRF-EBS storage-ring state ID32 reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
+| POL-1 | Blocks-go-live | The polarization value domain (linear / circular) and the phase conversion: pin it as a Calibration or run it rule-less on the live controller? | A `PseudoAxis` over the APPLE-II phase; rule-less by default (the i06 / i10 precedent). | The polarization-axis modelling. |
+| MONO-1 | Blocks-go-live | The PGM grating line densities, the cff, the incident-energy range, and the exact handles. | A soft X-ray PGM bound to `GratingMonochromator`; energy a `PseudoAxis`. | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The focusing-mirror coatings and the exact handles. | Soft X-ray focusing mirrors bound to `Mirror`. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
+
+### RIXS endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The 4-circle diffractometer (BLISS `DiffE4CH`, E4CH) circle roles and axes. | A `Goniometer`; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| DIFF-2 | Nice-to-have | The reciprocal-space (hkl) coordination over the diffractometer. | A reciprocal-space `PseudoAxis`, the rule deferred. | The reciprocal-space Asset. |
+| RIXS-1 | Blocks-go-live | The RIXS and XES dispersive spectrometer arms (the `SpectrometerArmsController` geometry, the Rowland radii, the grating modes). | Both bind the catalog `SpectrometerArm` Family (graduated across SIX + ID32 RIXS/XES + ID28); the per-Asset arm geometry stays pending. | The spectrometer-arm geometry; the family graduation is settled (see [Model](#loose-families-brought-to-a-rule-of-three-all-since-graduated)). |
+| POL-2 | Nice-to-have | The RIXS scattered-beam polarimeter (the `thpol` / `chipol` / `tthpol` block). | Binds the catalog `PolarizationAnalyzer`, graduated across 4-ID / i10 / ID32 / P09. | The polarimeter modelling. |
+| DET-1 | Blocks-go-live | The Andor CCD configurations (RIXS `andor_1`, XES `andor_2`). | Both bind `Camera`. | The detector modelling. |
+
+### XMCD endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MAG-1 | Blocks-go-live | The 9 T / 4 T XMCD split-coil magnet (field range, ramp, the two coils) and its cryogen plant. | Binds the catalog `Magnet` Family (graduated across 4-ID + i10-1 + ID32); the field is a settable axis (Regulator), the per-Asset field detail pending. | The per-Asset magnet field / control detail; the family graduation is settled (see [Model](#loose-families-brought-to-a-rule-of-three-all-since-graduated)). |
+| TEMP-1 | Nice-to-have | The LakeShore 336 (VTI sample) and 340 (coil / shield diagnostics) sensor and loop maps, and the He needle valve. | Two `TemperatureController` Assets presenting the `Regulator` Role; the needle valve folds into the VTI. | The temperature-control modelling. |
+| SAMPLE-1 | Blocks-go-live | The XMCD sample-positioning stage axes inside the magnet bore. | A `LinearStage`; axis set pending. | The sample-stage modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the Tango / IcePAP / BLISS handles read from the public Beacon config current and correct? | The handles in the descriptor are taken from the BLISS config and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The ESRF personnel-safety permit signals and the photon / front-end shutters (absent from the BLISS config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the liquid-helium supply for the magnet. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
+| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do RIXS, XMCD, and XES enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the SIX RIXS, the 4-ID / i06 / i10 XMCD, and the xas_spectroscopy XES slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/id32/questions.md b/docs/deployments/id32/questions.md
deleted file mode 100644
index a2a6ffa1183..00000000000
--- a/docs/deployments/id32/questions.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Open questions
-
-*What CORA needs the ID32 team to confirm before the model can be trusted.*
-
-ID32 was reverse-engineered from the ESRF's open BLISS Beacon device database ([gitlab.esrf.fr/id32/beamline_configuration](https://gitlab.esrf.fr/id32/beamline_configuration), a git mirror of the live Beacon config), so the control handles on the [device pages](index.md) are the beamline's real Tango / IcePAP / BLISS addresses, read from the config rather than confirmed by staff. This is CORA's first ESRF Site and first BLISS / Tango / IcePAP controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics zone feeding the RIXS and XMCD endstations, or a different layout? | A shared `id32-optics` zone and the `id32-rixs` and `id32-xmcd` experiment hutches. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The APPLE-II undulator period and segment count. | An APPLE-II undulator source on the `id/master/id32` device server; period pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The ESRF-EBS storage-ring state ID32 reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
-| POL-1 | Blocks-go-live | The polarization value domain (linear / circular) and the phase conversion: pin it as a Calibration or run it rule-less on the live controller? | A `PseudoAxis` over the APPLE-II phase; rule-less by default (the i06 / i10 precedent). | The polarization-axis modelling. |
-| MONO-1 | Blocks-go-live | The PGM grating line densities, the cff, the incident-energy range, and the exact handles. | A soft X-ray PGM bound to `GratingMonochromator`; energy a `PseudoAxis`. | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The focusing-mirror coatings and the exact handles. | Soft X-ray focusing mirrors bound to `Mirror`. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
-
-## RIXS endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The 4-circle diffractometer (BLISS `DiffE4CH`, E4CH) circle roles and axes. | A `Goniometer`; the `Assembly(Diffractometer)` is named, not built. | The diffractometer geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| DIFF-2 | Nice-to-have | The reciprocal-space (hkl) coordination over the diffractometer. | A reciprocal-space `PseudoAxis`, the rule deferred. | The reciprocal-space Asset. |
-| RIXS-1 | Blocks-go-live | The RIXS and XES dispersive spectrometer arms (the `SpectrometerArmsController` geometry, the Rowland radii, the grating modes). | Both bind the catalog `SpectrometerArm` Family (graduated across SIX + ID32 RIXS/XES + ID28); the per-Asset arm geometry stays pending. | The spectrometer-arm geometry; the family graduation is settled (see [Model](model.md#loose-families-brought-to-a-rule-of-three-all-since-graduated)). |
-| POL-2 | Nice-to-have | The RIXS scattered-beam polarimeter (the `thpol` / `chipol` / `tthpol` block). | Binds the catalog `PolarizationAnalyzer`, graduated across 4-ID / i10 / ID32 / P09. | The polarimeter modelling. |
-| DET-1 | Blocks-go-live | The Andor CCD configurations (RIXS `andor_1`, XES `andor_2`). | Both bind `Camera`. | The detector modelling. |
-
-## XMCD endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MAG-1 | Blocks-go-live | The 9 T / 4 T XMCD split-coil magnet (field range, ramp, the two coils) and its cryogen plant. | Binds the catalog `Magnet` Family (graduated across 4-ID + i10-1 + ID32); the field is a settable axis (Regulator), the per-Asset field detail pending. | The per-Asset magnet field / control detail; the family graduation is settled (see [Model](model.md#loose-families-brought-to-a-rule-of-three-all-since-graduated)). |
-| TEMP-1 | Nice-to-have | The LakeShore 336 (VTI sample) and 340 (coil / shield diagnostics) sensor and loop maps, and the He needle valve. | Two `TemperatureController` Assets presenting the `Regulator` Role; the needle valve folds into the VTI. | The temperature-control modelling. |
-| SAMPLE-1 | Blocks-go-live | The XMCD sample-positioning stage axes inside the magnet bore. | A `LinearStage`; axis set pending. | The sample-stage modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the Tango / IcePAP / BLISS handles read from the public Beacon config current and correct? | The handles in the descriptor are taken from the BLISS config and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The ESRF personnel-safety permit signals and the photon / front-end shutters (absent from the BLISS config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the liquid-helium supply for the magnet. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
-| GOV-1 | Nice-to-have | The ESRF operator pool and safety-review structure (site-level). | Carried pending on the ESRF Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do RIXS, XMCD, and XES enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the SIX RIXS, the 4-ID / i06 / i10 XMCD, and the xas_spectroscopy XES slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/id32/techniques.md b/docs/deployments/id32/techniques.md
deleted file mode 100644
index c67b5010fc4..00000000000
--- a/docs/deployments/id32/techniques.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Techniques
-
-*What the modelled part of ID32 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../esrf/index.md#the-techniques-adapted-here) is how a facility adapts it. ID32 runs three soft X-ray techniques, all new to CORA's catalog, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## Resonant inelastic X-ray scattering, magnetic dichroism, emission
-
-ID32 sets the X-ray energy and polarization with the twin APPLE-II undulators and the plane-grating monochromator, then either disperses the inelastically scattered beam on a long spectrometer arm (RIXS), or measures the absorption asymmetry between polarizations in a high magnetic field (XMCD), or disperses the emitted beam (XES).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | the roughly 5 m dispersive [spectrometer arm](detector.md) on the RIXS endstation, scanned in energy against the [incident-energy axis](source.md); reuses the SIX RIXS Method, the second consumer; Method not yet in the catalog |
-| X-ray magnetic dichroism | `xmcd` | absorption asymmetry in the 9 T [XMCD magnet](sample.md) between circular / linear polarizations set on the [APPLE-II](source.md); reuses the 4-ID / i06 / i10 dichroism Method; pending |
-| X-ray emission spectroscopy | `xas_spectroscopy` | the [XES Rowland arm](detector.md) at the XMCD endstation; reuses the `xas_spectroscopy` Method that ISS / LCLS-MFX left pending for XES; pending |
-
-RIXS needs the [incident-energy and polarization axes](source.md), the [RIXS diffractometer](sample.md) to set the scattering geometry, and the [dispersive spectrometer arm and its CCD](detector.md). XMCD needs the polarization axis, the [9 T magnet and its VTI](sample.md), and a detection channel. XES needs the [emission spectrometer arm](detector.md).
-
-## A new operating axis for the fleet, on familiar vocabulary
-
-RIXS at ID32 is the fleet's second soft X-ray RIXS after SIX, and the dispersive spectrometer arm is the device that ties them together: the same `SpectrometerArmsController` anatomy that SIX coined loose, sighted three times across two sites (the ID32 RIXS arm, the ID32 XES arm, and SIX). That rule-of-three earned the graduation of the `SpectrometerArm` Family, which has since landed as a catalog Family (SIX + ID32 RIXS/XES + ID28; see [Model](model.md#loose-families-brought-to-a-rule-of-three-all-since-graduated)). XMCD and XES likewise reuse the dichroism and emission Methods the fleet already carries pending; none forces a new device family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the RIXS energy maps and arm alignment, the XMCD field-and-polarization sequences, the XES scans, and the counting times) are not written yet; they join as the deployment approaches the point where CORA drives ID32. Whether RIXS, XMCD, and XES enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/ios/governance.md b/docs/deployments/ios/governance.md
deleted file mode 100644
index ea6ce439c3b..00000000000
--- a/docs/deployments/ios/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who will act at IOS, and the trust shape that will gate it. First cut.*
-
-Governance at IOS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-IOS is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. The PSS search-and-secure permit signals and the photon shutters are absent from the profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and not invented here (`PSS-1`).
-
-IOS carries the hazard classes that come with its instruments, which an experiment Clearance would carry; those land with the instruments that bring them:
-
-- the soft X-ray beam in the optics and endstation enclosures;
-- the ultra-high vacuum of the PGM, the KB system, and the analyzer endstation;
-- and, distinctively, the **ambient-pressure / operando sample environment**: a working gas atmosphere, the gas dosing and handling, and the sample heating that the reaction cell brings. That hardware is not in the profile collection, so its hazards (gas handling, pressure, temperature) are carried pending with the cell itself, not invented (`INSITU-1`).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives IOS, following the [2-BM governance](../2-bm/governance.md) shape. It re-tests the Site and Federation kernel rather than introducing a new trust model.
diff --git a/docs/deployments/ios/model.md b/docs/deployments/ios/model.md
deleted file mode 100644
index bcf6cccc485..00000000000
--- a/docs/deployments/ios/model.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's IOS content lives, how the ambient-pressure environment is carried as a deferral, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at IOS |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes IOS new
-
-The honest answer is: little on the hardware, one real thing on the science. IOS measures surface and interface chemistry under working conditions by ambient-pressure X-ray photoemission (AP-XPS / AP-PES) and soft NEXAFS / XAS. Every device it carries is a fleet shape ported once more:
-
-- the SPECS hemispherical analyzer binds the catalog `ElectronAnalyzer`, the third sighting after ESM and SST;
-- the VLS-PGM binds `GratingMonochromator`, a further consumer after SIX / CSX / ESM / SST;
-- the Vortex and Xspress3 silicon-drift detectors bind `EnergyDispersiveSpectrometer`;
-- the AP-PES four-axis stage binds `Manipulator`;
-- the two canted EPUs are the same `SR:C23-ID` twin-EPU straight CSX reads, with IOS on the 23-ID-2 branch.
-
-IOS's one genuinely distinct contribution is **in-situ / operando ambient-pressure spectroscopy**: measuring chemistry under a working gas atmosphere rather than in vacuum. That is the heart of the beamline, but the hardware that makes it (the reaction cell, the gas dosing and mixing manifold, the pressure control, the sample heating) is not in the profile collection, so CORA carries it as the headline open question (`INSITU-1`) and does not invent it. IOS also re-tests the NSLS-II Site and Federation kernel once more; the value there is confidence that the kernel holds, not a new abstraction.
-
-## No new families
-
-IOS coins no new Family and changes nothing in the catalog.
-
-- **The SPECS analyzer binds `ElectronAnalyzer`** (a photon-in / electron-out hemispherical analyzer, the ESM / SST precedent), the third sighting and the first non-Scienta and first ambient-pressure one; the analyzer make, the lens-mode set, and the pass-energy range are a per-Asset settings or bound-Model difference, not a Family split (`DET-1`).
-- **The VLS-PGM binds `GratingMonochromator`** (the soft X-ray plane-grating optic, the SIX / CSX precedent); the energy is its master axis with the EPU edge-table switching coupled in (`MONO-1`).
-- **The fluorescence detectors all reuse:** the Vortex (silicon-drift detector + MCA) and the Xspress3 (four-channel silicon-drift) bind `EnergyDispersiveSpectrometer`; the AP-PES stage binds `Manipulator`; the XAS-endstation translation binds `LinearStage`; the front-end and branch mirrors and the KB pair bind `Mirror`; the branch slits bind `Slit`; the front-end and branch shutters bind `Shutter`; the scaler and the Au-mesh I0 reference bind `FluxMonitor`; the surface-prep ion gun binds `GenericProbe`; the exit-slit diagnostic camera binds `Camera`; the two EPUs bind `InsertionDevice`.
-
-## How the ambient-pressure environment is carried (no device)
-
-The ambient-pressure / operando sample environment is what makes IOS IOS, and it is carried as a deferral, not a device:
-
-- the sample positioning that **is** in the profile (the APPES four-axis manipulator) is modelled as `Manipulator`;
-- the gas dosing and mixing, the pressure control, and the sample heating that the reaction cell needs are **not** in the profile collection (no gas, pressure, or temperature PVs), so they are carried as the headline open question (`INSITU-1`), not modelled.
-
-This is the same discipline the fleet's other in-situ accessories follow (SMI defers its humidity cell and blade coater, SST defers its ADR cryostat and syringe pump, ISS defers its broader sample environment): the device Roles that exist are modelled, and the sample-environment hardware that is not in the public source is deferred to an open question rather than invented. Whether a `ReactionCell` or near-ambient-pressure-cell Family is ever earned is a future owner decision, pending a second ambient-pressure deployment and the real PVs (`INSITU-1`).
-
-## Why no Practice is recorded
-
-IOS records **no Practice** at the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here), following [SST](../sst/techniques.md), the closest sibling (the soft / tender NSLS-II photoemission-and-absorption beamline that also recorded none):
-
-- IOS's ambient-pressure photoemission is photoemission, but the only photoemission Method slug the catalog anticipates is `angle_resolved_photoemission`, coined for ESM's ARPES; AP-XPS is chemical-state, not angle-resolved, so reusing that slug would name a shape it was not coined for;
-- IOS's soft NEXAFS / XAS is absorption by electron and fluorescence yield over an energy sweep, which leans on the deferred `energy_scan` Capability (the BMM question, `ENERGY-1`) and is a different shape from the crystal-emission-spectrometer `xas_spectroscopy` that MFX and ISS left pending.
-
-So no Practice is bound until a Method lands; IOS is bound to the Site through the beamline list, and each binding lands when its Capability does (`TECH-1`, `ENERGY-1`).
-
-## Deliberately not here yet
-
-- **The ambient-pressure reaction cell (`INSITU-1`).** The gas dosing / mixing manifold, the pressure control, and the sample heating are absent from the profile collection (no gas / pressure / temperature PVs) and are not invented; the sample positioning that is in the profile is modelled as `Manipulator`. A second ambient-pressure deployment and the real PVs would earn the abstraction.
-- **The sample transfer / load-lock.** A load-lock gate valve (`IOXAS-GV:4`) is in the profile but no sample-transfer motor PVs are, so the transfer mechanism is deferred (`SAMPLE-1`).
-- **The gate valves and the storage-ring readback.** The vacuum gate valves (`XF:23ID2-VA`) and the storage-ring current (`XF:23ID-SR`) are vacuum plumbing and facility observation, carried as notes, not Assets.
-- **The photoemission and NEXAFS Methods.** Whether ambient-pressure photoemission and soft NEXAFS enter CORA's catalog as Capabilities / Methods is an owner decision; the techniques render unlinked, and no Practice is recorded (`TECH-1`, `ENERGY-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_ios_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/ios/notes.md b/docs/deployments/ios/notes.md
new file mode 100644
index 00000000000..d1b23067135
--- /dev/null
+++ b/docs/deployments/ios/notes.md
@@ -0,0 +1,167 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at IOS: ambient-pressure photoemission and soft X-ray absorption, each a [Catalog](../../catalog/methods.md) Method. IOS follows the deferral discipline of the soft X-ray beamlines that brought each technique family to CORA. First cut.*
+
+IOS's techniques are soft X-ray surface science under working conditions: ambient-pressure photoemission and soft NEXAFS / XAS. The Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings them into the catalog. Following [SST](../sst/notes.md#techniques), IOS records **no Practice** at the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here) yet, because each technique sits on a pending or deferred Method; each binding lands when its Capability does.
+
+| Technique | Mode | Notes |
+| --- | --- | --- |
+| Ambient-pressure photoemission (AP-XPS / AP-PES) | fixed energy, gas atmosphere | photoelectron spectra on the SPECS hemispherical analyzer under a working gas pressure; the ESM / SST photoemission family, new Capability pending (`TECH-1`) |
+| Soft NEXAFS / XAS | energy sweep | absorption by total / partial electron yield (drain current through the scaler) and partial fluorescence yield (the Vortex / Xspress3), over a PGM energy scan; the BMM energy-scan question (`ENERGY-1`, `TECH-1`) |
+
+Both need the [grating monochromator](source.md) (the incident energy), the [AP-PES manipulator](sample.md) (the sample in the analyzer focus), and the [analyzer and yield chain](detector.md). The detection mode (TEY drain current, PEY kinetic-energy-selected electrons through the analyzer, PFY region-of-interest fluorescence) is a setting, not a separate technique.
+
+### Why the Capabilities stay deferred
+
+Each of IOS's techniques sits on a Capability the catalog does not yet carry, and the discipline is the same one the originating beamlines applied:
+
+- **Ambient-pressure photoemission** follows NSLS-II [ESM](../esm/index.md). The only photoemission Method slug the catalog anticipates is `angle_resolved_photoemission`, coined for ESM's ARPES; IOS's AP-XPS is chemical-state photoemission under a gas atmosphere, not angle-resolved, so reusing that slug would name a shape it was not coined for. The device Role already exists (the analyzer presents Detector); what is new is the science Capability, and the ambient-pressure context on top of it.
+- **Soft NEXAFS / XAS** follows [BMM](../bmm/index.md): the measurement is the energy sweep itself, the deferred `energy_scan` Capability (`ENERGY-1`). It is a different shape from the crystal-emission-spectrometer `xas_spectroscopy` that LCLS-MFX and ISS left pending (which disperses emitted photons through an analyzer crystal); IOS's NEXAFS reads absorption by electron and fluorescence yield.
+
+So IOS reinforces both technique families at one more instrument without coining either, and records no Practice; each binding lands when its Capability does (`TECH-1`, `ENERGY-1`).
+
+### The ambient-pressure context
+
+What distinguishes IOS from the fleet's other photoemission and absorption beamlines is that it runs under a working gas atmosphere (in situ / operando), not in vacuum. That context is the heart of the science, but the hardware that delivers it (the reaction cell, the gas dosing and mixing, the pressure control, the sample heating) is not in the profile collection and is carried as the headline open question (`INSITU-1`), not modelled. When a Method for ambient-pressure spectroscopy is eventually authored, the ambient-pressure context would be a Practice-level adaptation (the gas, pressure, and temperature settings) on the photoemission and absorption Methods, not a separate technique.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the energy scans with their coupled EPU edge-table switching, the spectrum acquisitions, the yield reads) are not written yet; they join as the deployment approaches the point where CORA drives IOS. The per-technique reduction (photoemission spectra, NEXAFS spectra) is `ComputePort` work, not beamline Methods. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at IOS, and the trust shape that will gate it. First cut.*
+
+Governance at IOS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+IOS is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. The PSS search-and-secure permit signals and the photon shutters are absent from the profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and not invented here (`PSS-1`).
+
+IOS carries the hazard classes that come with its instruments, which an experiment Clearance would carry; those land with the instruments that bring them:
+
+- the soft X-ray beam in the optics and endstation enclosures;
+- the ultra-high vacuum of the PGM, the KB system, and the analyzer endstation;
+- and, distinctively, the **ambient-pressure / operando sample environment**: a working gas atmosphere, the gas dosing and handling, and the sample heating that the reaction cell brings. That hardware is not in the profile collection, so its hazards (gas handling, pressure, temperature) are carried pending with the cell itself, not invented (`INSITU-1`).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives IOS, following the [2-BM governance](../2-bm/governance.md) shape. It re-tests the Site and Federation kernel rather than introducing a new trust model.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's IOS content lives, how the ambient-pressure environment is carried as a deferral, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at IOS |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes IOS new
+
+The honest answer is: little on the hardware, one real thing on the science. IOS measures surface and interface chemistry under working conditions by ambient-pressure X-ray photoemission (AP-XPS / AP-PES) and soft NEXAFS / XAS. Every device it carries is a fleet shape ported once more:
+
+- the SPECS hemispherical analyzer binds the catalog `ElectronAnalyzer`, the third sighting after ESM and SST;
+- the VLS-PGM binds `GratingMonochromator`, a further consumer after SIX / CSX / ESM / SST;
+- the Vortex and Xspress3 silicon-drift detectors bind `EnergyDispersiveSpectrometer`;
+- the AP-PES four-axis stage binds `Manipulator`;
+- the two canted EPUs are the same `SR:C23-ID` twin-EPU straight CSX reads, with IOS on the 23-ID-2 branch.
+
+IOS's one genuinely distinct contribution is **in-situ / operando ambient-pressure spectroscopy**: measuring chemistry under a working gas atmosphere rather than in vacuum. That is the heart of the beamline, but the hardware that makes it (the reaction cell, the gas dosing and mixing manifold, the pressure control, the sample heating) is not in the profile collection, so CORA carries it as the headline open question (`INSITU-1`) and does not invent it. IOS also re-tests the NSLS-II Site and Federation kernel once more; the value there is confidence that the kernel holds, not a new abstraction.
+
+### No new families
+
+IOS coins no new Family and changes nothing in the catalog.
+
+- **The SPECS analyzer binds `ElectronAnalyzer`** (a photon-in / electron-out hemispherical analyzer, the ESM / SST precedent), the third sighting and the first non-Scienta and first ambient-pressure one; the analyzer make, the lens-mode set, and the pass-energy range are a per-Asset settings or bound-Model difference, not a Family split (`DET-1`).
+- **The VLS-PGM binds `GratingMonochromator`** (the soft X-ray plane-grating optic, the SIX / CSX precedent); the energy is its master axis with the EPU edge-table switching coupled in (`MONO-1`).
+- **The fluorescence detectors all reuse:** the Vortex (silicon-drift detector + MCA) and the Xspress3 (four-channel silicon-drift) bind `EnergyDispersiveSpectrometer`; the AP-PES stage binds `Manipulator`; the XAS-endstation translation binds `LinearStage`; the front-end and branch mirrors and the KB pair bind `Mirror`; the branch slits bind `Slit`; the front-end and branch shutters bind `Shutter`; the scaler and the Au-mesh I0 reference bind `FluxMonitor`; the surface-prep ion gun binds `GenericProbe`; the exit-slit diagnostic camera binds `Camera`; the two EPUs bind `InsertionDevice`.
+
+### How the ambient-pressure environment is carried (no device)
+
+The ambient-pressure / operando sample environment is what makes IOS IOS, and it is carried as a deferral, not a device:
+
+- the sample positioning that **is** in the profile (the APPES four-axis manipulator) is modelled as `Manipulator`;
+- the gas dosing and mixing, the pressure control, and the sample heating that the reaction cell needs are **not** in the profile collection (no gas, pressure, or temperature PVs), so they are carried as the headline open question (`INSITU-1`), not modelled.
+
+This is the same discipline the fleet's other in-situ accessories follow (SMI defers its humidity cell and blade coater, SST defers its ADR cryostat and syringe pump, ISS defers its broader sample environment): the device Roles that exist are modelled, and the sample-environment hardware that is not in the public source is deferred to an open question rather than invented. Whether a `ReactionCell` or near-ambient-pressure-cell Family is ever earned is a future owner decision, pending a second ambient-pressure deployment and the real PVs (`INSITU-1`).
+
+### Why no Practice is recorded
+
+IOS records **no Practice** at the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here), following [SST](../sst/notes.md#techniques), the closest sibling (the soft / tender NSLS-II photoemission-and-absorption beamline that also recorded none):
+
+- IOS's ambient-pressure photoemission is photoemission, but the only photoemission Method slug the catalog anticipates is `angle_resolved_photoemission`, coined for ESM's ARPES; AP-XPS is chemical-state, not angle-resolved, so reusing that slug would name a shape it was not coined for;
+- IOS's soft NEXAFS / XAS is absorption by electron and fluorescence yield over an energy sweep, which leans on the deferred `energy_scan` Capability (the BMM question, `ENERGY-1`) and is a different shape from the crystal-emission-spectrometer `xas_spectroscopy` that MFX and ISS left pending.
+
+So no Practice is bound until a Method lands; IOS is bound to the Site through the beamline list, and each binding lands when its Capability does (`TECH-1`, `ENERGY-1`).
+
+### Deliberately not here yet
+
+- **The ambient-pressure reaction cell (`INSITU-1`).** The gas dosing / mixing manifold, the pressure control, and the sample heating are absent from the profile collection (no gas / pressure / temperature PVs) and are not invented; the sample positioning that is in the profile is modelled as `Manipulator`. A second ambient-pressure deployment and the real PVs would earn the abstraction.
+- **The sample transfer / load-lock.** A load-lock gate valve (`IOXAS-GV:4`) is in the profile but no sample-transfer motor PVs are, so the transfer mechanism is deferred (`SAMPLE-1`).
+- **The gate valves and the storage-ring readback.** The vacuum gate valves (`XF:23ID2-VA`) and the storage-ring current (`XF:23ID-SR`) are vacuum plumbing and facility observation, carried as notes, not Assets.
+- **The photoemission and NEXAFS Methods.** Whether ambient-pressure photoemission and soft NEXAFS enter CORA's catalog as Capabilities / Methods is an owner decision; the techniques render unlinked, and no Practice is recorded (`TECH-1`, `ENERGY-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_ios_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the IOS team to confirm before the model can be trusted.*
+
+IOS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/ios-profile-collection](https://github.com/NSLS2/ios-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | The 23-ID canted straight: do the two EPUs feed both CSX (23-ID-1) and IOS (23-ID-2), and is IOS one root Unit? | One root Unit `IOS` fed by the canted twin-EPU straight (the 32-ID / CSX precedent). | The source topology in the [descriptor](index.md). |
+| ENC-1 | Blocks-go-live | Are the PV zones `XF:23IDA` / `XF:23ID2-OP` / `XF:23ID2-ES` separate shielded hutches or beam zones within fewer? | Two enclosures (front-end optics + the 23-ID-2 branch). | The Enclosure grouping. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the ios-profile-collection current and correct, and is a queue server in use? | The handles in the descriptor are taken from the profile collection and carried confirm; queue-server use unknown. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the front-end shutter is `XF:23ID-PPS{Sh:FE}` and the branch shutter `XF:23ID2-PPS{PSh}`. | The Enclosure permit signals. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The two EPUs (`EPU:1`, `EPU:2`): type, period, the polarization (phase) model, and the energy-edge lookup tables. | Two `InsertionDevice` Assets; the phase axis and the edge table carried as settings. | The insertion-device specs. |
+| MONO-1 | Blocks-go-live | The VLS-PGM: the grating line densities, the c-value model, and the 200-2200 eV range. | A `GratingMonochromator` Asset with energy / mirror-pitch / mirror-x / grating-pitch / grating-x axes and an energy fly-scan. | The monochromator model. |
+| OPT-1 | Nice-to-have | The mirrors (M1A front-end, M1B1 / M1B2 deflecting, M3B branch, DM1, the KB pair): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The branch slits (`Slt:1` gap-center, `Slt:2` vertical): the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
+
+### Sample and ambient-pressure environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-build | The APPES manipulator (x / y / z / rotation) and the IOXAS stage: the axis roles, and the sample-transfer / load-lock mechanism (the `IOXAS-GV:4` valve is present, no transfer-motor PVs are). | A `Manipulator` and a `LinearStage`; the transfer mechanism deferred. | The sample-positioning model. |
+| SAMPLE-2 | Nice-to-have | The SPECS surface-prep sputter / ion gun: control and role. | A `GenericProbe` auxiliary, not the analyzer. | The surface-prep model. |
+| INSITU-1 | Blocks-build | The ambient-pressure reaction cell, the gas dosing / mixing manifold, the pressure control, and the sample heating: there are no gas / pressure / temperature PVs in the profile collection. | The ambient-pressure sample environment is out of the profile collection and not modelled until the hardware and PVs are provided. | The operando sample environment, IOS's defining feature. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The SPECS hemispherical analyzer: model (Phoibos NAP?), pass-energy range, lens-mode set, and angular acceptance. | An `ElectronAnalyzer` Asset; analyzer make and ranges are settings. | The analyzer model. |
+| DET-2 | Blocks-go-live | The Vortex and Xspress3 silicon-drift detectors: models, channels, and the ROI map (and why one of four Xspress3 channels is active). | `EnergyDispersiveSpectrometer` Assets; ROI / channel maps partial. | The fluorescence-detector models. |
+| DET-3 | Nice-to-have | The scaler, the `CurrAmp:1/2/3` current amplifiers, and the Au mesh: the electron-yield (TEY / PEY) channel wiring and the I0 reference. | `FluxMonitor` Assets; the yield-chain wiring partial. | The yield-chain map. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENERGY-1 | Nice-to-have | Is the NEXAFS / XAS measurement a continuous PGM energy fly-scan (with coupled EPU edge-table switching) or a stepped scan? | The PGM energy fly-scan is available; the sweep-as-measurement is carried as intent. | The energy-scan mode. |
+
+### Supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SUP-1 | Nice-to-have | The vacuum and cooling supplies the UHV optics, the KB system, and the analyzer endstation draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/ios/questions.md b/docs/deployments/ios/questions.md
deleted file mode 100644
index 4be292b5d5e..00000000000
--- a/docs/deployments/ios/questions.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# Open questions
-
-*What CORA needs the IOS team to confirm before the model can be trusted.*
-
-IOS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/ios-profile-collection](https://github.com/NSLS2/ios-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | The 23-ID canted straight: do the two EPUs feed both CSX (23-ID-1) and IOS (23-ID-2), and is IOS one root Unit? | One root Unit `IOS` fed by the canted twin-EPU straight (the 32-ID / CSX precedent). | The source topology in the [descriptor](index.md). |
-| ENC-1 | Blocks-go-live | Are the PV zones `XF:23IDA` / `XF:23ID2-OP` / `XF:23ID2-ES` separate shielded hutches or beam zones within fewer? | Two enclosures (front-end optics + the 23-ID-2 branch). | The Enclosure grouping. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the ios-profile-collection current and correct, and is a queue server in use? | The handles in the descriptor are taken from the profile collection and carried confirm; queue-server use unknown. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the front-end shutter is `XF:23ID-PPS{Sh:FE}` and the branch shutter `XF:23ID2-PPS{PSh}`. | The Enclosure permit signals. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The two EPUs (`EPU:1`, `EPU:2`): type, period, the polarization (phase) model, and the energy-edge lookup tables. | Two `InsertionDevice` Assets; the phase axis and the edge table carried as settings. | The insertion-device specs. |
-| MONO-1 | Blocks-go-live | The VLS-PGM: the grating line densities, the c-value model, and the 200-2200 eV range. | A `GratingMonochromator` Asset with energy / mirror-pitch / mirror-x / grating-pitch / grating-x axes and an energy fly-scan. | The monochromator model. |
-| OPT-1 | Nice-to-have | The mirrors (M1A front-end, M1B1 / M1B2 deflecting, M3B branch, DM1, the KB pair): coatings and axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The branch slits (`Slt:1` gap-center, `Slt:2` vertical): the internal axis maps. | `Slit` Assets with base PVs; per-blade axes partial. | The slit axis maps. |
-
-## Sample and ambient-pressure environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-build | The APPES manipulator (x / y / z / rotation) and the IOXAS stage: the axis roles, and the sample-transfer / load-lock mechanism (the `IOXAS-GV:4` valve is present, no transfer-motor PVs are). | A `Manipulator` and a `LinearStage`; the transfer mechanism deferred. | The sample-positioning model. |
-| SAMPLE-2 | Nice-to-have | The SPECS surface-prep sputter / ion gun: control and role. | A `GenericProbe` auxiliary, not the analyzer. | The surface-prep model. |
-| INSITU-1 | Blocks-build | The ambient-pressure reaction cell, the gas dosing / mixing manifold, the pressure control, and the sample heating: there are no gas / pressure / temperature PVs in the profile collection. | The ambient-pressure sample environment is out of the profile collection and not modelled until the hardware and PVs are provided. | The operando sample environment, IOS's defining feature. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The SPECS hemispherical analyzer: model (Phoibos NAP?), pass-energy range, lens-mode set, and angular acceptance. | An `ElectronAnalyzer` Asset; analyzer make and ranges are settings. | The analyzer model. |
-| DET-2 | Blocks-go-live | The Vortex and Xspress3 silicon-drift detectors: models, channels, and the ROI map (and why one of four Xspress3 channels is active). | `EnergyDispersiveSpectrometer` Assets; ROI / channel maps partial. | The fluorescence-detector models. |
-| DET-3 | Nice-to-have | The scaler, the `CurrAmp:1/2/3` current amplifiers, and the Au mesh: the electron-yield (TEY / PEY) channel wiring and the I0 reference. | `FluxMonitor` Assets; the yield-chain wiring partial. | The yield-chain map. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENERGY-1 | Nice-to-have | Is the NEXAFS / XAS measurement a continuous PGM energy fly-scan (with coupled EPU edge-table switching) or a stepped scan? | The PGM energy fly-scan is available; the sweep-as-measurement is carried as intent. | The energy-scan mode. |
-
-## Supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SUP-1 | Nice-to-have | The vacuum and cooling supplies the UHV optics, the KB system, and the analyzer endstation draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/ios/techniques.md b/docs/deployments/ios/techniques.md
deleted file mode 100644
index ab31fc6501e..00000000000
--- a/docs/deployments/ios/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What CORA would run at IOS: ambient-pressure photoemission and soft X-ray absorption, each a [Catalog](../../catalog/methods.md) Method. IOS follows the deferral discipline of the soft X-ray beamlines that brought each technique family to CORA. First cut.*
-
-IOS's techniques are soft X-ray surface science under working conditions: ambient-pressure photoemission and soft NEXAFS / XAS. The Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings them into the catalog. Following [SST](../sst/techniques.md), IOS records **no Practice** at the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here) yet, because each technique sits on a pending or deferred Method; each binding lands when its Capability does.
-
-| Technique | Mode | Notes |
-| --- | --- | --- |
-| Ambient-pressure photoemission (AP-XPS / AP-PES) | fixed energy, gas atmosphere | photoelectron spectra on the SPECS hemispherical analyzer under a working gas pressure; the ESM / SST photoemission family, new Capability pending (`TECH-1`) |
-| Soft NEXAFS / XAS | energy sweep | absorption by total / partial electron yield (drain current through the scaler) and partial fluorescence yield (the Vortex / Xspress3), over a PGM energy scan; the BMM energy-scan question (`ENERGY-1`, `TECH-1`) |
-
-Both need the [grating monochromator](source.md) (the incident energy), the [AP-PES manipulator](sample.md) (the sample in the analyzer focus), and the [analyzer and yield chain](detector.md). The detection mode (TEY drain current, PEY kinetic-energy-selected electrons through the analyzer, PFY region-of-interest fluorescence) is a setting, not a separate technique.
-
-## Why the Capabilities stay deferred
-
-Each of IOS's techniques sits on a Capability the catalog does not yet carry, and the discipline is the same one the originating beamlines applied:
-
-- **Ambient-pressure photoemission** follows NSLS-II [ESM](../esm/index.md). The only photoemission Method slug the catalog anticipates is `angle_resolved_photoemission`, coined for ESM's ARPES; IOS's AP-XPS is chemical-state photoemission under a gas atmosphere, not angle-resolved, so reusing that slug would name a shape it was not coined for. The device Role already exists (the analyzer presents Detector); what is new is the science Capability, and the ambient-pressure context on top of it.
-- **Soft NEXAFS / XAS** follows [BMM](../bmm/index.md): the measurement is the energy sweep itself, the deferred `energy_scan` Capability (`ENERGY-1`). It is a different shape from the crystal-emission-spectrometer `xas_spectroscopy` that LCLS-MFX and ISS left pending (which disperses emitted photons through an analyzer crystal); IOS's NEXAFS reads absorption by electron and fluorescence yield.
-
-So IOS reinforces both technique families at one more instrument without coining either, and records no Practice; each binding lands when its Capability does (`TECH-1`, `ENERGY-1`).
-
-## The ambient-pressure context
-
-What distinguishes IOS from the fleet's other photoemission and absorption beamlines is that it runs under a working gas atmosphere (in situ / operando), not in vacuum. That context is the heart of the science, but the hardware that delivers it (the reaction cell, the gas dosing and mixing, the pressure control, the sample heating) is not in the profile collection and is carried as the headline open question (`INSITU-1`), not modelled. When a Method for ambient-pressure spectroscopy is eventually authored, the ambient-pressure context would be a Practice-level adaptation (the gas, pressure, and temperature settings) on the photoemission and absorption Methods, not a separate technique.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the energy scans with their coupled EPU edge-table switching, the spectrum acquisitions, the yield reads) are not written yet; they join as the deployment approaches the point where CORA drives IOS. The per-technique reduction (photoemission spectra, NEXAFS spectra) is `ComputePort` work, not beamline Methods. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/isr/governance.md b/docs/deployments/isr/governance.md
deleted file mode 100644
index 5850045de1e..00000000000
--- a/docs/deployments/isr/governance.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Governance
-
-*Who will act at ISR, and the trust shape that will gate it. A deliberately partial first cut.*
-
-Governance at ISR follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-ISR is not yet driven by CORA, so this shape is not yet instantiated. As a partial modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
-
-## The safety boundary
-
-The safety tier is the other piece that is not yet settled, and the source is especially thin here: **no PSS search-and-secure permit signal, photon shutter, or hutch-interlock device is in the profile collection** (the only two-button-shutter use is the filter-bank actuation, not a beam shutter). So the Enclosure permit leaves and the interlock structure are carried pending and not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-ISR adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
-
-| Hazard class | Where it lands | Tracking |
-| --- | --- | --- |
-| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:04ID) (`ENC-1`) | (`PSS-1`) |
-| Vacuum optics | the [Source](source.md) walk | (`SUP-1`) |
-| In-situ sample environments (when present) | the [Sample](sample.md) side | (`INSITU-1`) |
-
-The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The in-situ sample environments that ISR's name implies (electrochemistry, gas, temperature, cryostat) would each bring their own hazards, but none is in the source yet, so they are carried against the in-situ question, not invented (`INSITU-1`).
-
-## When the shape lands
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when ISR's profile collection firms up past its current optics-first state and the deployment approaches the point where CORA drives ISR, following the [2-BM governance](../2-bm/governance.md) shape. Because ISR shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
diff --git a/docs/deployments/isr/model.md b/docs/deployments/isr/model.md
deleted file mode 100644
index c1e108adb07..00000000000
--- a/docs/deployments/isr/model.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ISR content lives, why this deployment is deliberately partial, and the record of what is deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ISR |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Why ISR is partial
-
-ISR's name, In Situ and Resonant, promises a multi-circle diffractometer, a tunable resonant energy axis, in-situ sample environments, and often polarization analysis. The public profile collection does not yet contain them. It is an optics-and-detectors-first scaffold: the front-end slit, the undulator gap (read-only), the DCM, the focusing and harmonic-rejection mirrors, the attenuator bank, the Eiger 1M, the diagnostic screen cameras, and only two bound sample axes (`th`, `zeta`). The flux-monitor electrometers are commented out, the energy axis is a non-functional stub, and the databroker catalog has a placeholder name, all commissioning signals.
-
-CORA models what is PV-bound and routes the four mission-critical gaps to open questions rather than inventing them. This is the same discipline the [i20-1](../i20-1/model.md) (EDE) partial uses: where the source is thin, model the real handles and name the absences, never fabricate the headline device.
-
-## No new families
-
-ISR coins no new Family and changes nothing in the catalog.
-
-- **4-ID is an undulator beamline** (read-only gap in source); machine state is observed through the loose `StorageRing`, and the undulator detail is `SRC-1`.
-- **The optics reuse the catalog:** the DCM binds `Monochromator`; the bendable focusing pair and the harmonic-rejection mirror bind `Mirror`; the front-end slit binds `Slit`; the attenuator bank binds `Filter`.
-- **The one bound sample rotation binds `RotaryStage`, not `Goniometer`.** With only `th` + `zeta` bound and no detector arm or reciprocal-space engine, there is no basis for a multi-circle `Goniometer`; it is one `RotaryStage` Asset with the full diffractometer deferred (`DIFF-1`).
-- **The Eiger 1M and the screen cameras bind `Camera`; the motorized BPM stage binds the graduated catalog `PositionMonitor`** (presents `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; the per-Asset channel map stays open, `DIAG-1`). The flux-monitor electrometers are commented out, so no `FluxMonitor` Asset is modelled (`DET-1`).
-
-## No new Methods
-
-ISR's science reuses two pending Methods rather than coining: `resonant_scattering` (APS 4-ID, CSX) and `diffraction` (4-ID, 8-ID). Both are doubly deferred here because the diffractometer they run on is absent from source (`TECH-1`, `DIFF-1`). When ISR's diffractometer lands and the techniques are driven, ISR becomes a further consumer of each, strengthening the case for cataloging them, an owner decision, not an automatic one.
-
-## Deliberately not here yet
-
-- **The multi-circle diffractometer (`DIFF-1`).** Only `th` + `zeta` are bound under the `Dif:ISD` IOC; the orientation circles, the detector two-theta arm, and the reciprocal-space / hkl engine are absent from source and not invented. When they land, the sample side would be a `Goniometer` plus reciprocal-space `PseudoAxis` (the IXS six-circle / CSX TARDIS precedent), with a detector-arm `RotaryStage` / `LinearStage`.
-- **The in-situ sample environment (`INSITU-1`).** No temperature / electrochemistry / gas / cryostat device is PV-bound. When it lands it reuses `TemperatureController` / the graduated `FlowController` and the Subject / Supply / Procedure seam, not a new family.
-- **The resonant energy axis and polarization analysis (`RESONANT-1`).** The energy axis is a non-functional stub; no polarization analyzer or phase retarder is bound. When wired, the energy axis is a `PseudoAxis` over the DCM and polarization hardware reuses the catalog `PhaseRetarder` and `PolarizationAnalyzer` (4-ID).
-- **The flux monitors (`DET-1`).** The QuadEM electrometers and the secondary-source slit are defined but commented out in source; not modelled until live.
-- **The Methods.** Whether `resonant_scattering` and `diffraction` enter CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_isr_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive, and whose primary instrument is not even in source, would be invention; they land when the diffractometer is bound and the team confirms.
diff --git a/docs/deployments/isr/notes.md b/docs/deployments/isr/notes.md
new file mode 100644
index 00000000000..dfe89283ab3
--- /dev/null
+++ b/docs/deployments/isr/notes.md
@@ -0,0 +1,150 @@
+# Notes
+
+## Techniques
+
+*What ISR is designed to do, as intent. A deliberately partial first cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. ISR's mission is hard X-ray resonant scattering and surface / interface diffraction, with in-situ sample environments. The Methods below render unlinked and are **doubly deferred**: the Methods themselves are pending, and the multi-circle diffractometer they run on is absent from the source (`TECH-1`, `DIFF-1`).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant scattering | `resonant_scattering` | resonant elastic scattering near an absorption edge; reuses the Method APS [4-ID](../4-id/notes.md#techniques) (POLAR) and [CSX](../csx/notes.md#techniques) left pending; needs a tunable energy axis and a diffractometer, both absent from source (`TECH-1`, `RESONANT-1`, `DIFF-1`) |
+| Surface / interface diffraction | `diffraction` | crystal truncation rods and surface structure; reuses the `diffraction` Method 4-ID / [8-ID](../8-id/notes.md#techniques) left pending; needs the multi-circle diffractometer, absent from source (`TECH-1`, `DIFF-1`) |
+
+Both techniques would need the [incident-beam chain](source.md) (the undulator, the DCM for energy, the focusing mirrors, the attenuator), a multi-circle [sample diffractometer](sample.md), and the [Eiger area detector](detector.md). The first two of those are partly modelled; the diffractometer is not.
+
+### Reuse, not new vocabulary
+
+ISR coins **no new Method**. Its resonant scattering reuses the `resonant_scattering` Method that APS 4-ID brought and CSX shares; its surface / CTR diffraction reuses the `diffraction` Method that 4-ID / 8-ID share. So ISR adds, when it lands, further consumers of two pending Methods, strengthening the case for cataloging them, but it does not mint vocabulary. The matching Site Practices (`ISR_resonant_scattering_practice`, `ISR_surface_diffraction_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here).
+
+### Why these are doubly deferred
+
+For every other beamline the technique Methods are deferred because the Capability is not yet in the catalog (the owner-scope decision). At ISR there is a second, harder deferral: the **devices** the techniques run on are not in the public source. Resonant scattering needs a tunable energy axis (a non-functional stub here, `RESONANT-1`) and surface diffraction needs a multi-circle diffractometer (only two axes bound, `DIFF-1`). So these Practices are intent recorded against a partial scaffold, not a capability CORA could drive today. They firm up as the diffractometer and the energy axis enter the source.
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet, and cannot be until the diffractometer lands: the reciprocal-space (hkl) scans, the rocking-curve and CTR trajectories, the energy scans across an edge for resonant work, and the in-situ environment programs. The integration and reduction (azimuthal / CTR rod integration) are `ComputePort` work, not beamline Methods. These join as ISR's profile collection grows past its current optics-first state.
+
+See [Open questions](#open-questions) for the world-facts to confirm first, especially the diffractometer (`DIFF-1`) and the in-situ environment (`INSITU-1`).
+
+## Governance
+
+*Who will act at ISR, and the trust shape that will gate it. A deliberately partial first cut.*
+
+Governance at ISR follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+ISR is not yet driven by CORA, so this shape is not yet instantiated. As a partial modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
+
+### The safety boundary
+
+The safety tier is the other piece that is not yet settled, and the source is especially thin here: **no PSS search-and-secure permit signal, photon shutter, or hutch-interlock device is in the profile collection** (the only two-button-shutter use is the filter-bank actuation, not a beam shutter). So the Enclosure permit leaves and the interlock structure are carried pending and not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+ISR adds the hazard classes that come with its instruments. Those land with the equipment that brings them, and an experiment Clearance would carry them.
+
+| Hazard class | Where it lands | Tracking |
+| --- | --- | --- |
+| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:04ID) (`ENC-1`) | (`PSS-1`) |
+| Vacuum optics | the [Source](source.md) walk | (`SUP-1`) |
+| In-situ sample environments (when present) | the [Sample](sample.md) side | (`INSITU-1`) |
+
+The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The in-situ sample environments that ISR's name implies (electrochemistry, gas, temperature, cryostat) would each bring their own hazards, but none is in the source yet, so they are carried against the in-situ question, not invented (`INSITU-1`).
+
+### When the shape lands
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when ISR's profile collection firms up past its current optics-first state and the deployment approaches the point where CORA drives ISR, following the [2-BM governance](../2-bm/governance.md) shape. Because ISR shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ISR content lives, why this deployment is deliberately partial, and the record of what is deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ISR |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Why ISR is partial
+
+ISR's name, In Situ and Resonant, promises a multi-circle diffractometer, a tunable resonant energy axis, in-situ sample environments, and often polarization analysis. The public profile collection does not yet contain them. It is an optics-and-detectors-first scaffold: the front-end slit, the undulator gap (read-only), the DCM, the focusing and harmonic-rejection mirrors, the attenuator bank, the Eiger 1M, the diagnostic screen cameras, and only two bound sample axes (`th`, `zeta`). The flux-monitor electrometers are commented out, the energy axis is a non-functional stub, and the databroker catalog has a placeholder name, all commissioning signals.
+
+CORA models what is PV-bound and routes the four mission-critical gaps to open questions rather than inventing them. This is the same discipline the [i20-1](../i20-1/notes.md#model) (EDE) partial uses: where the source is thin, model the real handles and name the absences, never fabricate the headline device.
+
+### No new families
+
+ISR coins no new Family and changes nothing in the catalog.
+
+- **4-ID is an undulator beamline** (read-only gap in source); machine state is observed through the loose `StorageRing`, and the undulator detail is `SRC-1`.
+- **The optics reuse the catalog:** the DCM binds `Monochromator`; the bendable focusing pair and the harmonic-rejection mirror bind `Mirror`; the front-end slit binds `Slit`; the attenuator bank binds `Filter`.
+- **The one bound sample rotation binds `RotaryStage`, not `Goniometer`.** With only `th` + `zeta` bound and no detector arm or reciprocal-space engine, there is no basis for a multi-circle `Goniometer`; it is one `RotaryStage` Asset with the full diffractometer deferred (`DIFF-1`).
+- **The Eiger 1M and the screen cameras bind `Camera`; the motorized BPM stage binds the graduated catalog `PositionMonitor`** (presents `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; the per-Asset channel map stays open, `DIAG-1`). The flux-monitor electrometers are commented out, so no `FluxMonitor` Asset is modelled (`DET-1`).
+
+### No new Methods
+
+ISR's science reuses two pending Methods rather than coining: `resonant_scattering` (APS 4-ID, CSX) and `diffraction` (4-ID, 8-ID). Both are doubly deferred here because the diffractometer they run on is absent from source (`TECH-1`, `DIFF-1`). When ISR's diffractometer lands and the techniques are driven, ISR becomes a further consumer of each, strengthening the case for cataloging them, an owner decision, not an automatic one.
+
+### Deliberately not here yet
+
+- **The multi-circle diffractometer (`DIFF-1`).** Only `th` + `zeta` are bound under the `Dif:ISD` IOC; the orientation circles, the detector two-theta arm, and the reciprocal-space / hkl engine are absent from source and not invented. When they land, the sample side would be a `Goniometer` plus reciprocal-space `PseudoAxis` (the IXS six-circle / CSX TARDIS precedent), with a detector-arm `RotaryStage` / `LinearStage`.
+- **The in-situ sample environment (`INSITU-1`).** No temperature / electrochemistry / gas / cryostat device is PV-bound. When it lands it reuses `TemperatureController` / the graduated `FlowController` and the Subject / Supply / Procedure seam, not a new family.
+- **The resonant energy axis and polarization analysis (`RESONANT-1`).** The energy axis is a non-functional stub; no polarization analyzer or phase retarder is bound. When wired, the energy axis is a `PseudoAxis` over the DCM and polarization hardware reuses the catalog `PhaseRetarder` and `PolarizationAnalyzer` (4-ID).
+- **The flux monitors (`DET-1`).** The QuadEM electrometers and the secondary-source slit are defined but commented out in source; not modelled until live.
+- **The Methods.** Whether `resonant_scattering` and `diffraction` enter CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_isr_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive, and whose primary instrument is not even in source, would be invention; they land when the diffractometer is bound and the team confirms.
+
+## Open questions
+
+*What CORA needs the ISR team to confirm before the model can be trusted.*
+
+ISR was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/isr-profile-collection](https://github.com/NSLS2/isr-profile-collection)), which is an early / commissioning, optics-first scaffold. The control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff, and the devices ISR's mission implies are largely absent from the source. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### The mission gaps (the headline)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-go-live | The multi-circle diffractometer: only two axes (`th`, `zeta`) are bound under the `Dif:ISD` IOC. What are the full sample-orientation circles, the detector two-theta arm, and the reciprocal-space / hkl engine that resonant and surface (CTR) diffraction need? | One `RotaryStage` for the two bound axes; the full diffractometer is absent and not modelled. | The sample-orientation and detection-geometry modelling. |
+| INSITU-1 | Blocks-go-live | The in-situ sample environment: despite In Situ being the beamline's name, no temperature controller, electrochemistry / potentiostat, gas / flow, or cryostat is PV-bound. Which in-situ environments exist and what are their PVs? | No in-situ device modelled; carried as a named gap. | The in-situ sample-environment modelling. |
+| RESONANT-1 | Blocks-go-live | The resonant energy axis and polarization analysis: the DCM Bragg is the physical energy axis but a wired energy pseudo-axis is only a non-functional stub, and no polarization analyzer or phase retarder is bound. How is energy scanned for resonant work, and is polarization analyzed? | Energy via the DCM Bragg; no energy pseudo-axis or polarization device modelled. | The resonant-scattering modelling. |
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the optics zones (FE:C04A, XF:04IDA-OP, XF:04IDB-OP) and the zone-D endstation (XF:04IDD-ES) separate hutches? | Two enclosures: an `isr-optics` zone and the `isr-endstation` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The in-vacuum undulator model and energy range (only a read-only gap encoder is bound; no gap-drive setpoint). | An `InsertionDevice` undulator, observed gap; parameters pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state ISR reads (only the ring current is bound). | Observe-only machine state, a loose `StorageRing`; the rest pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The DCM crystal cut (Si(111) / Si(311)) and the energy range. | A double-crystal `Monochromator`; the crystal cut and range pending. | The monochromator Asset. |
+| OPT-1 | Nice-to-have | The focusing-mirror pair (HFM / VFM) and harmonic-rejection mirror (DHRM) coatings and bend mechanisms. | Bendable focusing + harmonic-rejection mirrors bound to `Mirror`; coatings pending. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The front-end slit blade-axis map, and the secondary-source (SSA) slit (defined but commented out in source). | A front-end `Slit`; the SSA carried as a deferred gap. | The slit Asset detail. |
+| ATTN-1 | Nice-to-have | The four-foil attenuator bank (bit-encoded transmission level) and its calibration. | The foils bound to `Filter`. | The attenuator Asset. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The Eiger 1M model and the write path (a commissioning `testing/` path in source), and the flux monitors (the QuadEM electrometers are defined but commented out; there is no point / scaler detector for diffraction counting). | One `Camera` Asset (Eiger 1M); no `FluxMonitor` Asset modelled until the electrometers are live. | The detector and flux-monitor modelling. |
+| DIAG-1 | Nice-to-have | The diagnostic screen cameras and the motorized beam-position monitor (only its stage motors are bound; the electrometers are commented out), and the position-versus-intensity split (the fleet-wide question). | `Camera` for the screens; the graduated catalog `PositionMonitor` for the BPM stage (presents Sensor, distinct from `FluxMonitor` by measuring beam position). | The diagnostic modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the profile representative of production (the databroker catalog is a placeholder name and several devices are commented out, both commissioning signals)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane (bluesky-queueserver + Tiled) is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (no PSS / shutter / hutch-interlock device is in the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the optics) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics. | The Supply observations. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do resonant scattering and surface (CTR) diffraction enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the 4-ID / CSX `resonant_scattering` and 4-ID / 8-ID `diffraction` Methods; doubly deferred because the diffractometer is absent from source (DIFF-1). | The technique Capabilities. |
diff --git a/docs/deployments/isr/questions.md b/docs/deployments/isr/questions.md
deleted file mode 100644
index 680dd2c969b..00000000000
--- a/docs/deployments/isr/questions.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Open questions
-
-*What CORA needs the ISR team to confirm before the model can be trusted.*
-
-ISR was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/isr-profile-collection](https://github.com/NSLS2/isr-profile-collection)), which is an early / commissioning, optics-first scaffold. The control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff, and the devices ISR's mission implies are largely absent from the source. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## The mission gaps (the headline)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-go-live | The multi-circle diffractometer: only two axes (`th`, `zeta`) are bound under the `Dif:ISD` IOC. What are the full sample-orientation circles, the detector two-theta arm, and the reciprocal-space / hkl engine that resonant and surface (CTR) diffraction need? | One `RotaryStage` for the two bound axes; the full diffractometer is absent and not modelled. | The sample-orientation and detection-geometry modelling. |
-| INSITU-1 | Blocks-go-live | The in-situ sample environment: despite In Situ being the beamline's name, no temperature controller, electrochemistry / potentiostat, gas / flow, or cryostat is PV-bound. Which in-situ environments exist and what are their PVs? | No in-situ device modelled; carried as a named gap. | The in-situ sample-environment modelling. |
-| RESONANT-1 | Blocks-go-live | The resonant energy axis and polarization analysis: the DCM Bragg is the physical energy axis but a wired energy pseudo-axis is only a non-functional stub, and no polarization analyzer or phase retarder is bound. How is energy scanned for resonant work, and is polarization analyzed? | Energy via the DCM Bragg; no energy pseudo-axis or polarization device modelled. | The resonant-scattering modelling. |
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the optics zones (FE:C04A, XF:04IDA-OP, XF:04IDB-OP) and the zone-D endstation (XF:04IDD-ES) separate hutches? | Two enclosures: an `isr-optics` zone and the `isr-endstation` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The in-vacuum undulator model and energy range (only a read-only gap encoder is bound; no gap-drive setpoint). | An `InsertionDevice` undulator, observed gap; parameters pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state ISR reads (only the ring current is bound). | Observe-only machine state, a loose `StorageRing`; the rest pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The DCM crystal cut (Si(111) / Si(311)) and the energy range. | A double-crystal `Monochromator`; the crystal cut and range pending. | The monochromator Asset. |
-| OPT-1 | Nice-to-have | The focusing-mirror pair (HFM / VFM) and harmonic-rejection mirror (DHRM) coatings and bend mechanisms. | Bendable focusing + harmonic-rejection mirrors bound to `Mirror`; coatings pending. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The front-end slit blade-axis map, and the secondary-source (SSA) slit (defined but commented out in source). | A front-end `Slit`; the SSA carried as a deferred gap. | The slit Asset detail. |
-| ATTN-1 | Nice-to-have | The four-foil attenuator bank (bit-encoded transmission level) and its calibration. | The foils bound to `Filter`. | The attenuator Asset. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The Eiger 1M model and the write path (a commissioning `testing/` path in source), and the flux monitors (the QuadEM electrometers are defined but commented out; there is no point / scaler detector for diffraction counting). | One `Camera` Asset (Eiger 1M); no `FluxMonitor` Asset modelled until the electrometers are live. | The detector and flux-monitor modelling. |
-| DIAG-1 | Nice-to-have | The diagnostic screen cameras and the motorized beam-position monitor (only its stage motors are bound; the electrometers are commented out), and the position-versus-intensity split (the fleet-wide question). | `Camera` for the screens; the graduated catalog `PositionMonitor` for the BPM stage (presents Sensor, distinct from `FluxMonitor` by measuring beam position). | The diagnostic modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the profile representative of production (the databroker catalog is a placeholder name and several devices are commented out, both commissioning signals)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane (bluesky-queueserver + Tiled) is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the photon / front-end shutters (no PSS / shutter / hutch-interlock device is in the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the optics) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics. | The Supply observations. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do resonant scattering and surface (CTR) diffraction enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the 4-ID / CSX `resonant_scattering` and 4-ID / 8-ID `diffraction` Methods; doubly deferred because the diffractometer is absent from source (DIFF-1). | The technique Capabilities. |
diff --git a/docs/deployments/isr/techniques.md b/docs/deployments/isr/techniques.md
deleted file mode 100644
index d067d0826b3..00000000000
--- a/docs/deployments/isr/techniques.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Techniques
-
-*What ISR is designed to do, as intent. A deliberately partial first cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. ISR's mission is hard X-ray resonant scattering and surface / interface diffraction, with in-situ sample environments. The Methods below render unlinked and are **doubly deferred**: the Methods themselves are pending, and the multi-circle diffractometer they run on is absent from the source (`TECH-1`, `DIFF-1`).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant scattering | `resonant_scattering` | resonant elastic scattering near an absorption edge; reuses the Method APS [4-ID](../4-id/techniques.md) (POLAR) and [CSX](../csx/techniques.md) left pending; needs a tunable energy axis and a diffractometer, both absent from source (`TECH-1`, `RESONANT-1`, `DIFF-1`) |
-| Surface / interface diffraction | `diffraction` | crystal truncation rods and surface structure; reuses the `diffraction` Method 4-ID / [8-ID](../8-id/techniques.md) left pending; needs the multi-circle diffractometer, absent from source (`TECH-1`, `DIFF-1`) |
-
-Both techniques would need the [incident-beam chain](source.md) (the undulator, the DCM for energy, the focusing mirrors, the attenuator), a multi-circle [sample diffractometer](sample.md), and the [Eiger area detector](detector.md). The first two of those are partly modelled; the diffractometer is not.
-
-## Reuse, not new vocabulary
-
-ISR coins **no new Method**. Its resonant scattering reuses the `resonant_scattering` Method that APS 4-ID brought and CSX shares; its surface / CTR diffraction reuses the `diffraction` Method that 4-ID / 8-ID share. So ISR adds, when it lands, further consumers of two pending Methods, strengthening the case for cataloging them, but it does not mint vocabulary. The matching Site Practices (`ISR_resonant_scattering_practice`, `ISR_surface_diffraction_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here).
-
-## Why these are doubly deferred
-
-For every other beamline the technique Methods are deferred because the Capability is not yet in the catalog (the owner-scope decision). At ISR there is a second, harder deferral: the **devices** the techniques run on are not in the public source. Resonant scattering needs a tunable energy axis (a non-functional stub here, `RESONANT-1`) and surface diffraction needs a multi-circle diffractometer (only two axes bound, `DIFF-1`). So these Practices are intent recorded against a partial scaffold, not a capability CORA could drive today. They firm up as the diffractometer and the energy axis enter the source.
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet, and cannot be until the diffractometer lands: the reciprocal-space (hkl) scans, the rocking-curve and CTR trajectories, the energy scans across an edge for resonant work, and the in-situ environment programs. The integration and reduction (azimuthal / CTR rod integration) are `ComputePort` work, not beamline Methods. These join as ISR's profile collection grows past its current optics-first state.
-
-See [Open questions](questions.md) for the world-facts to confirm first, especially the diffractometer (`DIFF-1`) and the in-situ environment (`INSITU-1`).
diff --git a/docs/deployments/iss/governance.md b/docs/deployments/iss/governance.md
deleted file mode 100644
index 5d5b41288d2..00000000000
--- a/docs/deployments/iss/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at ISS and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An ISS beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may load an energy trajectory, sweep the energy, start an acquisition, move the emission-spectrometer crystals, run an in-situ program, override a caution, or commit an energy calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## The energy-scan under custody
-
-ISS's defining operation is the trajectory energy fly-scan, which couples the monochromator, the encoder, and the streaming detectors as one timed sweep. CORA's Campaign and Trust shapes are where that resolves: loading and starting a trajectory is a command the trust boundary gates, and the per-scan energy calibration (the reference foil read on the reference ion chamber) is a committed fact under custody, not an ad-hoc adjustment. If an autonomous Agent were added to drive the EXAFS / HERFD program (a common pattern at high-throughput XAS beamlines), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/iss/model.md b/docs/deployments/iss/model.md
deleted file mode 100644
index 92821033836..00000000000
--- a/docs/deployments/iss/model.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's ISS content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at ISS |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (8-ID-A optics, 8-ID-B experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates
-
-ISS earns one catalog change: the **`EmissionSpectrometer`** Family GRADUATED. LCLS-MFX introduced it for its von Hamos six-crystal XES spectrometer and carried it loose at n=1 (SPEC-1, with MAX IV Balder noted as a near-sighting). ISS's Johann and von Hamos crystal emission spectrometers are the **second** sighting, earning the rule-of-three the way `GratingMonochromator` (CSX), `Manipulator` (ESM), and `ElectronAnalyzer` (SST) graduated at their second sighting. The abstraction is settled (a crystal-analyzer emission spectrometer composing analyzer crystals and a 2D detector along a Rowland-circle or wavelength-dispersive geometry is a distinct, recurring device, not a point Sensor and not a beam-conditioning Monochromator), so it GRADUATED into the catalog (SPEC-1); LCLS-MFX's references were swept loose to graduated alongside. It stays distinct from the still-loose `EnergyAnalyzer` (the IXS diced-crystal energy-selecting analyzer, ANALYZER-1), which graduates nothing until its own rule-of-three, and from the catalog `SpectrometerArm` (the SIX soft X-ray grating dispersive RIXS arm, since graduated across SIX + ID32 + ID28, RIXS-1).
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
-
-- **No new loose Family.** ISS is otherwise a reuse deployment: the trajectory and high-resolution monochromators bind `Monochromator`, the mirrors `Mirror`, the filter box `Filter`, the slits `Slit`, the shutters `Shutter`, the energy axis `PseudoAxis`, the sample stage `LinearStage`, the goniometer `Goniometer`, the reference foil wheel `RotaryStage`, the thermal stage `TemperatureController`, the ion chambers `FluxMonitor`, the Xspress3 SDD `EnergyDispersiveSpectrometer`, the Pilatus `Camera`, the trajectory controller `MotionController`, the analog pizza box `TimingController`.
-- **The graduated `PositionMonitor`.** The beam-position diagnostics bind the graduated catalog `PositionMonitor` Family that the wide fleet shares; it presents the `Sensor` Role, earned across that fleet, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset beam-position channel map is the residual (`DIAG-1`).
-- **No new Capability or Method.** EXAFS leans on the deferred `energy_scan` Capability (ENERGY-1, the BMM question; ISS strengthens it as a further consumer without forcing it); XES / HERFD reuse the `xas_spectroscopy` Method LCLS-MFX left pending, the second consumer (TECH-1). ISS records that one pending Practice and coins nothing. The per-technique reduction is `ComputePort` work.
-- **The deferred in-situ environment.** The ion-chamber fill-gas mass-flow controllers (He / N2) would bind the graduated `FlowController` Family, but they and the broader in-situ sample environment are named in a question (`ENV-1`) rather than modelled at this design phase. ISS models the main transmission / fluorescence / emission legs as the representative configuration.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/iss/notes.md b/docs/deployments/iss/notes.md
new file mode 100644
index 00000000000..dbe0651cb61
--- /dev/null
+++ b/docs/deployments/iss/notes.md
@@ -0,0 +1,106 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at ISS: X-ray absorption and X-ray emission spectroscopy, each a [Catalog](../../catalog/methods.md) Method. ISS follows the deferral discipline of the beamlines that brought spectroscopy to CORA.*
+
+ISS's measurement is energy spectroscopy: it sweeps the incident energy across an absorption edge (EXAFS) and, with the crystal emission spectrometers, resolves the emitted spectrum (XES) or selects an emission line during the incident-energy sweep (HERFD). The Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Mode | Notes |
+| --- | --- | --- |
+| X-ray absorption (EXAFS) | transmission / fluorescence, energy fly-scan | I0 / It / Ir ion chambers or the Xspress3 SDD over a trajectory energy sweep; the BMM energy-scan question (ENERGY-1, TECH-1) |
+| X-ray emission (XES) | emission spectrometer, fixed incident energy | the Johann or von Hamos crystal spectrometer disperses the emitted spectrum onto the area detector (SPEC-1, TECH-1) |
+| HERFD | emission spectrometer, incident-energy fly-scan | high-energy-resolution fluorescence detection: scan the incident energy, read one emission line through the analyzer (ENERGY-1, SPEC-1) |
+
+All three need the [sample stage](sample.md) and a [detector](detector.md); the trajectory fly-scan sweeps the energy and the analog pizza box reads the detectors synchronously.
+
+### Why the Method scope stays pending
+
+ISS's absorption and emission both lean on energy spectroscopy CORA carries pending. EXAFS is the energy-sweep-as-the-measurement case BMM raised: the `energy_scan` Capability is anticipated in the catalog but deferred until a conduct-path forces it (ENERGY-1), and a descriptor scaffold does not force it; ISS is a further consumer that strengthens the case without coining it. The emission techniques (XES, HERFD) are the same shape LCLS-MFX left pending as the `xas_spectroscopy` Method (XAS / XES via the emission spectrometer), so ISS **reuses** that Method as the second consumer rather than coining a new one (TECH-1), and records that one pending Practice on the [NSLS-II Site](../nsls2/index.md). The device Roles already exist (the ion chambers present Sensor, the SDD the energy-dispersive Sensor, the emission spectrometers the Detector Role); what is new is the science Method, not a device shape.
+
+The per-technique reduction (EXAFS normalization and fitting, XES / HERFD spectra) is `ComputePort` work, not beamline Methods.
+
+## Governance
+
+*Who may act at ISS and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An ISS beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may load an energy trajectory, sweep the energy, start an acquisition, move the emission-spectrometer crystals, run an in-situ program, override a caution, or commit an energy calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### The energy-scan under custody
+
+ISS's defining operation is the trajectory energy fly-scan, which couples the monochromator, the encoder, and the streaming detectors as one timed sweep. CORA's Campaign and Trust shapes are where that resolves: loading and starting a trajectory is a command the trust boundary gates, and the per-scan energy calibration (the reference foil read on the reference ion chamber) is a committed fact under custody, not an ad-hoc adjustment. If an autonomous Agent were added to drive the EXAFS / HERFD program (a common pattern at high-throughput XAS beamlines), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's ISS content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at ISS |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (8-ID-A optics, 8-ID-B experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates
+
+ISS earns one catalog change: the **`EmissionSpectrometer`** Family GRADUATED. LCLS-MFX introduced it for its von Hamos six-crystal XES spectrometer and carried it loose at n=1 (SPEC-1, with MAX IV Balder noted as a near-sighting). ISS's Johann and von Hamos crystal emission spectrometers are the **second** sighting, earning the rule-of-three the way `GratingMonochromator` (CSX), `Manipulator` (ESM), and `ElectronAnalyzer` (SST) graduated at their second sighting. The abstraction is settled (a crystal-analyzer emission spectrometer composing analyzer crystals and a 2D detector along a Rowland-circle or wavelength-dispersive geometry is a distinct, recurring device, not a point Sensor and not a beam-conditioning Monochromator), so it GRADUATED into the catalog (SPEC-1); LCLS-MFX's references were swept loose to graduated alongside. It stays distinct from the still-loose `EnergyAnalyzer` (the IXS diced-crystal energy-selecting analyzer, ANALYZER-1), which graduates nothing until its own rule-of-three, and from the catalog `SpectrometerArm` (the SIX soft X-ray grating dispersive RIXS arm, since graduated across SIX + ID32 + ID28, RIXS-1).
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
+
+- **No new loose Family.** ISS is otherwise a reuse deployment: the trajectory and high-resolution monochromators bind `Monochromator`, the mirrors `Mirror`, the filter box `Filter`, the slits `Slit`, the shutters `Shutter`, the energy axis `PseudoAxis`, the sample stage `LinearStage`, the goniometer `Goniometer`, the reference foil wheel `RotaryStage`, the thermal stage `TemperatureController`, the ion chambers `FluxMonitor`, the Xspress3 SDD `EnergyDispersiveSpectrometer`, the Pilatus `Camera`, the trajectory controller `MotionController`, the analog pizza box `TimingController`.
+- **The graduated `PositionMonitor`.** The beam-position diagnostics bind the graduated catalog `PositionMonitor` Family that the wide fleet shares; it presents the `Sensor` Role, earned across that fleet, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset beam-position channel map is the residual (`DIAG-1`).
+- **No new Capability or Method.** EXAFS leans on the deferred `energy_scan` Capability (ENERGY-1, the BMM question; ISS strengthens it as a further consumer without forcing it); XES / HERFD reuse the `xas_spectroscopy` Method LCLS-MFX left pending, the second consumer (TECH-1). ISS records that one pending Practice and coins nothing. The per-technique reduction is `ComputePort` work.
+- **The deferred in-situ environment.** The ion-chamber fill-gas mass-flow controllers (He / N2) would bind the graduated `FlowController` Family, but they and the broader in-situ sample environment are named in a question (`ENV-1`) rather than modelled at this design phase. ISS models the main transmission / fluorescence / emission legs as the representative configuration.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the ISS team to confirm. This model is reverse-engineered from public open source (the `NSLS2/iss-profile-collection` bluesky / ophyd startup files): the EPICS PVs are read from the `startup/*.py` device classes, but undulator parameters, crystal cuts, vendor identities, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The 8-ID insertion-device identity, period, and gap range. The profile collection drives photon energy through the HHM trajectory and does not expose the undulator gap PVs; only the ring current (`SR:OPS-BI{DCCT:1}`) is read. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:08ID-PPS{Sh:FE}`, `XF:08IDA-PPS{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The HHM and HRM crystal cuts, reflections, and energy ranges. Both monochromators (`Mono:HHM`, `Mono:HRM`) and the HHM trajectory controller (`MC:06`) are in source. | One trajectory DCM and one high-resolution mono Asset, crystal settings blank. | The Monochromator settings. |
+| ENERGY-1 | Nice-to-have | ISS's measurement sweeps the energy axis (EXAFS) as a trajectory fly-scan, the textbook case for the energy-scan Capability the catalog anticipates. Does CORA coin `energy_scan` now, or keep it deferred until a conduct-path forces it? | Energy-scan deferred (the BMM question); ISS is a further consumer that strengthens the case. | The energy-scan Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SPEC-1 | Blocks-go-live | The Johann and von Hamos crystal emission spectrometer geometry: the analyzer crystal cut, the Rowland-circle radius, and whether each of the (Johann: main + four auxiliary) analyzer crystals is a child Asset or a setting on the one spectrometer Asset. | Two `EmissionSpectrometer` Assets (catalog Family, graduated at this 2nd sighting after LCLS-MFX); crystals as settings for now. | The emission-spectrometer model and analyzer-crystal composition. |
+| DET-1 | Blocks-go-live | The detector roster: the ion-chamber channel map (I0 / It / Ir / If through the ICAmplifier / Keithley-428 amps and the analog pizza box), the Xspress3 element count and ROI map, and which Pilatus serves which spectrometer. | The ion chambers, the 4-channel Xspress3, and one Pilatus modelled; channel maps blank. | The detector roster and channel maps. |
+| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live (the Lakeshore 331 is in source; cryostat / furnace not). | One `TemperatureController` Asset; the others noted. | The sample-environment Assets. |
+| ENV-1 | Nice-to-have | The ion-chamber fill-gas flow (He / N2 mass-flow controllers `XF:08IDB-OP{IC}FLW:`) and the broader in-situ sample environment. The mass-flow controllers would bind the graduated FlowController Family; the broader environment is deferred at this design phase. | Deferred; fill gas and in-situ environment named here, not modelled. | The fill-gas and in-situ Assets. |
+| DIAG-1 | Nice-to-have | The beam-position channel map (the Prosilica BPM cameras and the sample-positioner cameras); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The PositionMonitor bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the Delta-Tau HHM trajectory controller `MC:06`, the von Hamos `MC:3-Ax:` axes, and the EPICS motor records). | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the X-ray absorption (EXAFS) and X-ray emission (XES / HERFD) techniques enter CORA's catalog as Methods, or stay pending? ISS reuses the `xas_spectroscopy` Method LCLS-MFX left pending, the second consumer. | The `xas_spectroscopy` Method reused pending; no new Method coined (the BMM / SST deferral discipline). | The technique Method scope. |
diff --git a/docs/deployments/iss/questions.md b/docs/deployments/iss/questions.md
deleted file mode 100644
index bee24817875..00000000000
--- a/docs/deployments/iss/questions.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Open questions
-
-*What CORA needs the ISS team to confirm. This model is reverse-engineered from public open source (the `NSLS2/iss-profile-collection` bluesky / ophyd startup files): the EPICS PVs are read from the `startup/*.py` device classes, but undulator parameters, crystal cuts, vendor identities, and physical positions are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The 8-ID insertion-device identity, period, and gap range. The profile collection drives photon energy through the HHM trajectory and does not expose the undulator gap PVs; only the ring current (`SR:OPS-BI{DCCT:1}`) is read. | An in-vacuum undulator on the 3 GeV ring, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:08ID-PPS{Sh:FE}`, `XF:08IDA-PPS{PSh}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The HHM and HRM crystal cuts, reflections, and energy ranges. Both monochromators (`Mono:HHM`, `Mono:HRM`) and the HHM trajectory controller (`MC:06`) are in source. | One trajectory DCM and one high-resolution mono Asset, crystal settings blank. | The Monochromator settings. |
-| ENERGY-1 | Nice-to-have | ISS's measurement sweeps the energy axis (EXAFS) as a trajectory fly-scan, the textbook case for the energy-scan Capability the catalog anticipates. Does CORA coin `energy_scan` now, or keep it deferred until a conduct-path forces it? | Energy-scan deferred (the BMM question); ISS is a further consumer that strengthens the case. | The energy-scan Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SPEC-1 | Blocks-go-live | The Johann and von Hamos crystal emission spectrometer geometry: the analyzer crystal cut, the Rowland-circle radius, and whether each of the (Johann: main + four auxiliary) analyzer crystals is a child Asset or a setting on the one spectrometer Asset. | Two `EmissionSpectrometer` Assets (catalog Family, graduated at this 2nd sighting after LCLS-MFX); crystals as settings for now. | The emission-spectrometer model and analyzer-crystal composition. |
-| DET-1 | Blocks-go-live | The detector roster: the ion-chamber channel map (I0 / It / Ir / If through the ICAmplifier / Keithley-428 amps and the analog pizza box), the Xspress3 element count and ROI map, and which Pilatus serves which spectrometer. | The ion chambers, the 4-channel Xspress3, and one Pilatus modelled; channel maps blank. | The detector roster and channel maps. |
-| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live (the Lakeshore 331 is in source; cryostat / furnace not). | One `TemperatureController` Asset; the others noted. | The sample-environment Assets. |
-| ENV-1 | Nice-to-have | The ion-chamber fill-gas flow (He / N2 mass-flow controllers `XF:08IDB-OP{IC}FLW:`) and the broader in-situ sample environment. The mass-flow controllers would bind the graduated FlowController Family; the broader environment is deferred at this design phase. | Deferred; fill gas and in-situ environment named here, not modelled. | The fill-gas and in-situ Assets. |
-| DIAG-1 | Nice-to-have | The beam-position channel map (the Prosilica BPM cameras and the sample-positioner cameras); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | Read-only beam-position (graduated catalog `PositionMonitor`) probes; channel map blank. | The PositionMonitor bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, and IPs (the Delta-Tau HHM trajectory controller `MC:06`, the von Hamos `MC:3-Ax:` axes, and the EPICS motor records). | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the X-ray absorption (EXAFS) and X-ray emission (XES / HERFD) techniques enter CORA's catalog as Methods, or stay pending? ISS reuses the `xas_spectroscopy` Method LCLS-MFX left pending, the second consumer. | The `xas_spectroscopy` Method reused pending; no new Method coined (the BMM / SST deferral discipline). | The technique Method scope. |
diff --git a/docs/deployments/iss/techniques.md b/docs/deployments/iss/techniques.md
deleted file mode 100644
index 0386b3c3279..00000000000
--- a/docs/deployments/iss/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What CORA would run at ISS: X-ray absorption and X-ray emission spectroscopy, each a [Catalog](../../catalog/methods.md) Method. ISS follows the deferral discipline of the beamlines that brought spectroscopy to CORA.*
-
-ISS's measurement is energy spectroscopy: it sweeps the incident energy across an absorption edge (EXAFS) and, with the crystal emission spectrometers, resolves the emitted spectrum (XES) or selects an emission line during the incident-energy sweep (HERFD). The Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Mode | Notes |
-| --- | --- | --- |
-| X-ray absorption (EXAFS) | transmission / fluorescence, energy fly-scan | I0 / It / Ir ion chambers or the Xspress3 SDD over a trajectory energy sweep; the BMM energy-scan question (ENERGY-1, TECH-1) |
-| X-ray emission (XES) | emission spectrometer, fixed incident energy | the Johann or von Hamos crystal spectrometer disperses the emitted spectrum onto the area detector (SPEC-1, TECH-1) |
-| HERFD | emission spectrometer, incident-energy fly-scan | high-energy-resolution fluorescence detection: scan the incident energy, read one emission line through the analyzer (ENERGY-1, SPEC-1) |
-
-All three need the [sample stage](sample.md) and a [detector](detector.md); the trajectory fly-scan sweeps the energy and the analog pizza box reads the detectors synchronously.
-
-## Why the Method scope stays pending
-
-ISS's absorption and emission both lean on energy spectroscopy CORA carries pending. EXAFS is the energy-sweep-as-the-measurement case BMM raised: the `energy_scan` Capability is anticipated in the catalog but deferred until a conduct-path forces it (ENERGY-1), and a descriptor scaffold does not force it; ISS is a further consumer that strengthens the case without coining it. The emission techniques (XES, HERFD) are the same shape LCLS-MFX left pending as the `xas_spectroscopy` Method (XAS / XES via the emission spectrometer), so ISS **reuses** that Method as the second consumer rather than coining a new one (TECH-1), and records that one pending Practice on the [NSLS-II Site](../nsls2/index.md). The device Roles already exist (the ion chambers present Sensor, the SDD the energy-dispersive Sensor, the emission spectrometers the Detector Role); what is new is the science Method, not a device shape.
-
-The per-technique reduction (EXAFS normalization and fitting, XES / HERFD spectra) is `ComputePort` work, not beamline Methods.
diff --git a/docs/deployments/ixs/governance.md b/docs/deployments/ixs/governance.md
deleted file mode 100644
index 5c65b3065fc..00000000000
--- a/docs/deployments/ixs/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at IXS, and the trust shape that will gate it. First cut.*
-
-Governance at IXS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-IXS is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md), shared with the rest of the fleet (`GOV-1`).
-
-The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. IXS adds the hazard classes that come with a hard X-ray endstation under vacuum and a temperature-stabilized crystal analyzer; those land with the instruments that bring them, and an experiment Clearance would carry them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives IXS, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/ixs/model.md b/docs/deployments/ixs/model.md
deleted file mode 100644
index ab545451015..00000000000
--- a/docs/deployments/ixs/model.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's IXS content lives, the one new loose family this first hard inelastic-scattering deployment introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at IXS |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes IXS new
-
-IXS is CORA's first photon-in / photon-out energy-LOSS technique. The fleet already has elastic scattering (SAXS/WAXS, XPDF, powder, XPCS, MX), XRF microprobe, hard X-ray absorption (BMM), and soft resonant inelastic scattering (SIX), but no hard inelastic scattering. The novelty is the acquisition shape: set the momentum transfer Q with a six-circle reciprocal-space pseudo-axis, then scan the incident energy (the DCM, and the high-resolution monochromator for meV steps) against a fixed crystal analyzer, point-detecting the energy-analyzed scattered beam to build I(Q, energy-loss). That is a new Capability, deferred as a question (TECH-1); it forces no new device families beyond the analyzer below.
-
-## New loose families
-
-IXS introduces one device class no existing catalog Family covers: the crystal energy analyzer. Per earn-the-abstraction, it is held **loose at n=1** and graduates nothing: a second independent hard crystal-analyzer beamline must earn the abstraction before any catalog change. The name was cleared by the naming-r3 gate.
-
-| Loose family | Presents (when graduated) | What it is | Earns when |
-| --- | --- | --- | --- |
-| `EnergyAnalyzer` | Positioner (Sensor-vs-Positioner a confirm) | a diced multi-crystal Bragg analyzer that selects the final photon energy of the scattered beam, focusing energy-selected photons onto the point detectors | a 2nd hard crystal-analyzer / IXS beamline (`ANALYZER-1`) |
-
-`EnergyAnalyzer` is deliberately not stretched onto an existing Family. It is not the catalog `EnergyDispersiveSpectrometer` (a per-event point Sensor that reads energy, where the analyzer positions crystals and the reading happens downstream at the electrometers), nor the catalog `Monochromator` (an upstream incident-beam optic), nor the catalog `SpectrometerArm` (the energy-dispersive arm SIX coined, since graduated; IXS uses a driven scanning crystal analyzer, not a dispersive one). naming-r3 chose `EnergyAnalyzer` over `Analyzer` and `CrystalAnalyzer`: it is the `<Quantity>Analyzer` sibling of the catalog `PolarizationAnalyzer` (the qualifier names the analyzed quantity), and it avoids the `CrystalAnalyzer` / `AnalyzerCrystal` read-aloud homograph. Whether `EnergyAnalyzer` and `PolarizationAnalyzer` later merge into one `Analyzer` Family differentiated by a setting is the open `ANALYZER-1`, a gate decision at the second sighting, not this PR's.
-
-## Deliberately not here yet
-
-- **The six-circle arm binds the catalog `Goniometer`, not a new family.** The spectrometer arm (tth / th / chi / phi driven by the H/K/L reciprocal-space pseudo-axis) is the 8-ID / 4-ID six-circle diffractometer anatomy. In descriptor mode it binds the catalog `Goniometer` directly (the 8-ID / 4-ID scaffold pattern), and SIX's dispersive `SpectrometerArm` is the wrong anatomy for a driven scanning arm. The reciprocal-space layer binds the catalog `PseudoAxis`.
-
-- **The analyzer-Assembly question (`ANALYZER-1`).** Whether the crystal analyzer plus the six-circle arm compose an `Assembly(Diffractometer)`-style Fixture is deferred, exactly as 8-ID and 4-ID deferred materializing their diffractometer Assemblies in descriptor mode. The first cut is a flat loose `EnergyAnalyzer` Asset plus a `Goniometer` arm Asset, with the Assembly named as the follow-on. An Assembly is earned at n=2 across independent beamlines; coining one at n=1 would be over-modelling.
-
-- **The diced-crystal identity (`XTAL-1`).** The six diced crystals each carry their own theta / phi and PID temperature, so each is identity-bearing. The lower-risk first cut carries them as settings on the one `EnergyAnalyzer` Asset; promoting each to a child Asset via `parent_id` is exactly the nested-component-identity convention, which is itself at a rule-of-three gate (applied only for `RotaryDriveChassis` so far), so IXS flags `XTAL-1` as a candidate trigger rather than asserting it. The six crystal-temperature PID loops are carried as one `TemperatureController` Asset for the same reason (`TEMP-1`).
-
-- **The high-resolution-mono beamstop (`HRM-1`).** The high-resolution monochromator carries an in-line beamstop; whether it is a distinct child `BeamStop` Asset is gated under the same nested-component rule-of-three.
-
-- **The IXS Method.** Whether momentum-resolved inelastic scattering enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
-
-- **The simulated devices and full asset-tree scenarios.** No `test_ixs_*.py` registers the IXS asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/ixs/notes.md b/docs/deployments/ixs/notes.md
new file mode 100644
index 00000000000..ae6693c275d
--- /dev/null
+++ b/docs/deployments/ixs/notes.md
@@ -0,0 +1,142 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of IXS is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. IXS's technique is momentum-resolved hard X-ray inelastic scattering, the fleet's first energy-loss method, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Momentum-resolved inelastic X-ray scattering
+
+IXS sets the momentum transfer Q with the six-circle reciprocal-space arm, then scans the incident energy against a fixed crystal analyzer and counts the energy-analyzed scattered photons, so the measurement is the intensity surface I(Q, energy-loss): how much energy the sample exchanges with the photon at a chosen momentum transfer. The energy loss is read as the difference between the scanned incident energy and the fixed final energy the analyzer passes.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Momentum-resolved inelastic X-ray scattering | `inelastic_scattering` | Q is set on the [six-circle spectrometer arm](detector.md) via the H/K/L reciprocal-space pseudo-axis; the incident energy is scanned on the [double-crystal and high-resolution monochromators](source.md) against the fixed [crystal energy analyzer](detector.md); the energy-analyzed signal is point-counted on the electrometers; Method not yet in catalog |
+
+It needs the [incident-energy chain](source.md) (the DCM for the coarse energy and the high-resolution monochromator for the meV steps), the [sample stage](sample.md), and the [six-circle arm, crystal energy analyzer, and counting detectors](detector.md). The arm scattering angle sets the magnitude of the momentum transfer; the analyzer fixes the final energy so the incident-energy scan reads out the energy loss.
+
+### A new operating axis for the fleet
+
+Energy loss is genuinely new for the fleet. The catalog already covers elastic scattering (SAXS/WAXS, XPDF, powder, XPCS, MX), XRF microprobe, hard X-ray absorption (BMM), and soft resonant inelastic scattering (SIX), but no hard inelastic scattering. The new axis is the acquisition shape itself: scan one optic (the incident energy) against a second, fixed energy-selecting optic (the crystal analyzer) while a point detector counts, rather than expose an area detector at one energy. That is a new Capability, deferred as a question (`TECH-1`); it forces no new device families beyond the loose [`EnergyAnalyzer`](#new-loose-families).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the incident-energy maps, the per-Q energy scans, the analyzer alignment, and the counting times) are not written yet; they join as the deployment approaches the point where CORA drives IXS. Whether the technique enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); hard inelastic scattering is a new regime for the fleet (see [Open questions](#open-questions) for the world-facts to confirm first).
+
+## Governance
+
+*Who will act at IXS, and the trust shape that will gate it. First cut.*
+
+Governance at IXS follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+IXS is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md), shared with the rest of the fleet (`GOV-1`).
+
+The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are absent from the beamline's profile collection, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. IXS adds the hazard classes that come with a hard X-ray endstation under vacuum and a temperature-stabilized crystal analyzer; those land with the instruments that bring them, and an experiment Clearance would carry them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives IXS, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's IXS content lives, the one new loose family this first hard inelastic-scattering deployment introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at IXS |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the reciprocal-space `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes IXS new
+
+IXS is CORA's first photon-in / photon-out energy-LOSS technique. The fleet already has elastic scattering (SAXS/WAXS, XPDF, powder, XPCS, MX), XRF microprobe, hard X-ray absorption (BMM), and soft resonant inelastic scattering (SIX), but no hard inelastic scattering. The novelty is the acquisition shape: set the momentum transfer Q with a six-circle reciprocal-space pseudo-axis, then scan the incident energy (the DCM, and the high-resolution monochromator for meV steps) against a fixed crystal analyzer, point-detecting the energy-analyzed scattered beam to build I(Q, energy-loss). That is a new Capability, deferred as a question (TECH-1); it forces no new device families beyond the analyzer below.
+
+### New loose families
+
+IXS introduces one device class no existing catalog Family covers: the crystal energy analyzer. Per earn-the-abstraction, it is held **loose at n=1** and graduates nothing: a second independent hard crystal-analyzer beamline must earn the abstraction before any catalog change. The name was cleared by the naming-r3 gate.
+
+| Loose family | Presents (when graduated) | What it is | Earns when |
+| --- | --- | --- | --- |
+| `EnergyAnalyzer` | Positioner (Sensor-vs-Positioner a confirm) | a diced multi-crystal Bragg analyzer that selects the final photon energy of the scattered beam, focusing energy-selected photons onto the point detectors | a 2nd hard crystal-analyzer / IXS beamline (`ANALYZER-1`) |
+
+`EnergyAnalyzer` is deliberately not stretched onto an existing Family. It is not the catalog `EnergyDispersiveSpectrometer` (a per-event point Sensor that reads energy, where the analyzer positions crystals and the reading happens downstream at the electrometers), nor the catalog `Monochromator` (an upstream incident-beam optic), nor the catalog `SpectrometerArm` (the energy-dispersive arm SIX coined, since graduated; IXS uses a driven scanning crystal analyzer, not a dispersive one). naming-r3 chose `EnergyAnalyzer` over `Analyzer` and `CrystalAnalyzer`: it is the `<Quantity>Analyzer` sibling of the catalog `PolarizationAnalyzer` (the qualifier names the analyzed quantity), and it avoids the `CrystalAnalyzer` / `AnalyzerCrystal` read-aloud homograph. Whether `EnergyAnalyzer` and `PolarizationAnalyzer` later merge into one `Analyzer` Family differentiated by a setting is the open `ANALYZER-1`, a gate decision at the second sighting, not this PR's.
+
+### Deliberately not here yet
+
+- **The six-circle arm binds the catalog `Goniometer`, not a new family.** The spectrometer arm (tth / th / chi / phi driven by the H/K/L reciprocal-space pseudo-axis) is the 8-ID / 4-ID six-circle diffractometer anatomy. In descriptor mode it binds the catalog `Goniometer` directly (the 8-ID / 4-ID scaffold pattern), and SIX's dispersive `SpectrometerArm` is the wrong anatomy for a driven scanning arm. The reciprocal-space layer binds the catalog `PseudoAxis`.
+
+- **The analyzer-Assembly question (`ANALYZER-1`).** Whether the crystal analyzer plus the six-circle arm compose an `Assembly(Diffractometer)`-style Fixture is deferred, exactly as 8-ID and 4-ID deferred materializing their diffractometer Assemblies in descriptor mode. The first cut is a flat loose `EnergyAnalyzer` Asset plus a `Goniometer` arm Asset, with the Assembly named as the follow-on. An Assembly is earned at n=2 across independent beamlines; coining one at n=1 would be over-modelling.
+
+- **The diced-crystal identity (`XTAL-1`).** The six diced crystals each carry their own theta / phi and PID temperature, so each is identity-bearing. The lower-risk first cut carries them as settings on the one `EnergyAnalyzer` Asset; promoting each to a child Asset via `parent_id` is exactly the nested-component-identity convention, which is itself at a rule-of-three gate (applied only for `RotaryDriveChassis` so far), so IXS flags `XTAL-1` as a candidate trigger rather than asserting it. The six crystal-temperature PID loops are carried as one `TemperatureController` Asset for the same reason (`TEMP-1`).
+
+- **The high-resolution-mono beamstop (`HRM-1`).** The high-resolution monochromator carries an in-line beamstop; whether it is a distinct child `BeamStop` Asset is gated under the same nested-component rule-of-three.
+
+- **The IXS Method.** Whether momentum-resolved inelastic scattering enters CORA's catalog as a Capability / Method is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
+
+- **The simulated devices and full asset-tree scenarios.** No `test_ixs_*.py` registers the IXS asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the IXS team to confirm before the model can be trusted.*
+
+IXS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/ixs-profile-collection](https://github.com/NSLS2/ixs-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the new loose `EnergyAnalyzer` family). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | Does 10-ID share a canted straight with a sibling beamline, or run off its own undulator in series? | One root Unit Asset `IXS` on its own straight. | The source topology in the [descriptor](index.md). |
+| ENC-1 | Blocks-go-live | Are the PV zones `XF:10IDA/B/C/D` four separate shielded hutches or beam zones within fewer hutches? | Four enclosures, one per zone. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The IVU22 undulator period and type. | An in-vacuum undulator on `SR:C10-ID:G1{IVU22:1}`, period carried pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state IXS reads (current, fill, top-up). | Observe-only machine state on `SR:OPS-BI{DCCT:1}`, a loose `StorageRing`. | The machine-state observation. |
+| FEEDBACK-1 | Nice-to-have | How should the source-orbit feedback (`SR:UOFB`) be modelled, if at all? | Carried family-less, modelling deferred (the i03 `XBPMFeedback` precedent). | The feedback Asset. |
+| MONO-1 | Blocks-go-live | The DCM crystal cut / d-spacing, the incident-energy range, and the energy pseudo-axis partition rule. | Si(111) DCM, range 7.835-17.7 keV, energy via the DCM Bragg angle coupled to the undulator gap. | The monochromator and incident-energy Assets. |
+| HRM-1 | Blocks-go-live | The high-resolution monochromator crystals, its meV resolution, and whether its in-line beamstop is a distinct identity-bearing Asset. | A second crystal `Monochromator` Asset; the beamstop carried as a note, not yet a child Asset. | The high-resolution mono Asset. |
+| OPT-1 | Nice-to-have | The mirror coatings, bend mechanisms, and axis roles (VFM / HFM). | Grazing-incidence focusing mirrors bound to `Mirror`; coatings pending. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis roles of each slit (front-end, DCM, SSA, transport, endstation, analyzer). | Four-blade variable openings bound to `Slit`. | The slit Asset detail. |
+| PH-1 | Nice-to-have | Is the focusing pinhole a positioned beam-shaping aperture (`Aperture`) or a plain fixed opening (`Mask`)? | Bound to `Aperture` on the round-opening precedent; the catalog wording leans `Mask`. | The pinhole Family. |
+| MCM-1 | Nice-to-have | Is the MCM optics manipulator six coupled parallel-kinematics axes (a `Hexapod`) or independent serial rotations? | A coupled six-DOF `Hexapod`. | The manipulator Family. |
+
+### Sample and spectrometer
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | Are the sample table (`Spec:1`) and the sample-environment translations (`Env:1`) one fused stage or two siblings, and what is mounted on them? | Two sibling `LinearStage` Assets on their separate PV roots. | The sample-stage modelling. |
+| ANALYZER-1 | Blocks-build | How is the crystal energy analyzer configured: the diced-crystal Bragg geometry, the analyzed final energy, and whether it shares mechanics with the six-circle arm? | A diced multi-crystal Bragg analyzer on the spectrometer arm, selecting a fixed final energy. | The analyzer geometry; the CORA structural modelling is on [Model](#deliberately-not-here-yet). |
+| XTAL-1 | Blocks-go-live | Are the six diced analyzer crystals individually addressed (each its own theta / phi and temperature loop), and do they act as one analyzer? | Six crystals, each with theta / phi and a PID temperature, acting as one analyzer. | The diced-crystal addressing; the child-Asset modelling is on [Model](#deliberately-not-here-yet). |
+| TEMP-1 | Nice-to-have | Are the six crystal-temperature PID loops one Asset or six, and do they parent to the analyzer or to per-crystal child Assets? | One `TemperatureController` Asset noting six PID channels. | The thermal-control modelling. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The electrometer / scaler channel map: which channels are the analyzed-signal detector, which is I0, and whether the analyzer-focus photodiode is a separate Asset or a channel. | Quad electrometers + the scaler I0 bound to `FluxMonitor`; the focus diode is a channel, not a standalone Asset. | The detector modelling. |
+| ENERGY-1 | Nice-to-have | The read-only derived diffractometer angles (`HKLDerived`) present the Sensor read-back facet, not a driven axis. | A read-back facet of the reciprocal-space `PseudoAxis`. | The pseudo-axis read modelling. |
+| DIAG-1 | Blocks-go-live | The beam-position monitors bind the graduated catalog `PositionMonitor` Family; what beam-center calibration and diagnostic-foil channel detail do they need? | The graduated catalog `PositionMonitor` (presents `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux), the NSLS-II sibling choice; beam-center and foil channels to supply. | The beam-position-monitor calibration and channel detail. |
+| BPM-1 | Nice-to-have | Which monitors are true beam-position monitors versus intensity (I0) normalizers? | Treated as beam-position monitors; the intensity ones would be `FluxMonitor`. | The position-vs-intensity split. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the ixs-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+| SUP-1 | Nice-to-have | The vacuum extent and the analyzer thermal-stabilization supply. | Photon beam, cooling water, and vacuum on the optics and spectrometer path. | The Supply observations. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does the momentum-resolved inelastic-scattering technique enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice, no `cora.capability.ixs` coined. | The IXS Capability. |
diff --git a/docs/deployments/ixs/questions.md b/docs/deployments/ixs/questions.md
deleted file mode 100644
index c4071a52a07..00000000000
--- a/docs/deployments/ixs/questions.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Open questions
-
-*What CORA needs the IXS team to confirm before the model can be trusted.*
-
-IXS was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/ixs-profile-collection](https://github.com/NSLS2/ixs-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the new loose `EnergyAnalyzer` family). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | Does 10-ID share a canted straight with a sibling beamline, or run off its own undulator in series? | One root Unit Asset `IXS` on its own straight. | The source topology in the [descriptor](index.md). |
-| ENC-1 | Blocks-go-live | Are the PV zones `XF:10IDA/B/C/D` four separate shielded hutches or beam zones within fewer hutches? | Four enclosures, one per zone. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The IVU22 undulator period and type. | An in-vacuum undulator on `SR:C10-ID:G1{IVU22:1}`, period carried pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state IXS reads (current, fill, top-up). | Observe-only machine state on `SR:OPS-BI{DCCT:1}`, a loose `StorageRing`. | The machine-state observation. |
-| FEEDBACK-1 | Nice-to-have | How should the source-orbit feedback (`SR:UOFB`) be modelled, if at all? | Carried family-less, modelling deferred (the i03 `XBPMFeedback` precedent). | The feedback Asset. |
-| MONO-1 | Blocks-go-live | The DCM crystal cut / d-spacing, the incident-energy range, and the energy pseudo-axis partition rule. | Si(111) DCM, range 7.835-17.7 keV, energy via the DCM Bragg angle coupled to the undulator gap. | The monochromator and incident-energy Assets. |
-| HRM-1 | Blocks-go-live | The high-resolution monochromator crystals, its meV resolution, and whether its in-line beamstop is a distinct identity-bearing Asset. | A second crystal `Monochromator` Asset; the beamstop carried as a note, not yet a child Asset. | The high-resolution mono Asset. |
-| OPT-1 | Nice-to-have | The mirror coatings, bend mechanisms, and axis roles (VFM / HFM). | Grazing-incidence focusing mirrors bound to `Mirror`; coatings pending. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis roles of each slit (front-end, DCM, SSA, transport, endstation, analyzer). | Four-blade variable openings bound to `Slit`. | The slit Asset detail. |
-| PH-1 | Nice-to-have | Is the focusing pinhole a positioned beam-shaping aperture (`Aperture`) or a plain fixed opening (`Mask`)? | Bound to `Aperture` on the round-opening precedent; the catalog wording leans `Mask`. | The pinhole Family. |
-| MCM-1 | Nice-to-have | Is the MCM optics manipulator six coupled parallel-kinematics axes (a `Hexapod`) or independent serial rotations? | A coupled six-DOF `Hexapod`. | The manipulator Family. |
-
-## Sample and spectrometer
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | Are the sample table (`Spec:1`) and the sample-environment translations (`Env:1`) one fused stage or two siblings, and what is mounted on them? | Two sibling `LinearStage` Assets on their separate PV roots. | The sample-stage modelling. |
-| ANALYZER-1 | Blocks-build | How is the crystal energy analyzer configured: the diced-crystal Bragg geometry, the analyzed final energy, and whether it shares mechanics with the six-circle arm? | A diced multi-crystal Bragg analyzer on the spectrometer arm, selecting a fixed final energy. | The analyzer geometry; the CORA structural modelling is on [Model](model.md#deliberately-not-here-yet). |
-| XTAL-1 | Blocks-go-live | Are the six diced analyzer crystals individually addressed (each its own theta / phi and temperature loop), and do they act as one analyzer? | Six crystals, each with theta / phi and a PID temperature, acting as one analyzer. | The diced-crystal addressing; the child-Asset modelling is on [Model](model.md#deliberately-not-here-yet). |
-| TEMP-1 | Nice-to-have | Are the six crystal-temperature PID loops one Asset or six, and do they parent to the analyzer or to per-crystal child Assets? | One `TemperatureController` Asset noting six PID channels. | The thermal-control modelling. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The electrometer / scaler channel map: which channels are the analyzed-signal detector, which is I0, and whether the analyzer-focus photodiode is a separate Asset or a channel. | Quad electrometers + the scaler I0 bound to `FluxMonitor`; the focus diode is a channel, not a standalone Asset. | The detector modelling. |
-| ENERGY-1 | Nice-to-have | The read-only derived diffractometer angles (`HKLDerived`) present the Sensor read-back facet, not a driven axis. | A read-back facet of the reciprocal-space `PseudoAxis`. | The pseudo-axis read modelling. |
-| DIAG-1 | Blocks-go-live | The beam-position monitors bind the graduated catalog `PositionMonitor` Family; what beam-center calibration and diagnostic-foil channel detail do they need? | The graduated catalog `PositionMonitor` (presents `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux), the NSLS-II sibling choice; beam-center and foil channels to supply. | The beam-position-monitor calibration and channel detail. |
-| BPM-1 | Nice-to-have | Which monitors are true beam-position monitors versus intensity (I0) normalizers? | Treated as beam-position monitors; the intensity ones would be `FluxMonitor`. | The position-vs-intensity split. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the ixs-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (absent from the profile collection). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-| SUP-1 | Nice-to-have | The vacuum extent and the analyzer thermal-stabilization supply. | Photon beam, cooling water, and vacuum on the optics and spectrometer path. | The Supply observations. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does the momentum-resolved inelastic-scattering technique enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice, no `cora.capability.ixs` coined. | The IXS Capability. |
diff --git a/docs/deployments/ixs/techniques.md b/docs/deployments/ixs/techniques.md
deleted file mode 100644
index cdd4298a0c7..00000000000
--- a/docs/deployments/ixs/techniques.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Techniques
-
-*What the modelled part of IXS is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. IXS's technique is momentum-resolved hard X-ray inelastic scattering, the fleet's first energy-loss method, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Momentum-resolved inelastic X-ray scattering
-
-IXS sets the momentum transfer Q with the six-circle reciprocal-space arm, then scans the incident energy against a fixed crystal analyzer and counts the energy-analyzed scattered photons, so the measurement is the intensity surface I(Q, energy-loss): how much energy the sample exchanges with the photon at a chosen momentum transfer. The energy loss is read as the difference between the scanned incident energy and the fixed final energy the analyzer passes.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Momentum-resolved inelastic X-ray scattering | `inelastic_scattering` | Q is set on the [six-circle spectrometer arm](detector.md) via the H/K/L reciprocal-space pseudo-axis; the incident energy is scanned on the [double-crystal and high-resolution monochromators](source.md) against the fixed [crystal energy analyzer](detector.md); the energy-analyzed signal is point-counted on the electrometers; Method not yet in catalog |
-
-It needs the [incident-energy chain](source.md) (the DCM for the coarse energy and the high-resolution monochromator for the meV steps), the [sample stage](sample.md), and the [six-circle arm, crystal energy analyzer, and counting detectors](detector.md). The arm scattering angle sets the magnitude of the momentum transfer; the analyzer fixes the final energy so the incident-energy scan reads out the energy loss.
-
-## A new operating axis for the fleet
-
-Energy loss is genuinely new for the fleet. The catalog already covers elastic scattering (SAXS/WAXS, XPDF, powder, XPCS, MX), XRF microprobe, hard X-ray absorption (BMM), and soft resonant inelastic scattering (SIX), but no hard inelastic scattering. The new axis is the acquisition shape itself: scan one optic (the incident energy) against a second, fixed energy-selecting optic (the crystal analyzer) while a point detector counts, rather than expose an area detector at one energy. That is a new Capability, deferred as a question (`TECH-1`); it forces no new device families beyond the loose [`EnergyAnalyzer`](model.md#new-loose-families).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the incident-energy maps, the per-Q energy scans, the analyzer alignment, and the counting times) are not written yet; they join as the deployment approaches the point where CORA drives IXS. Whether the technique enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); hard inelastic scattering is a new regime for the fleet (see [Open questions](questions.md) for the world-facts to confirm first).
diff --git a/docs/deployments/lcls-mfx/governance.md b/docs/deployments/lcls-mfx/governance.md
deleted file mode 100644
index c6a127c6271..00000000000
--- a/docs/deployments/lcls-mfx/governance.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Governance
-
-*Who would act at MFX and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
-
-MFX's principals are facility principals at the [SLAC Site](../slac/index.md), not beamline-local: the LCLS instrument-scientist and operator pool, and the LCLS safety-review body. Both are carried pending in the [site descriptor](../slac/index.md) until the LCLS structure is confirmed. CORA's role kernel (the five-role authorization model) is facility-invariant, so MFX inherits it; what MFX adds to think about is two hazard gates the storage-ring exercises do not have.
-
-## The pump-probe laser Clearance
-
-MFX runs a class-4 optical laser for pump-probe, governed at LCLS by the Beam Transport Protection System (BTPS). CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture 32-ID takes for its additive-manufacturing laser. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family (the 4-ID precedent), while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
-
-## The PPS permit
-
-As at every beamline, beam-on work in an enclosure is gated by the facility personnel protection system (PPS). The LCLS PPS search-and-secure permit signals are not in `pcdshub` and are carried pending (PSS-1). MFX's enclosure structure (a shared front-end / transport zone plus the MFX experiment hutch) is itself carried `confirm` because the `pcdshub` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
-
-## What is not modelled
-
-- **Trust instantiation.** No scenario instantiates MFX trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded.
-- **The DAQ and analysis software as principals.** The LCLS DAQ, `psana`, and the bluesky-based scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
-
-People and agents are facility principals at the [SLAC Site](../slac/index.md); see [Open questions](questions.md) for the governance items still to confirm.
diff --git a/docs/deployments/lcls-mfx/model.md b/docs/deployments/lcls-mfx/model.md
deleted file mode 100644
index f10a38529cb..00000000000
--- a/docs/deployments/lcls-mfx/model.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's LCLS-MFX content lives, how the device families fold while the gaps stay architectural, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at LCLS-MFX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## The headline: the families fold, the gaps are architectural
-
-I03 graduated a device Family (Goniometer). MFX coined exactly one new family and reused everything else, and that is the finding. Of MFX's full device set, one type had no CORA Family, the von Hamos emission spectrometer; it introduced `EmissionSpectrometer`, which has since GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting (SPEC-1). Everything else reuses an existing Family: the offset mirrors fold into `Mirror`, the solid-Si attenuators into `Filter`, the JAWS into `Slit`, the pulse picker into `Shutter` (PULSE-1), the profile imagers into `Scintillator` + `Camera`, the intensity-position monitors into `FluxMonitor` + `Diagnostic`, the channel-cut into `Monochromator`, the lens stacks into the graduated `Transfocator` catalog Family, the EventSequencer into `TimingController`, the pump-probe laser into the catalog `Laser` Family (the 4-ID precedent), and the area detector into `Camera`. Each fold was reviewed against coining a synonym and rejected.
-
-So the device taxonomy generalizes from storage rings to an XFEL almost untouched. What does not generalize is the **acquisition ontology**. That is the product of this exercise, recorded next.
-
-## Deliberately not here yet (the architectural gap register)
-
-These are the parts of MFX this scaffold leaves out on purpose. Unlike the open questions (facts the LCLS team owns), each of these is a CORA scope decision: a shape the model does not yet have, with the seam it would extend named. None is built speculatively; an XFEL is the trigger that would justify the work.
-
-- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The load-bearing gap. CORA's acquisition is a single-detector poll-to-Done loop (`apps/api/src/cora/operation/acquisitions.py`) plus a sub-Hz scalar observation logbook with no pulse-ID key (`apps/api/src/cora/run/aggregates/run/entries.py`). An XFEL collects a free-running stream of per-shot frames correlated by fiducial at beam rate. The Run-as-provenance-envelope survives and the per-shot data plane lives in `psana` (CORA references a `Dataset`, as it does for reconstructions via `ComputePort`), but representing a DAQ run as an actuation is a new event-stream axis. Its shape is sketched as a forward-looking design note in CORA's design memory (gated, not built).
-- **Beam-synchronous event-code timing (TIMING-1).** The EventSequencer plays a sequence of `[beam_code, delta_beam, delta_fiducial, burst_count]` lines that gate acquisition at beam rate. CORA's `TimingController` Family carries the device, but "acquire on event-code N at rate R, burst B" has no typed parameter home; today it would be opaque setpoints.
-- **Femtosecond pump-probe synchronization (LASER-1).** The optical laser and the FEL are two synchronized timing domains (the `lxt_ttc` SyncAxis holds a ~50 fs deadband; the timetool corrects residual jitter). CORA's `PartitionRule` is single-domain spatial math; a cross-timing-domain synchronization is a relationship it cannot express. The laser device itself folds (catalog `Laser`, 4-ID precedent); the sync is the gap.
-- **One switched FEL source feeding co-equal instruments (TOPO-1).** One linac and undulator line serve many instruments, beam routed one at a time by the transport mirrors. CORA models each beamline as a root Unit owning its source; a shared, switched source feeding co-equal Units has no home except the `Supply("PhotonBeam")` seam, and the routing state ("which instrument has beam now") is new.
-- **Attenuator transmission solver (ATT-1).** The solid-Si attenuators solve a foil combination for a requested transmission, energy-dependent (the `AttBase` solver). CORA's `Filter` covers the discrete selection; the solve is the deferred `Attenuable` + `SolverReference` leg (`apps/api/src/cora/operation/_partition_rule_eval.py` defers SolverReference evaluation). MFX, with the same focus solver on the `Transfocator` lens stacks, is the rule-of-three trigger.
-- **Computed device-state to path-transmission lightpath (LIGHTPATH-1).** `pcdshub`'s `lightpath` walks the z-ordered beam path and computes path-level transmission and the first blocking device from each device's inserted / removed state. CORA already has the static z-ordered walk and the location-not-identity discipline; only the dynamic computed half is deferred (the passive-beam-path tier). `lightpath/path.py` is a ready precedent.
-
-## What is deliberately not here yet (modelling, as at the other exercises)
-
-- **New Capabilities / Methods and vendor Models.** MFX earns no catalog change; the XFEL recipes are carried pending on the [SLAC Practices](../slac/index.md). No catalog Model is bound.
-- **The von Hamos as a graduated Family.** `EmissionSpectrometer` GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting (its Johann + von Hamos XES / HERFD spectrometers); MAX IV Balder (SCANIA-2D) is a third near-sighting. The residual open question is whether each analyzer crystal is a child Asset (SPEC-1).
-- **Sample delivery and the Subject custody thread.** The liquid jet / fixed target is endstation-specific and deferred (SAMPLE-1); no Family is coined.
-- **Integration scenarios.** No `test_lcls_mfx_*.py` registers MFX Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
diff --git a/docs/deployments/lcls-mfx/notes.md b/docs/deployments/lcls-mfx/notes.md
new file mode 100644
index 00000000000..f158cb7f0aa
--- /dev/null
+++ b/docs/deployments/lcls-mfx/notes.md
@@ -0,0 +1,136 @@
+# Notes
+
+## Techniques
+
+*What MFX is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
+
+MFX runs three technique families, none of which fits the catalog's tomography Methods, so each is carried pending on the [SLAC Practices](../slac/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
+
+### Serial femtosecond crystallography (SFX)
+
+A stream of microcrystals is delivered into the focused FEL beam (liquid jet or fixed target); each X-ray pulse destroys its crystal but records a diffraction pattern first ("diffraction before destruction"). The dataset is millions of single-shot patterns, indexed and merged downstream.
+
+- **Spine shape:** a `serial_crystallography` Method binding the focusing lenses, the sample delivery, the pulse picker, and the area detector, over a Run that is a free-running per-shot acquisition rather than a trajectory of points.
+- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). This is the technique that most exposes the acquisition-ontology gap: there is no trajectory to walk, only a shot stream to tag and reference.
+
+### Femtosecond optical pump-probe
+
+An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves dynamics in time.
+
+- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis) while acquiring per-shot, with the timetool correcting residual jitter shot by shot.
+- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `lxt_ttc` SyncAxis).
+
+### X-ray emission spectroscopy (XES / HERFD)
+
+The von Hamos 6-crystal spectrometer disperses the X-ray fluorescence emitted by the sample onto a 2D detector, resolving emission energy; in HERFD mode the incident energy is scanned at a fixed emission line.
+
+- **Spine shape:** an `xas_spectroscopy` Method binding the emission spectrometer and, for HERFD, the incident-energy choreography (the DCCM), over a per-shot acquisition.
+- **Gap it leans on:** the emission spectrometer binds the `EmissionSpectrometer` family it introduced, since graduated once ISS earned the 2nd sighting (SPEC-1 now tracks only the analyzer-crystal composition), and HERFD's incident-energy scan reuses the energy-change choreography CORA already models well.
+
+### Why none is in the catalog yet
+
+The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL shares none of them: there is no rotation, no flat / dark frame pairing, no storage-ring energy ramp. Coining XFEL Methods now, before the acquisition axis they depend on exists, would be inventing recipes for a spine that cannot yet run them. So each is carried pending, naming the Method it would earn, and the deepest dependency (the event-stream acquisition axis, DAQ-1) is sketched as a design note rather than built. See [Model](#model) for the gap register.
+
+## Governance
+
+*Who would act at MFX and the trust shape that gates their commands. Design-phase: the principals are facility-level and carried pending.*
+
+MFX's principals are facility principals at the [SLAC Site](../slac/index.md), not beamline-local: the LCLS instrument-scientist and operator pool, and the LCLS safety-review body. Both are carried pending in the [site descriptor](../slac/index.md) until the LCLS structure is confirmed. CORA's role kernel (the five-role authorization model) is facility-invariant, so MFX inherits it; what MFX adds to think about is two hazard gates the storage-ring exercises do not have.
+
+### The pump-probe laser Clearance
+
+MFX runs a class-4 optical laser for pump-probe, governed at LCLS by the Beam Transport Protection System (BTPS). CORA carries this as a `Clearance` hazard on the experiment (a facility-issued safety permit that must be Active before laser-on work), the same posture 32-ID takes for its additive-manufacturing laser. This is distinct from whether the laser is a driven Asset: the device folds into the catalog `Laser` Family (the 4-ID precedent), while the personnel-safety permit is a Clearance. The two coexist (LASER-1).
+
+### The PPS permit
+
+As at every beamline, beam-on work in an enclosure is gated by the facility personnel protection system (PPS). The LCLS PPS search-and-secure permit signals are not in `pcdshub` and are carried pending (PSS-1). MFX's enclosure structure (a shared front-end / transport zone plus the MFX experiment hutch) is itself carried `confirm` because the `pcdshub` PV prefixes encode beamline-line zones, not access-gated hutches (ENC-1).
+
+### What is not modelled
+
+- **Trust instantiation.** No scenario instantiates MFX trust zones or actors; this is a design-phase modelling exercise, so the governance shape is described, not seeded.
+- **The DAQ and analysis software as principals.** The LCLS DAQ, `psana`, and the bluesky-based scan suite are control-system software on the floor, not CORA actors (see [Controls](controls.md)). When the per-shot acquisition axis is designed (DAQ-1), the question of which principal authorizes a DAQ run is part of that work.
+
+People and agents are facility principals at the [SLAC Site](../slac/index.md); see [Open questions](#open-questions) for the governance items still to confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's LCLS-MFX content lives, how the device families fold while the gaps stay architectural, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at LCLS-MFX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### The headline: the families fold, the gaps are architectural
+
+I03 graduated a device Family (Goniometer). MFX coined exactly one new family and reused everything else, and that is the finding. Of MFX's full device set, one type had no CORA Family, the von Hamos emission spectrometer; it introduced `EmissionSpectrometer`, which has since GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting (SPEC-1). Everything else reuses an existing Family: the offset mirrors fold into `Mirror`, the solid-Si attenuators into `Filter`, the JAWS into `Slit`, the pulse picker into `Shutter` (PULSE-1), the profile imagers into `Scintillator` + `Camera`, the intensity-position monitors into `FluxMonitor` + `Diagnostic`, the channel-cut into `Monochromator`, the lens stacks into the graduated `Transfocator` catalog Family, the EventSequencer into `TimingController`, the pump-probe laser into the catalog `Laser` Family (the 4-ID precedent), and the area detector into `Camera`. Each fold was reviewed against coining a synonym and rejected.
+
+So the device taxonomy generalizes from storage rings to an XFEL almost untouched. What does not generalize is the **acquisition ontology**. That is the product of this exercise, recorded next.
+
+### Deliberately not here yet (the architectural gap register)
+
+These are the parts of MFX this scaffold leaves out on purpose. Unlike the open questions (facts the LCLS team owns), each of these is a CORA scope decision: a shape the model does not yet have, with the seam it would extend named. None is built speculatively; an XFEL is the trigger that would justify the work.
+
+- **Per-shot, pulse-ID-tagged event DAQ (DAQ-1).** The load-bearing gap. CORA's acquisition is a single-detector poll-to-Done loop (`apps/api/src/cora/operation/acquisitions.py`) plus a sub-Hz scalar observation logbook with no pulse-ID key (`apps/api/src/cora/run/aggregates/run/entries.py`). An XFEL collects a free-running stream of per-shot frames correlated by fiducial at beam rate. The Run-as-provenance-envelope survives and the per-shot data plane lives in `psana` (CORA references a `Dataset`, as it does for reconstructions via `ComputePort`), but representing a DAQ run as an actuation is a new event-stream axis. Its shape is sketched as a forward-looking design note in CORA's design memory (gated, not built).
+- **Beam-synchronous event-code timing (TIMING-1).** The EventSequencer plays a sequence of `[beam_code, delta_beam, delta_fiducial, burst_count]` lines that gate acquisition at beam rate. CORA's `TimingController` Family carries the device, but "acquire on event-code N at rate R, burst B" has no typed parameter home; today it would be opaque setpoints.
+- **Femtosecond pump-probe synchronization (LASER-1).** The optical laser and the FEL are two synchronized timing domains (the `lxt_ttc` SyncAxis holds a ~50 fs deadband; the timetool corrects residual jitter). CORA's `PartitionRule` is single-domain spatial math; a cross-timing-domain synchronization is a relationship it cannot express. The laser device itself folds (catalog `Laser`, 4-ID precedent); the sync is the gap.
+- **One switched FEL source feeding co-equal instruments (TOPO-1).** One linac and undulator line serve many instruments, beam routed one at a time by the transport mirrors. CORA models each beamline as a root Unit owning its source; a shared, switched source feeding co-equal Units has no home except the `Supply("PhotonBeam")` seam, and the routing state ("which instrument has beam now") is new.
+- **Attenuator transmission solver (ATT-1).** The solid-Si attenuators solve a foil combination for a requested transmission, energy-dependent (the `AttBase` solver). CORA's `Filter` covers the discrete selection; the solve is the deferred `Attenuable` + `SolverReference` leg (`apps/api/src/cora/operation/_partition_rule_eval.py` defers SolverReference evaluation). MFX, with the same focus solver on the `Transfocator` lens stacks, is the rule-of-three trigger.
+- **Computed device-state to path-transmission lightpath (LIGHTPATH-1).** `pcdshub`'s `lightpath` walks the z-ordered beam path and computes path-level transmission and the first blocking device from each device's inserted / removed state. CORA already has the static z-ordered walk and the location-not-identity discipline; only the dynamic computed half is deferred (the passive-beam-path tier). `lightpath/path.py` is a ready precedent.
+
+### What is deliberately not here yet (modelling, as at the other exercises)
+
+- **New Capabilities / Methods and vendor Models.** MFX earns no catalog change; the XFEL recipes are carried pending on the [SLAC Practices](../slac/index.md). No catalog Model is bound.
+- **The von Hamos as a graduated Family.** `EmissionSpectrometer` GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting (its Johann + von Hamos XES / HERFD spectrometers); MAX IV Balder (SCANIA-2D) is a third near-sighting. The residual open question is whether each analyzer crystal is a child Asset (SPEC-1).
+- **Sample delivery and the Subject custody thread.** The liquid jet / fixed target is endstation-specific and deferred (SAMPLE-1); no Family is coined.
+- **Integration scenarios.** No `test_lcls_mfx_*.py` registers MFX Assets. Hard-registering a design-phase, off-roadmap, XFEL beamline would commit speculative structure.
+
+## Open questions
+
+*What CORA needs the LCLS team (and SLAC's documentation) to confirm before the model can be trusted.*
+
+MFX is modelled from SLAC's open [`pcdshub`](https://github.com/pcdshub) stack, treated as a dry, correct DATA source: the `happi` device database ([`device_config/db.json`](https://github.com/pcdshub/device_config)), the worked hutch config ([`mfx/beamline.py`](https://github.com/pcdshub/mfx)), the [`lightpath`](https://github.com/pcdshub/lightpath) beam-walk engine, and `pcdsdevices`. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the calibrated numbers, the PPS safety structure, the undulator specifics, or the Capability / Method binding. This page collects what `pcdshub` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+As at the Diamond exercises, the EPICS PV prefix for every device is already recorded in the descriptor, so wiring handles is not a question here. The questions concentrate on the one thing the storage-ring exercises never reached: the XFEL acquisition paradigm.
+
+### Scope, topology, and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCOPE-1 | Nice-to-have | Is MFX (or any LCLS instrument) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: MFX tests the XFEL acquisition paradigm; it is not on the pilot roadmap. | Whether SLAC is a real Site or a modelling fixture. |
+| TOPO-1 | Blocks-build | One linac and undulator line feed many co-equal instruments (CXI/XPP/XCS/MEC/MFX, plus the LCLS-II soft-X-ray instruments), beam routed to one at a time. Should each instrument be its own root Unit sharing an upstream source, and where does the shared switched source live? | One `LCLS-MFX` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
+| PSS-1 | Blocks-build | What are the LCLS PPS search-and-secure permit signals, and the BTPS interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `pcdshub` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
+| ENC-1 | Blocks-build | Which enclosure does each device sit in? `pcdshub` prefixes encode beamline-line zones (FEE, XRT, HFX, MFX:DG1/DG2/DIA), not the access-gated hutch or its safety meaning. | The shared front-end / transport zone plus the MFX experiment hutch. | The per-device Enclosure assignment. |
+
+### Source, optics, and attenuation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-build | What are the HXR undulator line parameters and the per-shot photon-energy mechanism (vernier vs undulator), and is the beam SASE or self-seeded? `pcdshub` carries the device handles, not the source curve. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
+| MACHINE-1 | Nice-to-have | LCLS is a linac, not a storage ring, so the loose `StorageRing` family used by the synchrotron exercises does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via a `FluxMonitor` gas detector. | The linac machine-state modelling boundary. |
+| ATT-1 | Blocks-go-live | The solid-Si attenuators select a foil combination for a requested transmission (energy-dependent, the `AttBase` solver). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg, and MFX is its rule-of-three trigger. | Whether the transmission solver is built and where. |
+| MONO-1 | Nice-to-have | The diamond double-channel-cut mono (DCCM) is used for some modes; MFX also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCCM internals and the pink-vs-mono mode model. |
+
+### Acquisition and timing (the architectural core)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DAQ-1 | Blocks-build | The LCLS DAQ records a free-running stream of per-shot frames tagged by pulse-ID / fiducial at beam rate (120 Hz to ~1 MHz), correlated downstream by pulse-ID. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in `psana`, and CORA references a `Dataset`, exactly as it does for reconstructions via `ComputePort`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. | Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for MFX. |
+| TIMING-1 | Blocks-go-live | The EventSequencer plays a beam-synchronous sequence (each line `[beam_code, delta_beam, delta_fiducial, burst_count]`) to gate acquisition. CORA's `TimingController` carries the device but has no typed home for an event-code sequence. Where does the sequence parameter live? | `TimingController` for the device; the event-code sequence is carried as opaque setpoints until a typed parameter shape is earned. | The event-code-sequence parameter model. |
+| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `lxt_ttc` SyncAxis, ~50 fs deadband) and timetool jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (the 4-ID precedent, model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
+| LIGHTPATH-1 | Nice-to-have | `lightpath` computes path-level transmission and the first blocking device from each device's inserted / removed state along the z-walk. CORA has the static z-ordered walk and location-not-identity, but not the dynamic device-state-to-path-transmission computation (the passive-beam-path tier defers the beam effect). Should it graduate? | The static walk is modelled; the dynamic computed transmission is deferred under the passive-beam-path tier; `lightpath/path.py` is the precedent. | Whether the computed lightpath beam-effect is built. |
+
+### Diagnostics, sample, and detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (IPM), the gas detector, the Wave8, and the timetool modelled? They present the Sensor Role; the gas detector is a `BeamStats` PV, not a happi device. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from I22 / 2-BM; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
+| SAMPLE-1 | Blocks-go-live | What is the sample-delivery shape (liquid jet, fixed target), and the `Subject` custody lifecycle for serial crystallography? | Sample delivery is endstation-specific and deferred; no Family is coined yet; the `Subject` thread is carried as this question. | The sample-delivery model and the `Subject` custody thread. |
+| SPEC-1 | Nice-to-have | The von Hamos 6-crystal spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector along a dispersive geometry. The Family question is resolved: `EmissionSpectrometer` GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting. The residual question is whether each of the six analyzer crystals is a child Asset or a setting on the one spectrometer Asset. | The six analyzer crystals carried as settings on the one `EmissionSpectrometer` Asset for now; child-Asset-per-crystal deferred. | The analyzer-crystal composition (child-Asset vs setting). |
+| DET-1 | Blocks-go-live | What is the MFX area detector (Rayonix MX340-XFEL, ePix10k, Jungfrau), and its threshold / geometry? `pcdshub` manages it through the DAQ, not as a polled happi device. | The detector reuses `Camera`; per-shot frames flow through the DAQ data plane (DAQ-1); the model and calibration are to supply. | The detector model and how its per-shot frames are referenced. |
+| PULSE-1 | Nice-to-have | The pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/lcls-mfx/questions.md b/docs/deployments/lcls-mfx/questions.md
deleted file mode 100644
index 64f4b8a5d11..00000000000
--- a/docs/deployments/lcls-mfx/questions.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Open questions
-
-*What CORA needs the LCLS team (and SLAC's documentation) to confirm before the model can be trusted.*
-
-MFX is modelled from SLAC's open [`pcdshub`](https://github.com/pcdshub) stack, treated as a dry, correct DATA source: the `happi` device database ([`device_config/db.json`](https://github.com/pcdshub/device_config)), the worked hutch config ([`mfx/beamline.py`](https://github.com/pcdshub/mfx)), the [`lightpath`](https://github.com/pcdshub/lightpath) beam-walk engine, and `pcdsdevices`. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the calibrated numbers, the PPS safety structure, the undulator specifics, or the Capability / Method binding. This page collects what `pcdshub` cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-As at the Diamond exercises, the EPICS PV prefix for every device is already recorded in the descriptor, so wiring handles is not a question here. The questions concentrate on the one thing the storage-ring exercises never reached: the XFEL acquisition paradigm.
-
-## Scope, topology, and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCOPE-1 | Nice-to-have | Is MFX (or any LCLS instrument) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? | A generalization exercise: MFX tests the XFEL acquisition paradigm; it is not on the pilot roadmap. | Whether SLAC is a real Site or a modelling fixture. |
-| TOPO-1 | Blocks-build | One linac and undulator line feed many co-equal instruments (CXI/XPP/XCS/MEC/MFX, plus the LCLS-II soft-X-ray instruments), beam routed to one at a time. Should each instrument be its own root Unit sharing an upstream source, and where does the shared switched source live? | One `LCLS-MFX` root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The `Supply("PhotonBeam")` seam is the candidate home. | One-vs-many root Units and where the shared source and its routing state are modelled. |
-| PSS-1 | Blocks-build | What are the LCLS PPS search-and-secure permit signals, and the BTPS interlock for the pump-probe laser? | Both enclosures exist with permit signals to be named; `pcdshub` does not carry them. | The Enclosure permit signals and the laser-safety interlock. |
-| ENC-1 | Blocks-build | Which enclosure does each device sit in? `pcdshub` prefixes encode beamline-line zones (FEE, XRT, HFX, MFX:DG1/DG2/DIA), not the access-gated hutch or its safety meaning. | The shared front-end / transport zone plus the MFX experiment hutch. | The per-device Enclosure assignment. |
-
-## Source, optics, and attenuation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-build | What are the HXR undulator line parameters and the per-shot photon-energy mechanism (vernier vs undulator), and is the beam SASE or self-seeded? `pcdshub` carries the device handles, not the source curve. | A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred. | The `Undulator` parameters and the per-shot energy mechanism. |
-| MACHINE-1 | Nice-to-have | LCLS is a linac, not a storage ring, so the loose `StorageRing` family used by the synchrotron exercises does not fit. How should machine beam be modelled? | A `PhotonBeam` Supply, not a `StorageRing` device; the per-shot pulse energy is read via a `FluxMonitor` gas detector. | The linac machine-state modelling boundary. |
-| ATT-1 | Blocks-go-live | The solid-Si attenuators select a foil combination for a requested transmission (energy-dependent, the `AttBase` solver). CORA's `Filter` covers the discrete selection but not the solve. Should the deferred `Attenuable` + `SolverReference` leg graduate? | `Filter` for the discrete selection; the target-transmission solver is the deferred `Attenuable` leg, and MFX is its rule-of-three trigger. | Whether the transmission solver is built and where. |
-| MONO-1 | Nice-to-have | The diamond double-channel-cut mono (DCCM) is used for some modes; MFX also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary? | A `Monochromator` Asset, used in some modes; mode and crystal details are settings to supply. | The DCCM internals and the pink-vs-mono mode model. |
-
-## Acquisition and timing (the architectural core)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DAQ-1 | Blocks-build | The LCLS DAQ records a free-running stream of per-shot frames tagged by pulse-ID / fiducial at beam rate (120 Hz to ~1 MHz), correlated downstream by pulse-ID. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. How does CORA represent a DAQ run? | The Run-as-provenance-envelope is kept; the per-shot data plane lives in `psana`, and CORA references a `Dataset`, exactly as it does for reconstructions via `ComputePort`. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built. | Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for MFX. |
-| TIMING-1 | Blocks-go-live | The EventSequencer plays a beam-synchronous sequence (each line `[beam_code, delta_beam, delta_fiducial, burst_count]`) to gate acquisition. CORA's `TimingController` carries the device but has no typed home for an event-code sequence. Where does the sequence parameter live? | `TimingController` for the device; the event-code sequence is carried as opaque setpoints until a typed parameter shape is earned. | The event-code-sequence parameter model. |
-| LASER-1 | Blocks-go-live | The fs pump-probe needs laser-to-X-ray synchronization (the `lxt_ttc` SyncAxis, ~50 fs deadband) and timetool jitter correction. CORA's `PartitionRule` is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard? | The laser is carried as a catalog `Laser` Family device (the 4-ID precedent, model-vs-hazard open); the delay stage is a `LinearStage`; the fs synchronization has no CORA model. | The pump-probe synchronization model and the laser's model-vs-hazard status. |
-| LIGHTPATH-1 | Nice-to-have | `lightpath` computes path-level transmission and the first blocking device from each device's inserted / removed state along the z-walk. CORA has the static z-ordered walk and location-not-identity, but not the dynamic device-state-to-path-transmission computation (the passive-beam-path tier defers the beam effect). Should it graduate? | The static walk is modelled; the dynamic computed transmission is deferred under the passive-beam-path tier; `lightpath/path.py` is the precedent. | Whether the computed lightpath beam-effect is built. |
-
-## Diagnostics, sample, and detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIAG-1 | Blocks-go-live | How are the intensity-position monitors (IPM), the gas detector, the Wave8, and the timetool modelled? They present the Sensor Role; the gas detector is a `BeamStats` PV, not a happi device. | The loose `FluxMonitor` and `Diagnostic` Sensor families reused from I22 / 2-BM; per-shot intensity normalization is a DAQ-plane concern (DAQ-1). | The diagnostics modelling boundary. |
-| SAMPLE-1 | Blocks-go-live | What is the sample-delivery shape (liquid jet, fixed target), and the `Subject` custody lifecycle for serial crystallography? | Sample delivery is endstation-specific and deferred; no Family is coined yet; the `Subject` thread is carried as this question. | The sample-delivery model and the `Subject` custody thread. |
-| SPEC-1 | Nice-to-have | The von Hamos 6-crystal spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector along a dispersive geometry. The Family question is resolved: `EmissionSpectrometer` GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting. The residual question is whether each of the six analyzer crystals is a child Asset or a setting on the one spectrometer Asset. | The six analyzer crystals carried as settings on the one `EmissionSpectrometer` Asset for now; child-Asset-per-crystal deferred. | The analyzer-crystal composition (child-Asset vs setting). |
-| DET-1 | Blocks-go-live | What is the MFX area detector (Rayonix MX340-XFEL, ePix10k, Jungfrau), and its threshold / geometry? `pcdshub` manages it through the DAQ, not as a polled happi device. | The detector reuses `Camera`; per-shot frames flow through the DAQ data plane (DAQ-1); the model and calibration are to supply. | The detector model and how its per-shot frames are referenced. |
-| PULSE-1 | Nice-to-have | The pulse picker is a fast single-pulse selector folded into `Shutter`. Is a rotary pulse-picking chopper a distinct Family (the loose `Chopper` shape)? | `Shutter` Role; the Shutter-vs-Chopper distinction is carried as this question. | Whether the pulse picker earns its own Family. |
diff --git a/docs/deployments/lcls-mfx/techniques.md b/docs/deployments/lcls-mfx/techniques.md
deleted file mode 100644
index b191db959bf..00000000000
--- a/docs/deployments/lcls-mfx/techniques.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Techniques
-
-*What MFX is designed to do, as design intent. Design-phase: these are Methods CORA would earn, not Methods it has.*
-
-MFX runs three technique families, none of which fits the catalog's tomography Methods, so each is carried pending on the [SLAC Practices](../slac/index.md) until it is earned. They are listed here as design intent, with the shape each would take over the spine and the gap each leans on.
-
-## Serial femtosecond crystallography (SFX)
-
-A stream of microcrystals is delivered into the focused FEL beam (liquid jet or fixed target); each X-ray pulse destroys its crystal but records a diffraction pattern first ("diffraction before destruction"). The dataset is millions of single-shot patterns, indexed and merged downstream.
-
-- **Spine shape:** a `serial_crystallography` Method binding the focusing lenses, the sample delivery, the pulse picker, and the area detector, over a Run that is a free-running per-shot acquisition rather than a trajectory of points.
-- **Gap it leans on:** the per-shot, pulse-ID-tagged event DAQ (DAQ-1). This is the technique that most exposes the acquisition-ontology gap: there is no trajectory to walk, only a shot stream to tag and reference.
-
-## Femtosecond optical pump-probe
-
-An optical laser pulse excites the sample a controlled femtoseconds before (or after) the X-ray probe pulse; scanning the delay resolves dynamics in time.
-
-- **Spine shape:** a `pump_probe` Method that scans the laser-to-X-ray delay (a `LinearStage` delay axis) while acquiring per-shot, with the timetool correcting residual jitter shot by shot.
-- **Gap it leans on:** the cross-timing-domain synchronization (LASER-1). The delay axis itself is a positioner; what CORA cannot express is the femtosecond synchronization between the optical-laser and FEL timing domains (the `lxt_ttc` SyncAxis).
-
-## X-ray emission spectroscopy (XES / HERFD)
-
-The von Hamos 6-crystal spectrometer disperses the X-ray fluorescence emitted by the sample onto a 2D detector, resolving emission energy; in HERFD mode the incident energy is scanned at a fixed emission line.
-
-- **Spine shape:** an `xas_spectroscopy` Method binding the emission spectrometer and, for HERFD, the incident-energy choreography (the DCCM), over a per-shot acquisition.
-- **Gap it leans on:** the emission spectrometer binds the `EmissionSpectrometer` family it introduced, since graduated once ISS earned the 2nd sighting (SPEC-1 now tracks only the analyzer-crystal composition), and HERFD's incident-energy scan reuses the energy-change choreography CORA already models well.
-
-## Why none is in the catalog yet
-
-The catalog's Methods are all tomography-family (`tomography`, `dark_field`, `flat_field`, the alignment and energy-change methods). An XFEL shares none of them: there is no rotation, no flat / dark frame pairing, no storage-ring energy ramp. Coining XFEL Methods now, before the acquisition axis they depend on exists, would be inventing recipes for a spine that cannot yet run them. So each is carried pending, naming the Method it would earn, and the deepest dependency (the event-stream acquisition axis, DAQ-1) is sketched as a design note rather than built. See [Model](model.md) for the gap register.
diff --git a/docs/deployments/lix/governance.md b/docs/deployments/lix/governance.md
deleted file mode 100644
index c85602738e1..00000000000
--- a/docs/deployments/lix/governance.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Governance
-
-*Who will act at LIX, and the trust shape that will gate it. First cut.*
-
-Governance at LIX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-LIX is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection's access model is a POSIX-ACL `login` keyed to a proposal id, not a facility role roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
-
-## The safety boundary
-
-The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are largely absent from the beamline's profile collection (only the photon-shutter enable status is present), so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-LIX adds the hazard classes that come with its instruments, and one that is distinctive: a wet, biological sample environment. Those land with the equipment and the samples that bring them, and an experiment Clearance would carry them.
-
-| Hazard class | Where it lands | Tracking |
-| --- | --- | --- |
-| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:16IDA / B / C) (`ENC-1`) | (`PSS-1`) |
-| Vacuum optics and the SAXS flight path | the [Source](source.md) walk and the detector translations | (`SUP-1`) |
-| Biological samples, buffers, and pressurized fluidics | the [Sample](sample.md) delivery chain (the HPLC pump, the buffers, the flow cell) | (`FLUID-1`, `SEC-1`) |
-
-The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The vacuum extent and the cooling supply that the optics and flight path depend on are carried pending (`SUP-1`). The biological-sample and pressurized-fluidics hazards are distinctive to a life-science solution beamline and travel with the delivery chain and the Subject; they are carried pending against the fluidic questions, not invented (`FLUID-1`, `SEC-1`).
-
-## When the shape lands
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives LIX, following the [2-BM governance](../2-bm/governance.md) shape. Because LIX shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The one new wrinkle is the fluidic delivery chain: a Conduit would have to bind the HPLC cart's heterogeneous surfaces (the soft-IOC, the Moxa sockets) as command surfaces alongside EPICS, the same multi-transport Conduit shape the [MX3](../mx3/governance.md) deployment first surfaced. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
diff --git a/docs/deployments/lix/model.md b/docs/deployments/lix/model.md
deleted file mode 100644
index b22ad3a950f..00000000000
--- a/docs/deployments/lix/model.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's LIX content lives, how it models a solution beamline's fluidic delivery without inventing device vocabulary, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at LIX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes LIX new
-
-The honest answer is: not the detector, and one real thing on the sample side. LIX measures biological structure by small- and wide-angle X-ray scattering (bio-SAXS / WAXS), in-line size-exclusion-chromatography-coupled scattering (SEC-SAXS), and scanning-microbeam mapping. The scattering hardware overlaps the fleet heavily: LIX shares its science axis and its `Camera` / `FluxMonitor` / `BeamStop` vocabulary with the materials-scattering beamlines SMI, CMS, I22, and 9-ID, and contributes reinforcement there, not novelty.
-
-LIX's genuinely distinct contributions are above the detector and beside the sample:
-
-- **The solution Subject.** The fleet's first life-science solution-scattering beamline measures a buffer-borne macromolecule, often an eluting chromatographic peak, rather than a solid mount. That is a new Subject shape, with its own provenance, not a new device (`SUBJECT-1`).
-- **The fluidic sample-delivery chain.** An HPLC delivery pump, selector valves, a size-exclusion column, buffers, and a flow cell move the sample into the beam in lockstep with the exposure. It is the fleet's first fluidic delivery plane, and it is heterogeneous (a Moxa terminal server, the Agilent OpenLAB .NET SDK, a pcaspy soft-IOC), the MX3 non-EPICS shape extended to fluidics (`FLUID-1`).
-- **The SEC-SAXS Procedure.** The run is a flow program correlated to the chromatographic elution, a Procedure over the seam plus a Subject / Supply shape, not a device (`FLUID-1`, `SEC-1`).
-
-## No new families
-
-LIX coins no new Family and changes nothing in the catalog.
-
-- **16-ID is an undulator beamline** (unlike the bending-magnet CMS), so it carries an `InsertionDevice` on the spine; the machine state is also observed through the loose `StorageRing`, and the undulator detail is `SRC-1`.
-- **The DCM binds `Monochromator`** (a silicon double-crystal optic, the energy law implies Si(111)); the incident energy is a `PseudoAxis` over its Bragg angle and the undulator gap.
-- **The optics and detectors all reuse:** the white-beam and KB mirrors bind `Mirror`; the slits bind `Slit`; the compound refractive lens binds the graduated `Transfocator`; the shutters bind `Shutter`; the solution positioning stack binds the graduated `Manipulator`; the scanning goniometer binds `Goniometer`; the Pilatus detectors bind `Camera`; the Xspress3 binds the graduated `EnergyDispersiveSpectrometer`; the detector translations bind `LinearStage`; the beamstop binds `BeamStop`; the TetrAMM electrometers bind `FluxMonitor`; the diamond-diode / Best beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux, `DIAG-1`); the Zebra binds `TimingController`.
-
-## The graduated FlowController Family
-
-The one reuse worth spelling out is the HPLC delivery pump. Its CORA-facing anatomy is a settable flow / pump actuator presenting `Regulator`: a flowrate setpoint and readback, a pressure readback, and run / stop. That is exactly the graduated catalog `FlowController` Family, the continuous-setpoint flow / pump actuator that presents `Regulator` and is the settable-actuator sibling of `TemperatureController`. So the pump **reuses** the graduated `FlowController`; it coins nothing.
-
-`FlowController` graduated into the catalog on the rule-of-three across Diamond i22, APS 7-BM, NSLS-II LIX, and NSLS-II XFP, the same way `TemperatureController`, `FluxMonitor`, and `EmissionSpectrometer` did: presenting the existing `Regulator` Role, so a YAML-and-docs change with no new Role or affordance. LIX is one of the four consumers that earned the graduation, and it now simply **binds the catalog `FlowController` Family (graduated; presents `Regulator`)**. The wider fluidic chain stays deferred (`FLUID-1`, `FLOW-1`).
-
-## How the fluidic chain is modelled (mostly not a device)
-
-The fluidic delivery chain is the novel axis, and only one piece of it is a device:
-
-- the **delivery pump** is the `DeliveryPump`, binding the graduated `FlowController` (above);
-- the **selector valves** (VICI column / purge / detector, the Aurora buffer valve) are the ControlPort **seam**: discrete N-position routers over Moxa TCP sockets, with no existing Family, conducted over the seam and not coined at n=1 (`FLUID-1`);
-- the **SEC column and buffers** are **Supply** consumables (`SEC-1`);
-- the **flow cell** is sample environment, living in an external library (lixtools), not a catalog device here (`SEC-1`, `FLUID-1`);
-- the **sample robot and autosampler** are a **Procedure** over the spine plus a **Subject** custody thread, the i03 / MX3 robot precedent, not a device Family (`ROBOT-1`);
-- the **solution sample / eluting peak** is a **Subject** (`SUBJECT-1`).
-
-This is the CORA-lens decision for a solution beamline: the experiment's identity lives in the Subject (which protein, which peak), the Supply (which column, which buffers), and the Procedure (the flow program), with the pump and valves as actuators conducted over the seam. Coining `Pump` and `Valve` device Families at n=1 would mint federation vocabulary one deployment cannot earn alone; the pump reuses the graduated `FlowController` Family instead, and the valves stay in the seam pending a second fluidic beamline (`FLUID-1`).
-
-## Deliberately not here yet
-
-- **The selector-valve Family (`FLUID-1`).** The VICI and Aurora valves are discrete-position routers with no existing Family. Per earn-the-abstraction they are carried in the seam at n=1, no `Valve` / `SelectorValve` Family coined; a second fluidic beamline would earn the abstraction.
-- **The disabled attenuator and the deferred temperature controllers.** The `Fltr:Attn` attenuator and its lookup tables are commented out in the profile collection, so no attenuator is modelled, not invented (`ATTN-1`). The sample-cell temperature controllers (the FTC100D and the SMC chiller) have their module-level instances commented out, though a solution mode instantiates an FTC100D, so this is a scope deferral; the autosampler tray temperature (`SAMPLER:TEMP`) is folded into the same deferral (`TEMP-1`).
-- **The Methods.** Whether `solution_scattering` and the scanning Method enter CORA's catalog is an owner decision; the Practices render unlinked, pending. `solution_scattering` is new and `scanning_fluorescence_microscopy` is reused pending (`TECH-1`).
-- **The multi-mode endstation rebinding.** The solution, scanning, and vacuum-scan modes rebind the logical sample axes across physical PVs and controllers (EPICS, XPS trajectory, SmarAct) at startup; CORA models the logical stacks and carries the active binding as a setting (`SAMPLE-1`, `SCAN-1`), not as separate Assets.
-- **The third Pilatus, the Kinetix, and the viewing cameras.** The 300K WAXS1 head is disabled, the Xspress3 is optional, and the Kinetix and Prosilica cameras are not modelled in this cut (`DET-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_lix_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/lix/notes.md b/docs/deployments/lix/notes.md
new file mode 100644
index 00000000000..e9be0004dce
--- /dev/null
+++ b/docs/deployments/lix/notes.md
@@ -0,0 +1,180 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of LIX is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. LIX measures biological structure three ways: biological solution scattering (bio-SAXS / WAXS), in-line size-exclusion-chromatography-coupled scattering (SEC-SAXS), and scanning-microbeam mapping of cells and tissue. The Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings any of them into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Biological solution scattering (bio-SAXS / WAXS) | `solution_scattering` | small- and wide-angle scattering from a protein in solution in the [flow cell](sample.md), read on the [SAXS Pilatus 1M](detector.md); the fleet's first solution-scattering Method, new to the catalog (`TECH-1`) |
+| In-line SEC-SAXS | `solution_scattering` | the [HPLC delivery pump](sample.md) flows an eluting size-exclusion peak through the cell while the SAXS detector reads; the same `solution_scattering` Method with the chromatographic elution as the acquisition axis (`TECH-1`, `FLUID-1`) |
+| Scanning-microbeam mapping | `scanning_fluorescence_microscopy` | raster the microbeam across a cell or tissue section on the [scanning goniometer](sample.md), reading scattering and fluorescence per point; reuses the existing pending Method (`TECH-1`) |
+
+All three techniques need the [incident-beam chain](source.md) (the undulator and DCM for energy, the mirrors and transfocator for focus, the slits), the [sample side](sample.md) (the positioning stack or scanning goniometer, and for the solution modes the fluidic delivery chain), and the [endstation detectors](detector.md) (the Pilatus heads, beamstop, flux monitors).
+
+### Where the novelty is: the Subject, not the Method
+
+LIX's measurement, small- and wide-angle X-ray scattering, is a science axis the fleet already speaks. The materials-scattering beamlines [SMI](../smi/notes.md#techniques), [CMS](../cms/notes.md#techniques), Diamond [I22](../i22/notes.md#techniques), and APS [9-ID](../9-id/notes.md#techniques) / [12-ID](../12-id/notes.md#techniques) all run small- and wide-angle scattering on the same `Camera` / `FluxMonitor` / `BeamStop` vocabulary. So the scattering hardware and detection are reinforcement, not novelty.
+
+What LIX adds is a new **Subject** and a new **sample-delivery** shape, not a new detector. The specimen is a protein in solution rather than a solid mount, and for SEC-SAXS it is an eluting chromatographic peak whose elution profile is the acquisition axis. That is why `solution_scattering` is proposed as a Method distinct from the materials `small_angle_scattering`: not because the optics differ, but because the Subject and the acquisition (a flowing, time-resolved liquid correlated to chromatography) differ. Whether the catalog ultimately holds one scattering Capability with solution-versus-solid as a Practice adaptation, or a distinct `solution_scattering` Capability, is the owner-scope decision (`TECH-1`); LIX records the case, it does not mint the vocabulary.
+
+The matching Site Practices (`LIX_solution_scattering_practice`, `LIX_sec_saxs_practice`, `LIX_microbeam_scanning_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
+
+### SEC-SAXS is a Procedure over the fluidic seam
+
+In-line SEC-SAXS is the technique that most exercises the fluidic delivery chain, and CORA models it as a **Procedure**, not a new device. The run equilibrates the size-exclusion column, injects the sample, and reads SAXS frames continuously while the peak elutes through the [flow cell](sample.md). The actuators it drives, the [HPLC delivery pump](sample.md) (the graduated `FlowController`) and the selector valves (the seam), are conducted over the `ControlPort`; the [column and buffers](sample.md) are Supply; the eluting peak is a Subject; the frames correlated to the elution are the Dataset. The technique's identity in CORA's record lives in the Subject, Supply, and Procedure, not in a device or a new detector (`FLUID-1`, `SEC-1`, `SUBJECT-1`).
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet. For solution scattering that is the per-frame exposures, the buffer-subtraction sequence, and the azimuthal integration that turns 2D frames into I(Q) curves (the integration and reduction are `ComputePort` work, not beamline Methods). For SEC-SAXS it is the column-equilibration and injection steps, the flow program, and the peak-fraction model that maps frames to elution. For the scanning mode it is the raster trajectory and the per-point reduction. These join as the deployment approaches the point where CORA drives LIX.
+
+Whether any of these techniques enters CORA's catalog is an owner-scope decision on [Model](#model): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at LIX, and the trust shape that will gate it. First cut.*
+
+Governance at LIX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+LIX is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. The profile collection's access model is a POSIX-ACL `login` keyed to a proposal id, not a facility role roster, so the NSLS-II operator pool and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), shared with the rest of the fleet (`GOV-1`).
+
+### The safety boundary
+
+The safety tier is the other piece that is not yet settled. The PSS search-and-secure permit signals and the front-end and photon shutters are largely absent from the beamline's profile collection (only the photon-shutter enable status is present), so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+LIX adds the hazard classes that come with its instruments, and one that is distinctive: a wet, biological sample environment. Those land with the equipment and the samples that bring them, and an experiment Clearance would carry them.
+
+| Hazard class | Where it lands | Tracking |
+| --- | --- | --- |
+| Hard X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (XF:16IDA / B / C) (`ENC-1`) | (`PSS-1`) |
+| Vacuum optics and the SAXS flight path | the [Source](source.md) walk and the detector translations | (`SUP-1`) |
+| Biological samples, buffers, and pressurized fluidics | the [Sample](sample.md) delivery chain (the HPLC pump, the buffers, the flow cell) | (`FLUID-1`, `SEC-1`) |
+
+The hard X-ray beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The vacuum extent and the cooling supply that the optics and flight path depend on are carried pending (`SUP-1`). The biological-sample and pressurized-fluidics hazards are distinctive to a life-science solution beamline and travel with the delivery chain and the Subject; they are carried pending against the fluidic questions, not invented (`FLUID-1`, `SEC-1`).
+
+### When the shape lands
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives LIX, following the [2-BM governance](../2-bm/governance.md) shape. Because LIX shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The one new wrinkle is the fluidic delivery chain: a Conduit would have to bind the HPLC cart's heterogeneous surfaces (the soft-IOC, the Moxa sockets) as command surfaces alongside EPICS, the same multi-transport Conduit shape the [MX3](../mx3/notes.md#governance) deployment first surfaced. The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's LIX content lives, how it models a solution beamline's fluidic delivery without inventing device vocabulary, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at LIX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes LIX new
+
+The honest answer is: not the detector, and one real thing on the sample side. LIX measures biological structure by small- and wide-angle X-ray scattering (bio-SAXS / WAXS), in-line size-exclusion-chromatography-coupled scattering (SEC-SAXS), and scanning-microbeam mapping. The scattering hardware overlaps the fleet heavily: LIX shares its science axis and its `Camera` / `FluxMonitor` / `BeamStop` vocabulary with the materials-scattering beamlines SMI, CMS, I22, and 9-ID, and contributes reinforcement there, not novelty.
+
+LIX's genuinely distinct contributions are above the detector and beside the sample:
+
+- **The solution Subject.** The fleet's first life-science solution-scattering beamline measures a buffer-borne macromolecule, often an eluting chromatographic peak, rather than a solid mount. That is a new Subject shape, with its own provenance, not a new device (`SUBJECT-1`).
+- **The fluidic sample-delivery chain.** An HPLC delivery pump, selector valves, a size-exclusion column, buffers, and a flow cell move the sample into the beam in lockstep with the exposure. It is the fleet's first fluidic delivery plane, and it is heterogeneous (a Moxa terminal server, the Agilent OpenLAB .NET SDK, a pcaspy soft-IOC), the MX3 non-EPICS shape extended to fluidics (`FLUID-1`).
+- **The SEC-SAXS Procedure.** The run is a flow program correlated to the chromatographic elution, a Procedure over the seam plus a Subject / Supply shape, not a device (`FLUID-1`, `SEC-1`).
+
+### No new families
+
+LIX coins no new Family and changes nothing in the catalog.
+
+- **16-ID is an undulator beamline** (unlike the bending-magnet CMS), so it carries an `InsertionDevice` on the spine; the machine state is also observed through the loose `StorageRing`, and the undulator detail is `SRC-1`.
+- **The DCM binds `Monochromator`** (a silicon double-crystal optic, the energy law implies Si(111)); the incident energy is a `PseudoAxis` over its Bragg angle and the undulator gap.
+- **The optics and detectors all reuse:** the white-beam and KB mirrors bind `Mirror`; the slits bind `Slit`; the compound refractive lens binds the graduated `Transfocator`; the shutters bind `Shutter`; the solution positioning stack binds the graduated `Manipulator`; the scanning goniometer binds `Goniometer`; the Pilatus detectors bind `Camera`; the Xspress3 binds the graduated `EnergyDispersiveSpectrometer`; the detector translations bind `LinearStage`; the beamstop binds `BeamStop`; the TetrAMM electrometers bind `FluxMonitor`; the diamond-diode / Best beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux, `DIAG-1`); the Zebra binds `TimingController`.
+
+### The graduated FlowController Family
+
+The one reuse worth spelling out is the HPLC delivery pump. Its CORA-facing anatomy is a settable flow / pump actuator presenting `Regulator`: a flowrate setpoint and readback, a pressure readback, and run / stop. That is exactly the graduated catalog `FlowController` Family, the continuous-setpoint flow / pump actuator that presents `Regulator` and is the settable-actuator sibling of `TemperatureController`. So the pump **reuses** the graduated `FlowController`; it coins nothing.
+
+`FlowController` graduated into the catalog on the rule-of-three across Diamond i22, APS 7-BM, NSLS-II LIX, and NSLS-II XFP, the same way `TemperatureController`, `FluxMonitor`, and `EmissionSpectrometer` did: presenting the existing `Regulator` Role, so a YAML-and-docs change with no new Role or affordance. LIX is one of the four consumers that earned the graduation, and it now simply **binds the catalog `FlowController` Family (graduated; presents `Regulator`)**. The wider fluidic chain stays deferred (`FLUID-1`, `FLOW-1`).
+
+### How the fluidic chain is modelled (mostly not a device)
+
+The fluidic delivery chain is the novel axis, and only one piece of it is a device:
+
+- the **delivery pump** is the `DeliveryPump`, binding the graduated `FlowController` (above);
+- the **selector valves** (VICI column / purge / detector, the Aurora buffer valve) are the ControlPort **seam**: discrete N-position routers over Moxa TCP sockets, with no existing Family, conducted over the seam and not coined at n=1 (`FLUID-1`);
+- the **SEC column and buffers** are **Supply** consumables (`SEC-1`);
+- the **flow cell** is sample environment, living in an external library (lixtools), not a catalog device here (`SEC-1`, `FLUID-1`);
+- the **sample robot and autosampler** are a **Procedure** over the spine plus a **Subject** custody thread, the i03 / MX3 robot precedent, not a device Family (`ROBOT-1`);
+- the **solution sample / eluting peak** is a **Subject** (`SUBJECT-1`).
+
+This is the CORA-lens decision for a solution beamline: the experiment's identity lives in the Subject (which protein, which peak), the Supply (which column, which buffers), and the Procedure (the flow program), with the pump and valves as actuators conducted over the seam. Coining `Pump` and `Valve` device Families at n=1 would mint federation vocabulary one deployment cannot earn alone; the pump reuses the graduated `FlowController` Family instead, and the valves stay in the seam pending a second fluidic beamline (`FLUID-1`).
+
+### Deliberately not here yet
+
+- **The selector-valve Family (`FLUID-1`).** The VICI and Aurora valves are discrete-position routers with no existing Family. Per earn-the-abstraction they are carried in the seam at n=1, no `Valve` / `SelectorValve` Family coined; a second fluidic beamline would earn the abstraction.
+- **The disabled attenuator and the deferred temperature controllers.** The `Fltr:Attn` attenuator and its lookup tables are commented out in the profile collection, so no attenuator is modelled, not invented (`ATTN-1`). The sample-cell temperature controllers (the FTC100D and the SMC chiller) have their module-level instances commented out, though a solution mode instantiates an FTC100D, so this is a scope deferral; the autosampler tray temperature (`SAMPLER:TEMP`) is folded into the same deferral (`TEMP-1`).
+- **The Methods.** Whether `solution_scattering` and the scanning Method enter CORA's catalog is an owner decision; the Practices render unlinked, pending. `solution_scattering` is new and `scanning_fluorescence_microscopy` is reused pending (`TECH-1`).
+- **The multi-mode endstation rebinding.** The solution, scanning, and vacuum-scan modes rebind the logical sample axes across physical PVs and controllers (EPICS, XPS trajectory, SmarAct) at startup; CORA models the logical stacks and carries the active binding as a setting (`SAMPLE-1`, `SCAN-1`), not as separate Assets.
+- **The third Pilatus, the Kinetix, and the viewing cameras.** The 300K WAXS1 head is disabled, the Xspress3 is optional, and the Kinetix and Prosilica cameras are not modelled in this cut (`DET-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_lix_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the LIX team to confirm before the model can be trusted.*
+
+LIX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/lix-profile-collection](https://github.com/NSLS2/lix-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the PV zones XF:16IDA (optics), XF:16IDB (transport), and XF:16IDC (endstation) three separate hutches? | Two enclosures: a `lix-optics` zone (folding A and B) and the `lix-endstation` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The in-vacuum undulator model, period, and length (the profile collection fits an empirical Keff(gap) curve, a 23 mm period implied, but names no device). | An `InsertionDevice` undulator, observed gap; parameters pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state LIX reads (current, fill, status); only the ring current PV is read for beam suspenders. | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The DCM crystal cut (the energy law implies Si(111)), the energy range, and the energy-partition rule coupling the Bragg angle to the undulator gap. | A double-crystal `Monochromator`; the energy is a `PseudoAxis` over the Bragg angle and the gap; the crystal cut pending. | The monochromator and incident-energy Assets. |
+| OPT-1 | Nice-to-have | The white-beam and KB mirror coatings, whether the KB pair is bimorph, and the bend mechanisms. | Focusing mirrors bound to `Mirror`; coatings and bend pending. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis roles of each slit (the mono slit, the secondary-source aperture, the endstation guard slit). | Four-blade and center / gap slits bound to `Slit`. | The slit Asset detail. |
+| CRL-1 | Nice-to-have | The compound refractive lens lens-group configuration (nine selectable groups, in / out per group) and the focal-length map. | A `Transfocator` reusing the graduated Family; the lens-group set carried as settings. | The transfocator Asset detail. |
+| ATTN-1 | Nice-to-have | Is an attenuator live (the `Fltr:Attn` motors and the `Attenuator` class are commented out in the profile collection)? | No attenuator modelled; not invented. | Whether an attenuator Asset exists. |
+
+### Sample and delivery
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The solution-mode positioning stack axes (the coarse x and z pusher are EPICS; the scan x / y are Newport-XPS trajectory axes), and how the flow cell mounts on it. | A `Manipulator` for the positioning stack; the flow cell is the fluidic seam. | The solution-stage modelling. |
+| SCAN-1 | Blocks-go-live | The scanning-microbeam goniometer axes (the SmarAct stack), the fast raster axes (the XPS scan.X / scan.Y trajectory), and the tomo rotation (the XPS rot.rY). | A `Goniometer` for the SmarAct stack; the XPS trajectory axes carried as the motion-controller seam. | The scanning-stage modelling. |
+| FLUID-1 | Blocks-go-live | The fluidic sample-delivery chain: the HPLC delivery pump (an Agilent quaternary pump over the .NET SDK plus a regeneration pump over a Moxa socket, fronted by the `XF:16IDC-ES{HPLC}` soft-IOC), the VICI and Aurora selector valves (Moxa TCP sockets, no EPICS), and whether the valve actuators earn a Family. | The pump binds the graduated catalog `FlowController` (presents Regulator; earned across i22 / 7-BM / LIX / XFP); the valves stay in the seam; no Valve Family coined. | The fluidic-delivery modelling; the CORA decisions are on [Model](#deliberately-not-here-yet). |
+| SEC-1 | Nice-to-have | The size-exclusion column types, the buffers, the needle wash, and the X-ray flow cell (the flow cell lives in an external library, lixtools). | The column and buffers are Supply consumables; the flow cell is sample environment, not a device. | The consumable / flow-cell modelling. |
+| ROBOT-1 | Nice-to-have | The sample-handling robot (the `SW:` method soft-IOC, task-verb-driven) and the Agilent autosampler, and whether they earn a Family. | Modelled as a Procedure over the spine and a Subject custody thread, the i03 / MX3 robot precedent; no `SampleExchanger` Family coined. | The sample-handling modelling. |
+| SUBJECT-1 | Nice-to-have | The solution Subject: a buffer-borne macromolecule or an eluting SEC peak, with its own provenance, distinct from a solid mount. | A liquid Subject; the chromatographic peak as the acquisition axis for SEC-SAXS. | The Subject modelling. |
+| TEMP-1 | Nice-to-have | The sample-cell temperature control (the FTC100D and SMC chiller module-level instances are commented out, though a solution mode instantiates an FTC100D; plus the autosampler tray temperature SAMPLER:TEMP). | No temperature-controller device modelled in this cut; the in-situ environment pending. | The temperature-environment modelling. |
+
+### Detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The SAXS / WAXS Pilatus detector models and sizes (a 1M SAXS, a 900K WAXS; a 300K WAXS1 is disabled), the Xspress3 per-run availability (initialized in a try / except), the detector-distance calibrations, and the flux / beam-position channel map. | Two `Camera` Assets (Pilatus 1M SAXS, 900K WAXS); the Xspress3 binds `EnergyDispersiveSpectrometer`; the monitors bind `FluxMonitor` and the graduated catalog `PositionMonitor`. | The detector modelling. |
+| DIAG-1 | Nice-to-have | The beam-position monitor: the Best aggregator deriving x / y from the TetrAMM quadrant currents, and the position-versus-intensity channel split. The Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | The graduated catalog `PositionMonitor`, earned across the wide fleet that shares it; the per-Asset channel split is the residual. | The beam-position channel split. |
+| TRIG-1 | Blocks-go-live | The exposure triggering: the Zebra soft-input pulse and position capture, gated from the Newport XPS, and the fast-shutter TTL. | A `TimingController` (the Zebra); the fast shutter a `Shutter` on the timing seam. | The triggering modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the data plane Kafka plus Redis plus a custom packing queue (no Tiled, no queueserver in the profile collection)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals, the front-end and photon shutters (only the photon-shutter enable status is in the profile collection; the security model there is a POSIX-ACL login). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the optics, the SAXS flight path) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Do the solution-scattering and scanning techniques (bio-SAXS / WAXS, SEC-SAXS, microbeam mapping) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; `solution_scattering` is new and `scanning_fluorescence_microscopy` is reused pending; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/lix/questions.md b/docs/deployments/lix/questions.md
deleted file mode 100644
index a79aacb941a..00000000000
--- a/docs/deployments/lix/questions.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Open questions
-
-*What CORA needs the LIX team to confirm before the model can be trusted.*
-
-LIX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/lix-profile-collection](https://github.com/NSLS2/lix-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the PV zones XF:16IDA (optics), XF:16IDB (transport), and XF:16IDC (endstation) three separate hutches? | Two enclosures: a `lix-optics` zone (folding A and B) and the `lix-endstation` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The in-vacuum undulator model, period, and length (the profile collection fits an empirical Keff(gap) curve, a 23 mm period implied, but names no device). | An `InsertionDevice` undulator, observed gap; parameters pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state LIX reads (current, fill, status); only the ring current PV is read for beam suspenders. | Observe-only machine state, a loose `StorageRing`; the exact PVs pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The DCM crystal cut (the energy law implies Si(111)), the energy range, and the energy-partition rule coupling the Bragg angle to the undulator gap. | A double-crystal `Monochromator`; the energy is a `PseudoAxis` over the Bragg angle and the gap; the crystal cut pending. | The monochromator and incident-energy Assets. |
-| OPT-1 | Nice-to-have | The white-beam and KB mirror coatings, whether the KB pair is bimorph, and the bend mechanisms. | Focusing mirrors bound to `Mirror`; coatings and bend pending. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis roles of each slit (the mono slit, the secondary-source aperture, the endstation guard slit). | Four-blade and center / gap slits bound to `Slit`. | The slit Asset detail. |
-| CRL-1 | Nice-to-have | The compound refractive lens lens-group configuration (nine selectable groups, in / out per group) and the focal-length map. | A `Transfocator` reusing the graduated Family; the lens-group set carried as settings. | The transfocator Asset detail. |
-| ATTN-1 | Nice-to-have | Is an attenuator live (the `Fltr:Attn` motors and the `Attenuator` class are commented out in the profile collection)? | No attenuator modelled; not invented. | Whether an attenuator Asset exists. |
-
-## Sample and delivery
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The solution-mode positioning stack axes (the coarse x and z pusher are EPICS; the scan x / y are Newport-XPS trajectory axes), and how the flow cell mounts on it. | A `Manipulator` for the positioning stack; the flow cell is the fluidic seam. | The solution-stage modelling. |
-| SCAN-1 | Blocks-go-live | The scanning-microbeam goniometer axes (the SmarAct stack), the fast raster axes (the XPS scan.X / scan.Y trajectory), and the tomo rotation (the XPS rot.rY). | A `Goniometer` for the SmarAct stack; the XPS trajectory axes carried as the motion-controller seam. | The scanning-stage modelling. |
-| FLUID-1 | Blocks-go-live | The fluidic sample-delivery chain: the HPLC delivery pump (an Agilent quaternary pump over the .NET SDK plus a regeneration pump over a Moxa socket, fronted by the `XF:16IDC-ES{HPLC}` soft-IOC), the VICI and Aurora selector valves (Moxa TCP sockets, no EPICS), and whether the valve actuators earn a Family. | The pump binds the graduated catalog `FlowController` (presents Regulator; earned across i22 / 7-BM / LIX / XFP); the valves stay in the seam; no Valve Family coined. | The fluidic-delivery modelling; the CORA decisions are on [Model](model.md#deliberately-not-here-yet). |
-| SEC-1 | Nice-to-have | The size-exclusion column types, the buffers, the needle wash, and the X-ray flow cell (the flow cell lives in an external library, lixtools). | The column and buffers are Supply consumables; the flow cell is sample environment, not a device. | The consumable / flow-cell modelling. |
-| ROBOT-1 | Nice-to-have | The sample-handling robot (the `SW:` method soft-IOC, task-verb-driven) and the Agilent autosampler, and whether they earn a Family. | Modelled as a Procedure over the spine and a Subject custody thread, the i03 / MX3 robot precedent; no `SampleExchanger` Family coined. | The sample-handling modelling. |
-| SUBJECT-1 | Nice-to-have | The solution Subject: a buffer-borne macromolecule or an eluting SEC peak, with its own provenance, distinct from a solid mount. | A liquid Subject; the chromatographic peak as the acquisition axis for SEC-SAXS. | The Subject modelling. |
-| TEMP-1 | Nice-to-have | The sample-cell temperature control (the FTC100D and SMC chiller module-level instances are commented out, though a solution mode instantiates an FTC100D; plus the autosampler tray temperature SAMPLER:TEMP). | No temperature-controller device modelled in this cut; the in-situ environment pending. | The temperature-environment modelling. |
-
-## Detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The SAXS / WAXS Pilatus detector models and sizes (a 1M SAXS, a 900K WAXS; a 300K WAXS1 is disabled), the Xspress3 per-run availability (initialized in a try / except), the detector-distance calibrations, and the flux / beam-position channel map. | Two `Camera` Assets (Pilatus 1M SAXS, 900K WAXS); the Xspress3 binds `EnergyDispersiveSpectrometer`; the monitors bind `FluxMonitor` and the graduated catalog `PositionMonitor`. | The detector modelling. |
-| DIAG-1 | Nice-to-have | The beam-position monitor: the Best aggregator deriving x / y from the TetrAMM quadrant currents, and the position-versus-intensity channel split. The Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | The graduated catalog `PositionMonitor`, earned across the wide fleet that shares it; the per-Asset channel split is the residual. | The beam-position channel split. |
-| TRIG-1 | Blocks-go-live | The exposure triggering: the Zebra soft-input pulse and position capture, gated from the Newport XPS, and the fast-shutter TTL. | A `TimingController` (the Zebra); the fast shutter a `Shutter` on the timing seam. | The triggering modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the data plane Kafka plus Redis plus a custom packing queue (no Tiled, no queueserver in the profile collection)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals, the front-end and photon shutters (only the photon-shutter enable status is in the profile collection; the security model there is a POSIX-ACL login). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the optics, the SAXS flight path) and the cooling supply. | Photon beam, cooling water, and vacuum on the optics and flight path. | The Supply observations. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Do the solution-scattering and scanning techniques (bio-SAXS / WAXS, SEC-SAXS, microbeam mapping) enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices; `solution_scattering` is new and `scanning_fluorescence_microscopy` is reused pending; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/lix/techniques.md b/docs/deployments/lix/techniques.md
deleted file mode 100644
index 425886839e7..00000000000
--- a/docs/deployments/lix/techniques.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Techniques
-
-*What the modelled part of LIX is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. LIX measures biological structure three ways: biological solution scattering (bio-SAXS / WAXS), in-line size-exclusion-chromatography-coupled scattering (SEC-SAXS), and scanning-microbeam mapping of cells and tissue. The Methods below render unlinked and are carried pending until the owner-scope decision (`TECH-1`) brings any of them into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Biological solution scattering (bio-SAXS / WAXS) | `solution_scattering` | small- and wide-angle scattering from a protein in solution in the [flow cell](sample.md), read on the [SAXS Pilatus 1M](detector.md); the fleet's first solution-scattering Method, new to the catalog (`TECH-1`) |
-| In-line SEC-SAXS | `solution_scattering` | the [HPLC delivery pump](sample.md) flows an eluting size-exclusion peak through the cell while the SAXS detector reads; the same `solution_scattering` Method with the chromatographic elution as the acquisition axis (`TECH-1`, `FLUID-1`) |
-| Scanning-microbeam mapping | `scanning_fluorescence_microscopy` | raster the microbeam across a cell or tissue section on the [scanning goniometer](sample.md), reading scattering and fluorescence per point; reuses the existing pending Method (`TECH-1`) |
-
-All three techniques need the [incident-beam chain](source.md) (the undulator and DCM for energy, the mirrors and transfocator for focus, the slits), the [sample side](sample.md) (the positioning stack or scanning goniometer, and for the solution modes the fluidic delivery chain), and the [endstation detectors](detector.md) (the Pilatus heads, beamstop, flux monitors).
-
-## Where the novelty is: the Subject, not the Method
-
-LIX's measurement, small- and wide-angle X-ray scattering, is a science axis the fleet already speaks. The materials-scattering beamlines [SMI](../smi/techniques.md), [CMS](../cms/techniques.md), Diamond [I22](../i22/techniques.md), and APS [9-ID](../9-id/techniques.md) / [12-ID](../12-id/techniques.md) all run small- and wide-angle scattering on the same `Camera` / `FluxMonitor` / `BeamStop` vocabulary. So the scattering hardware and detection are reinforcement, not novelty.
-
-What LIX adds is a new **Subject** and a new **sample-delivery** shape, not a new detector. The specimen is a protein in solution rather than a solid mount, and for SEC-SAXS it is an eluting chromatographic peak whose elution profile is the acquisition axis. That is why `solution_scattering` is proposed as a Method distinct from the materials `small_angle_scattering`: not because the optics differ, but because the Subject and the acquisition (a flowing, time-resolved liquid correlated to chromatography) differ. Whether the catalog ultimately holds one scattering Capability with solution-versus-solid as a Practice adaptation, or a distinct `solution_scattering` Capability, is the owner-scope decision (`TECH-1`); LIX records the case, it does not mint the vocabulary.
-
-The matching Site Practices (`LIX_solution_scattering_practice`, `LIX_sec_saxs_practice`, `LIX_microbeam_scanning_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
-
-## SEC-SAXS is a Procedure over the fluidic seam
-
-In-line SEC-SAXS is the technique that most exercises the fluidic delivery chain, and CORA models it as a **Procedure**, not a new device. The run equilibrates the size-exclusion column, injects the sample, and reads SAXS frames continuously while the peak elutes through the [flow cell](sample.md). The actuators it drives, the [HPLC delivery pump](sample.md) (the graduated `FlowController`) and the selector valves (the seam), are conducted over the `ControlPort`; the [column and buffers](sample.md) are Supply; the eluting peak is a Subject; the frames correlated to the elution are the Dataset. The technique's identity in CORA's record lives in the Subject, Supply, and Procedure, not in a device or a new detector (`FLUID-1`, `SEC-1`, `SUBJECT-1`).
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet. For solution scattering that is the per-frame exposures, the buffer-subtraction sequence, and the azimuthal integration that turns 2D frames into I(Q) curves (the integration and reduction are `ComputePort` work, not beamline Methods). For SEC-SAXS it is the column-equilibration and injection steps, the flow program, and the peak-fraction model that maps frames to elution. For the scanning mode it is the raster trajectory and the per-point reduction. These join as the deployment approaches the point where CORA drives LIX.
-
-Whether any of these techniques enters CORA's catalog is an owner-scope decision on [Model](model.md): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/manaca/governance.md b/docs/deployments/manaca/governance.md
deleted file mode 100644
index b2364f8717a..00000000000
--- a/docs/deployments/manaca/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at MANACA, and the trust shape that will gate it. First cut.*
-
-Governance at MANACA follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Sirius Site](../sirius/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-MANACA is Sirius's first MX beamline but not CORA's first Sirius deployment (the [MOGNO](../mogno/index.md) tomography scaffold precedes it): the operator pool and the safety-review structure are carried pending on the [Sirius Site](../sirius/index.md#safety-and-governance), shared across the facility's beamlines, until LNLS staff confirm them (`GOV-1`). MANACA is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives MANACA, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. LNLS publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Sirius Site](../sirius/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-MANACA also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop is modelled as a Procedure with a Subject thread (`ROBOT-1`), not as an Asset CORA drives for safety.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives MANACA, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/manaca/model.md b/docs/deployments/manaca/model.md
deleted file mode 100644
index 887985ee60a..00000000000
--- a/docs/deployments/manaca/model.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's MANACA content lives, its place as Sirius's first MX beamline, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at MANACA |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes MANACA new
-
-MANACA is a new beamline at an existing Site, and nothing new at the vocabulary level. It is **Sirius's first macromolecular-crystallography beamline**, CORA's second modelled Sirius beamline after the [MOGNO](../mogno/index.md) tomography scaffold. Its science is macromolecular crystallography (serial and room-temperature) at 5-20 keV: rotation MX on a goniometer reading an area detector, with an automated 48-pin sample changer. The control plane is the Sirius EPICS device floor with MXCuBE3 / MXCuBE Web as the MX experiment UI; Bluesky / Ophyd (the LNLS sophys family) is named as a facility orchestration direction, the same migration question MOGNO records (`ORCH-1`).
-
-## No new families (the MX spine reuses the i03 / FMX / AMX / MX3 precedent)
-
-MANACA coins no new Family. The goniometer binds the graduated `Goniometer`; the monochromator binds `Monochromator` and the energy is a `PseudoAxis`; the attenuators bind `Filter`; the cryostream binds the graduated `TemperatureController`; the beamstop binds `BeamStop`; the area detector and the on-axis camera bind `Camera`, the detector stage `LinearStage`, the flux monitor the graduated `FluxMonitor`; the shutters bind `Shutter`; the machine state binds the supply-loose `StorageRing`, and the sample backlight the catalog `Backlight` (graduated across the MX / imaging fleet, `DET-1`). Nothing in the catalog changes. The automated 48-pin sample changer is a deferred sample-exchange Procedure, not a device family (the i03 / i24 / MX3 `ROBOT-1` precedent).
-
-## The control plane
-
-MANACA sits on the Sirius EPICS device floor with MXCuBE3 / MXCuBE Web as the MX experiment UI driving the goniometer, the detector, and the sample changer. Sirius has named Bluesky / Ophyd (the LNLS sophys family: a RunEngine fronted by bluesky-queueserver and bluesky-httpserver) as a facility orchestration direction, and the MOGNO scaffold records the same migration question (`ORCH-1`); whether MANACA runs it today is not public. LNLS publishes its control software openly but no per-beamline PV manifest, so CORA does not bind the EPICS / MXCuBE handles here; when bound they would be modelled as opaque edge strings over the `ControlPort` (`CTRL-1`). The rotation-MX acquisition runs through MXCuBE and the beamline orchestration layer; that orchestration is the seam CORA's edge replaces or drives through, conducting over the EPICS floor rather than owning it. The detector file-writing to the Sirius data store is plumbing CORA observes, not data it owns.
-
-## Deliberately not here yet
-
-- **The control handles (`CTRL-1`).** No public per-beamline EPICS / MXCuBE manifest exists; the handles are carried pending, not invented.
-- **The detector model (`DET-1`).** The area detector is bound to `Camera` but its model (a Pilatus / Eiger-class photon-counting detector) is unpublished, carried pending.
-- **The sample-exchange Procedure (`ROBOT-1`).** The automated 48-pin changer is named as a deferred Procedure, not built, following the established MX robot precedent.
-- **The exact optics and goniometer detail (`MONO-1`, `ENERGY-1`, `FILT-1`, `OPT-1`, `GONIO-1`).** The monochromator crystal, the energy axis, the attenuators, the mirrors / slits, and the goniometer axes are carried confirm-pending.
-- **The MX Methods (`TECH-1`, `ROBOT-1`).** Whether rotation MX, grid scan, and sample exchange enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the i03 slugs.
-- **The simulated devices and full asset-tree scenarios.** No `test_manaca_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/manaca/notes.md b/docs/deployments/manaca/notes.md
new file mode 100644
index 00000000000..006149706e6
--- /dev/null
+++ b/docs/deployments/manaca/notes.md
@@ -0,0 +1,133 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of MANACA is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../sirius/index.md#the-techniques-adapted-here) is how a facility adapts it. MANACA runs macromolecular crystallography, reusing the same cross-facility MX Methods Diamond i03 introduced, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`, `ROBOT-1`).
+
+### Macromolecular crystallography
+
+MANACA sets the X-ray energy (5-20 keV) with the undulator and the monochromator, mounts a crystal on the goniometer (from the automated 48-pin sample changer), and rotates it through an oscillation while the area detector reads frames. It supports serial and room-temperature MX in addition to standard cryocooled rotation collection.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the [goniometer](sample.md) reading the [area detector](detector.md); reuses the i03 Method (also at FMX / AMX / MX3), not yet in the catalog (`TECH-1`) |
+| Grid scan | `grid_scan` | fast grid scan for sample location and centring on the [goniometer](sample.md); reuses the i03 Method; pending (`TECH-1`) |
+| Sample exchange | `sample_exchange` | the automated 48-pin changer load / centre / collect / unmount loop, modelled as a Procedure over the spine; reuses the i03 / MX3 Method; pending (`ROBOT-1`) |
+
+Rotation MX needs the [incident energy](source.md) set by the [monochromator](source.md), the [goniometer and cryostream](sample.md), and the [area detector](detector.md). Serial and room-temperature MX reuse the same chain with the sample-delivery and environment varied.
+
+### A new beamline on familiar vocabulary
+
+MANACA is a further macromolecular-crystallography beamline after Diamond i03, NSLS-II FMX / AMX, and the Australian Synchrotron MX3, and Sirius's first MX beamline (its [MOGNO](../mogno/index.md) sibling is tomography). It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, driven here through the Sirius EPICS floor and MXCuBE3. It reuses the `mx_data_collection`, `grid_scan`, and `sample_exchange` Methods directly (all carried pending across the MX fleet); none forces a new device family, and the 48-pin sample changer is a Procedure, not a new device.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the oscillation sequences and their exposures, the grid-scan centring, the sample-changer custody loop, the serial / room-temperature delivery) are not written yet; they join as the deployment approaches the point where CORA drives MANACA. Whether the MX Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at MANACA, and the trust shape that will gate it. First cut.*
+
+Governance at MANACA follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Sirius Site](../sirius/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+MANACA is Sirius's first MX beamline but not CORA's first Sirius deployment (the [MOGNO](../mogno/index.md) tomography scaffold precedes it): the operator pool and the safety-review structure are carried pending on the [Sirius Site](../sirius/index.md#safety-and-governance), shared across the facility's beamlines, until LNLS staff confirm them (`GOV-1`). MANACA is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives MANACA, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. LNLS publishes no per-beamline personnel-safety permit signals or photon / front-end shutters, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Sirius Site](../sirius/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+MANACA also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop is modelled as a Procedure with a Subject thread (`ROBOT-1`), not as an Asset CORA drives for safety.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives MANACA, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's MANACA content lives, its place as Sirius's first MX beamline, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at MANACA |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes MANACA new
+
+MANACA is a new beamline at an existing Site, and nothing new at the vocabulary level. It is **Sirius's first macromolecular-crystallography beamline**, CORA's second modelled Sirius beamline after the [MOGNO](../mogno/index.md) tomography scaffold. Its science is macromolecular crystallography (serial and room-temperature) at 5-20 keV: rotation MX on a goniometer reading an area detector, with an automated 48-pin sample changer. The control plane is the Sirius EPICS device floor with MXCuBE3 / MXCuBE Web as the MX experiment UI; Bluesky / Ophyd (the LNLS sophys family) is named as a facility orchestration direction, the same migration question MOGNO records (`ORCH-1`).
+
+### No new families (the MX spine reuses the i03 / FMX / AMX / MX3 precedent)
+
+MANACA coins no new Family. The goniometer binds the graduated `Goniometer`; the monochromator binds `Monochromator` and the energy is a `PseudoAxis`; the attenuators bind `Filter`; the cryostream binds the graduated `TemperatureController`; the beamstop binds `BeamStop`; the area detector and the on-axis camera bind `Camera`, the detector stage `LinearStage`, the flux monitor the graduated `FluxMonitor`; the shutters bind `Shutter`; the machine state binds the supply-loose `StorageRing`, and the sample backlight the catalog `Backlight` (graduated across the MX / imaging fleet, `DET-1`). Nothing in the catalog changes. The automated 48-pin sample changer is a deferred sample-exchange Procedure, not a device family (the i03 / i24 / MX3 `ROBOT-1` precedent).
+
+### The control plane
+
+MANACA sits on the Sirius EPICS device floor with MXCuBE3 / MXCuBE Web as the MX experiment UI driving the goniometer, the detector, and the sample changer. Sirius has named Bluesky / Ophyd (the LNLS sophys family: a RunEngine fronted by bluesky-queueserver and bluesky-httpserver) as a facility orchestration direction, and the MOGNO scaffold records the same migration question (`ORCH-1`); whether MANACA runs it today is not public. LNLS publishes its control software openly but no per-beamline PV manifest, so CORA does not bind the EPICS / MXCuBE handles here; when bound they would be modelled as opaque edge strings over the `ControlPort` (`CTRL-1`). The rotation-MX acquisition runs through MXCuBE and the beamline orchestration layer; that orchestration is the seam CORA's edge replaces or drives through, conducting over the EPICS floor rather than owning it. The detector file-writing to the Sirius data store is plumbing CORA observes, not data it owns.
+
+### Deliberately not here yet
+
+- **The control handles (`CTRL-1`).** No public per-beamline EPICS / MXCuBE manifest exists; the handles are carried pending, not invented.
+- **The detector model (`DET-1`).** The area detector is bound to `Camera` but its model (a Pilatus / Eiger-class photon-counting detector) is unpublished, carried pending.
+- **The sample-exchange Procedure (`ROBOT-1`).** The automated 48-pin changer is named as a deferred Procedure, not built, following the established MX robot precedent.
+- **The exact optics and goniometer detail (`MONO-1`, `ENERGY-1`, `FILT-1`, `OPT-1`, `GONIO-1`).** The monochromator crystal, the energy axis, the attenuators, the mirrors / slits, and the goniometer axes are carried confirm-pending.
+- **The MX Methods (`TECH-1`, `ROBOT-1`).** Whether rotation MX, grid scan, and sample exchange enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the i03 slugs.
+- **The simulated devices and full asset-tree scenarios.** No `test_manaca_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the MANACA team to confirm before the model can be trusted.*
+
+MANACA was reverse-engineered from Sirius's public facility pages ([lnls.cnpem.br/facilities/manaca](https://lnls.cnpem.br/facilities/manaca/)) and a verified research brief, not from a live connection. LNLS publishes its control software (the Bluesky-based sophys family) openly, but no per-beamline EPICS PV manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. MANACA is Sirius's first macromolecular-crystallography beamline, CORA's second modelled Sirius beamline after the [MOGNO](../mogno/index.md) tomography scaffold. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics hutch feeding one experiment hutch, or a different layout? | A `manaca-optics` zone and a `manaca-experiment` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator source, 5-20 keV; period pending. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The Sirius storage-ring state MANACA reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The monochromator crystal / multilayer type and handles. | A monochromator bound to `Monochromator`; 5-20 keV. | The monochromator modelling. |
+| ENERGY-1 | Nice-to-have | Whether energy is scanned as the measurement (anomalous MX). | A master energy `PseudoAxis` the monochromator tracks. | The energy-axis modelling. |
+| FILT-1 | Nice-to-have | The attenuator / transmission foil set. | An attenuator unit bound to `Filter`. | The attenuator Asset detail. |
+| OPT-1 | Nice-to-have | The focusing mirrors and beam-defining slits (presence, handles). | No standalone mirror / slit device published; deferred. | The optics Asset detail. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The goniometer geometry: the rotation, centring, and alignment axes. | A `Goniometer` (the graduated i03 family); axis set pending. | The goniometer modelling. |
+| TEMP-1 | Nice-to-have | The cryostream sample-cooling sensor and setpoint handles. | A `TemperatureController` (the graduated family). | The temperature-control modelling. |
+| SAMPLE-1 | Nice-to-have | The beamstop axes and the sample-environment detail. | A `BeamStop` at the sample; axis set pending. | The sample-stage modelling. |
+| ROBOT-1 | Blocks-go-live | The automated 48-pin sample changer (load / centre / collect / unmount loop). | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family. | The sample-exchange modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The area-detector model (a Pilatus / Eiger-class photon-counting detector), its translation stage, and the on-axis camera. | A `Camera` plus a `LinearStage` and an on-axis `Camera`; model not published, carried pending. | The detector modelling. |
+| DIAG-1 | Nice-to-have | The incident-flux monitor handles. | A `FluxMonitor` (the graduated family). | The flux-monitor modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The EPICS PV and MXCuBE device handles per MANACA device (absent from any public per-beamline manifest). | The handles are unbound, carried pending; the control plane is the Sirius EPICS floor + MXCuBE3. | Binding each Asset's control handle. |
+| ORCH-1 | Nice-to-have | Does MANACA run the Bluesky / Ophyd (sophys) orchestration layer, or another scan engine under MXCuBE? | Bluesky / sophys is a named facility direction (as MOGNO records); the MANACA status is unconfirmed. | The orchestration-layer modelling. |
+| PSS-1 | Blocks-go-live | The Sirius personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
+| GOV-1 | Nice-to-have | The Sirius operator pool and safety-review structure (site-level). | Carried pending on the Sirius Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do rotation MX and grid scan enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the i03 `mx_data_collection` and `grid_scan` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/manaca/questions.md b/docs/deployments/manaca/questions.md
deleted file mode 100644
index a25b49f992a..00000000000
--- a/docs/deployments/manaca/questions.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Open questions
-
-*What CORA needs the MANACA team to confirm before the model can be trusted.*
-
-MANACA was reverse-engineered from Sirius's public facility pages ([lnls.cnpem.br/facilities/manaca](https://lnls.cnpem.br/facilities/manaca/)) and a verified research brief, not from a live connection. LNLS publishes its control software (the Bluesky-based sophys family) openly, but no per-beamline EPICS PV manifest, so the [device pages](index.md) carry a planned shape with control handles unbound. MANACA is Sirius's first macromolecular-crystallography beamline, CORA's second modelled Sirius beamline after the [MOGNO](../mogno/index.md) tomography scaffold. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a shared optics hutch feeding one experiment hutch, or a different layout? | A `manaca-optics` zone and a `manaca-experiment` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator source, 5-20 keV; period pending. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The Sirius storage-ring state MANACA reads. | Observe-only machine state, a loose `StorageRing`; exact handles pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The monochromator crystal / multilayer type and handles. | A monochromator bound to `Monochromator`; 5-20 keV. | The monochromator modelling. |
-| ENERGY-1 | Nice-to-have | Whether energy is scanned as the measurement (anomalous MX). | A master energy `PseudoAxis` the monochromator tracks. | The energy-axis modelling. |
-| FILT-1 | Nice-to-have | The attenuator / transmission foil set. | An attenuator unit bound to `Filter`. | The attenuator Asset detail. |
-| OPT-1 | Nice-to-have | The focusing mirrors and beam-defining slits (presence, handles). | No standalone mirror / slit device published; deferred. | The optics Asset detail. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The goniometer geometry: the rotation, centring, and alignment axes. | A `Goniometer` (the graduated i03 family); axis set pending. | The goniometer modelling. |
-| TEMP-1 | Nice-to-have | The cryostream sample-cooling sensor and setpoint handles. | A `TemperatureController` (the graduated family). | The temperature-control modelling. |
-| SAMPLE-1 | Nice-to-have | The beamstop axes and the sample-environment detail. | A `BeamStop` at the sample; axis set pending. | The sample-stage modelling. |
-| ROBOT-1 | Blocks-go-live | The automated 48-pin sample changer (load / centre / collect / unmount loop). | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family. | The sample-exchange modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The area-detector model (a Pilatus / Eiger-class photon-counting detector), its translation stage, and the on-axis camera. | A `Camera` plus a `LinearStage` and an on-axis `Camera`; model not published, carried pending. | The detector modelling. |
-| DIAG-1 | Nice-to-have | The incident-flux monitor handles. | A `FluxMonitor` (the graduated family). | The flux-monitor modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The EPICS PV and MXCuBE device handles per MANACA device (absent from any public per-beamline manifest). | The handles are unbound, carried pending; the control plane is the Sirius EPICS floor + MXCuBE3. | Binding each Asset's control handle. |
-| ORCH-1 | Nice-to-have | Does MANACA run the Bluesky / Ophyd (sophys) orchestration layer, or another scan engine under MXCuBE? | Bluesky / sophys is a named facility direction (as MOGNO records); the MANACA status is unconfirmed. | The orchestration-layer modelling. |
-| PSS-1 | Blocks-go-live | The Sirius personnel-safety permit signals and the photon / front-end shutters (not published per beamline). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
-| GOV-1 | Nice-to-have | The Sirius operator pool and safety-review structure (site-level). | Carried pending on the Sirius Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do rotation MX and grid scan enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the i03 `mx_data_collection` and `grid_scan` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/manaca/techniques.md b/docs/deployments/manaca/techniques.md
deleted file mode 100644
index ae757e77354..00000000000
--- a/docs/deployments/manaca/techniques.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Techniques
-
-*What the modelled part of MANACA is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../sirius/index.md#the-techniques-adapted-here) is how a facility adapts it. MANACA runs macromolecular crystallography, reusing the same cross-facility MX Methods Diamond i03 introduced, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`, `ROBOT-1`).
-
-## Macromolecular crystallography
-
-MANACA sets the X-ray energy (5-20 keV) with the undulator and the monochromator, mounts a crystal on the goniometer (from the automated 48-pin sample changer), and rotates it through an oscillation while the area detector reads frames. It supports serial and room-temperature MX in addition to standard cryocooled rotation collection.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the [goniometer](sample.md) reading the [area detector](detector.md); reuses the i03 Method (also at FMX / AMX / MX3), not yet in the catalog (`TECH-1`) |
-| Grid scan | `grid_scan` | fast grid scan for sample location and centring on the [goniometer](sample.md); reuses the i03 Method; pending (`TECH-1`) |
-| Sample exchange | `sample_exchange` | the automated 48-pin changer load / centre / collect / unmount loop, modelled as a Procedure over the spine; reuses the i03 / MX3 Method; pending (`ROBOT-1`) |
-
-Rotation MX needs the [incident energy](source.md) set by the [monochromator](source.md), the [goniometer and cryostream](sample.md), and the [area detector](detector.md). Serial and room-temperature MX reuse the same chain with the sample-delivery and environment varied.
-
-## A new beamline on familiar vocabulary
-
-MANACA is a further macromolecular-crystallography beamline after Diamond i03, NSLS-II FMX / AMX, and the Australian Synchrotron MX3, and Sirius's first MX beamline (its [MOGNO](../mogno/index.md) sibling is tomography). It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, driven here through the Sirius EPICS floor and MXCuBE3. It reuses the `mx_data_collection`, `grid_scan`, and `sample_exchange` Methods directly (all carried pending across the MX fleet); none forces a new device family, and the 48-pin sample changer is a Procedure, not a new device.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the oscillation sequences and their exposures, the grid-scan centring, the sample-changer custody loop, the serial / room-temperature delivery) are not written yet; they join as the deployment approaches the point where CORA drives MANACA. Whether the MX Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/mogno/governance.md b/docs/deployments/mogno/governance.md
deleted file mode 100644
index c309335d9ef..00000000000
--- a/docs/deployments/mogno/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at MOGNO, and the trust shape that will gate it. First cut.*
-
-Governance at MOGNO follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Sirius Site](../sirius/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-MOGNO is CORA's first Sirius deployment, so Sirius is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [Sirius Site](../sirius/index.md#safety-and-governance), shared across the facility's beamlines, until LNLS staff confirm them (`GOV-1`). MOGNO is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives MOGNO, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The Sirius personnel-safety permit signals and the photon and front-end shutters are not in any public source, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Sirius Site](../sirius/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-MOGNO carries the hazard classes that come with a tomography beamline: an intense X-ray beam (a quasi-monochromatic dipole source running up to ~68 keV), and the radiation-enclosure interlocks of the two experiment stations. Those land at the Site safety envelope; an experiment Clearance would carry the per-experiment authorization.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives MOGNO, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/mogno/model.md b/docs/deployments/mogno/model.md
deleted file mode 100644
index 1f73eacee2d..00000000000
--- a/docs/deployments/mogno/model.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's MOGNO content lives, the new Sirius Site and the compute axis named for reconstruction, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at MOGNO |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the cone-beam magnification `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes MOGNO new
-
-MOGNO is CORA's **eighth Site** (Sirius, the Brazilian Synchrotron Light Laboratory at CNPEM) and the fleet's **first South American facility**, the biggest re-test of the Site and Federation kernel a single deployment can be. Its science is cone-beam X-ray micro and nanotomography across two endstations, fed by a quasi-monochromatic dipole source at three working energies.
-
-It is also the thinnest reverse-engineered scaffold to date, by necessity. The NSLS-II and Diamond beamlines were built from public open-source controls libraries (bluesky profile collections, `dodal`), so their descriptors carry real EPICS PVs or device handles. MOGNO has no public controls configuration: its facts come from two papers and a facility page. So every device binds a catalog Family but carries no handle and no vendor Model; the handles are open questions, not read-from-config evidence.
-
-## No new families, no new method (reuse and reinforce)
-
-MOGNO coins nothing. It is the tomography spine landing on a third facility after the APS 2-BM pilot and NSLS-II FXI, and it reuses their vocabulary wholesale:
-
-- the rotation axes bind `RotaryStage` (the master clock for triggered acquisition);
-- the sample positioners (including the fine piezo "tripod") bind `LinearStage`, the axis set a per-Asset setting;
-- the focusing optics bind `Mirror`, the beam-defining slits bind `Slit`;
-- the detectors bind `Camera` and `Scintillator` (the indirect chain);
-- the cone-beam magnification binds `PseudoAxis` (the FXI Magnification precedent);
-- the TATU FPGA trigger binds `TimingController` (the 2-BM softGlueZynq / FXI Zebra precedent);
-- the machine state binds the loose `StorageRing`;
-- the `tomography` Method is reused, the practice carried pending (`TECH-1`).
-
-## The control seam: a custom EPICS application layer
-
-MOGNO is the fleet's first orchestration layer that is neither Bluesky nor BLISS nor Sardana. Its floor is EPICS IOCs plus a TATU FPGA trigger/timer (shared Sirius infrastructure, exposing EPICS PVs via the LNLS Nheengatu layer). Above that floor sits a beamline-owned custom PyEpics application stack: `mgn-devices` (device abstraction over PyEpics), `mgn-routines` (the alignment and tomogram acquisition routines), and `mgn-control-guis` (the PyQt/PyDM launchers). A tomogram is launched from a GUI dialog that runs the relevant `mgn-routines` script as a subprocess, driving the rotation stage, detector, and TATU trigger over EPICS.
-
-That custom routine layer is the orchestration CORA's edge would conduct over the EPICS floor, exactly as the 2-BM seam designates: CORA's EdgeConductor replaces the scan/alignment orchestration the `mgn-routines` perform today, conducting over the EPICS + TATU floor rather than replacing it. The beamline has named Bluesky/sophys (Ophyd devices, Bluesky plans) as a future migration target; whether it has migrated is an open question (`ORCH-1`). Modelling the seam against a custom stack, not Bluesky, is the point: it confirms the seam model does not assume a particular orchestration framework.
-
-## The compute axis: reconstruction named, not built
-
-MOGNO reconstructs on an HPC cluster. The beamline's reconstruction library is `ssc-raft` (CUDA, from the Sirius Scientific Computing group), submitted to the cluster over SSH from a FastAPI reconstruction service with a PyQt job-queue GUI; it has been the production reconstruction path since early 2024. This is a clean instance of CORA's compute axis (a `ComputePort` over a Method, no new BC): named here as reinforcement of the compute-modelling synthesis, not modelled as Assets in this cut. The cluster name, scheduler, and storage path are not confirmed from public sources (`COMPUTE-1`).
-
-## Deliberately not here yet
-
-- **The exact device handles and vendor models (`CTRL-1`, `STAGE-1`, `STAGE-2`, `STAGE-3`, `CAM-1`, `CAM-2`, `OPT-1`, `OPT-2`).** No public controls config exists; the PVs, controller boxes, and part numbers must come from staff. They carry no value here rather than a guessed one.
-- **The reconstruction Assets and the compute leg (`COMPUTE-1`).** The `ssc-raft` HPC path is named above, not modelled.
-- **The orchestration migration status (`ORCH-1`).** Whether MOGNO still runs the custom `mgn-*` stack or has moved to Bluesky/sophys is an open question.
-- **The PSS permit signals and shutters (`PSS-1`).** Absent from public sources, carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_mogno_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/mogno/notes.md b/docs/deployments/mogno/notes.md
new file mode 100644
index 00000000000..da3b047870d
--- /dev/null
+++ b/docs/deployments/mogno/notes.md
@@ -0,0 +1,137 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of MOGNO is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../sirius/index.md#the-techniques-adapted-here) is how a facility adapts it. MOGNO runs cone-beam X-ray tomography, which is already in CORA's catalog, so the Method below renders linked and the practice is carried pending until the technique enters scope (`TECH-1`).
+
+### Cone-beam micro and nanotomography
+
+MOGNO illuminates the sample with a quasi-monochromatic divergent (cone) beam and records projections as the sample rotates. Because the geometry is cone-beam, moving the sample along the cone between the secondary source and the detector changes the magnification, so a single instrument spans nanotomography (at the elliptical-mirror nanofocus) and microtomography (large field of view) by sample position. Phase contrast comes from propagation over the sample-to-detector distance, and time-resolved (4D) tomography from fast continuous rotation.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Cone-beam X-ray tomography | `tomography` | projections over a rotation on the [nanotomography](sample.md) and [microtomography](sample.md) stations, hardware-triggered by the [TATU timing unit](controls.md); reuses the graduated `tomography` Method the APS 2-BM pilot and NSLS-II FXI share; practice pending (`TECH-1`) |
+
+Tomography at MOGNO needs the [rotation axis](sample.md) as the master clock, the [TATU trigger](controls.md) to hardware-sync projection acquisition, the [detector chain](detector.md) to record the projections plus flat and dark fields, and the [cone-beam magnification axis](detector.md) to set the resolution-and-field-of-view working point.
+
+### A familiar technique on a third facility
+
+MOGNO is the tomography spine reaching a third facility after the APS 2-BM bending-magnet micro-CT pilot and the NSLS-II FXI transmission microscope. It coins no new Method: the same `tomography` Method covers micro and nano variants, exactly as 2-BM uses it for both. What MOGNO reinforces is not the technique but the surrounding model, the cone-beam magnification as a `PseudoAxis`, the FPGA trigger as a `TimingController`, and the seam against a custom (non-Bluesky) orchestration layer.
+
+The streaming and continuous-rotation tomography variants the catalog already carries (`streaming_tomography`, `continuous_rotation_tomography`) are plausible for MOGNO's 4D time-resolved work, but are not asserted here without a source; they would be added as practices once staff confirm the acquisition modes.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the rotation ranges and speeds, the projection counts, the flat and dark field cadence, the per-energy and per-station alignment routines, and the reconstruction parameters) are not written yet; they join as the deployment approaches the point where CORA drives MOGNO. The reconstruction step (`ssc-raft` on the HPC cluster) is named on [Model](#the-compute-axis-reconstruction-named-not-built) as the compute axis, not modelled here. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at MOGNO, and the trust shape that will gate it. First cut.*
+
+Governance at MOGNO follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Sirius Site](../sirius/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+MOGNO is CORA's first Sirius deployment, so Sirius is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [Sirius Site](../sirius/index.md#safety-and-governance), shared across the facility's beamlines, until LNLS staff confirm them (`GOV-1`). MOGNO is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives MOGNO, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The Sirius personnel-safety permit signals and the photon and front-end shutters are not in any public source, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Sirius Site](../sirius/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+MOGNO carries the hazard classes that come with a tomography beamline: an intense X-ray beam (a quasi-monochromatic dipole source running up to ~68 keV), and the radiation-enclosure interlocks of the two experiment stations. Those land at the Site safety envelope; an experiment Clearance would carry the per-experiment authorization.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives MOGNO, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's MOGNO content lives, the new Sirius Site and the compute axis named for reconstruction, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at MOGNO |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the cone-beam magnification `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes MOGNO new
+
+MOGNO is CORA's **eighth Site** (Sirius, the Brazilian Synchrotron Light Laboratory at CNPEM) and the fleet's **first South American facility**, the biggest re-test of the Site and Federation kernel a single deployment can be. Its science is cone-beam X-ray micro and nanotomography across two endstations, fed by a quasi-monochromatic dipole source at three working energies.
+
+It is also the thinnest reverse-engineered scaffold to date, by necessity. The NSLS-II and Diamond beamlines were built from public open-source controls libraries (bluesky profile collections, `dodal`), so their descriptors carry real EPICS PVs or device handles. MOGNO has no public controls configuration: its facts come from two papers and a facility page. So every device binds a catalog Family but carries no handle and no vendor Model; the handles are open questions, not read-from-config evidence.
+
+### No new families, no new method (reuse and reinforce)
+
+MOGNO coins nothing. It is the tomography spine landing on a third facility after the APS 2-BM pilot and NSLS-II FXI, and it reuses their vocabulary wholesale:
+
+- the rotation axes bind `RotaryStage` (the master clock for triggered acquisition);
+- the sample positioners (including the fine piezo "tripod") bind `LinearStage`, the axis set a per-Asset setting;
+- the focusing optics bind `Mirror`, the beam-defining slits bind `Slit`;
+- the detectors bind `Camera` and `Scintillator` (the indirect chain);
+- the cone-beam magnification binds `PseudoAxis` (the FXI Magnification precedent);
+- the TATU FPGA trigger binds `TimingController` (the 2-BM softGlueZynq / FXI Zebra precedent);
+- the machine state binds the loose `StorageRing`;
+- the `tomography` Method is reused, the practice carried pending (`TECH-1`).
+
+### The control seam: a custom EPICS application layer
+
+MOGNO is the fleet's first orchestration layer that is neither Bluesky nor BLISS nor Sardana. Its floor is EPICS IOCs plus a TATU FPGA trigger/timer (shared Sirius infrastructure, exposing EPICS PVs via the LNLS Nheengatu layer). Above that floor sits a beamline-owned custom PyEpics application stack: `mgn-devices` (device abstraction over PyEpics), `mgn-routines` (the alignment and tomogram acquisition routines), and `mgn-control-guis` (the PyQt/PyDM launchers). A tomogram is launched from a GUI dialog that runs the relevant `mgn-routines` script as a subprocess, driving the rotation stage, detector, and TATU trigger over EPICS.
+
+That custom routine layer is the orchestration CORA's edge would conduct over the EPICS floor, exactly as the 2-BM seam designates: CORA's EdgeConductor replaces the scan/alignment orchestration the `mgn-routines` perform today, conducting over the EPICS + TATU floor rather than replacing it. The beamline has named Bluesky/sophys (Ophyd devices, Bluesky plans) as a future migration target; whether it has migrated is an open question (`ORCH-1`). Modelling the seam against a custom stack, not Bluesky, is the point: it confirms the seam model does not assume a particular orchestration framework.
+
+### The compute axis: reconstruction named, not built
+
+MOGNO reconstructs on an HPC cluster. The beamline's reconstruction library is `ssc-raft` (CUDA, from the Sirius Scientific Computing group), submitted to the cluster over SSH from a FastAPI reconstruction service with a PyQt job-queue GUI; it has been the production reconstruction path since early 2024. This is a clean instance of CORA's compute axis (a `ComputePort` over a Method, no new BC): named here as reinforcement of the compute-modelling synthesis, not modelled as Assets in this cut. The cluster name, scheduler, and storage path are not confirmed from public sources (`COMPUTE-1`).
+
+### Deliberately not here yet
+
+- **The exact device handles and vendor models (`CTRL-1`, `STAGE-1`, `STAGE-2`, `STAGE-3`, `CAM-1`, `CAM-2`, `OPT-1`, `OPT-2`).** No public controls config exists; the PVs, controller boxes, and part numbers must come from staff. They carry no value here rather than a guessed one.
+- **The reconstruction Assets and the compute leg (`COMPUTE-1`).** The `ssc-raft` HPC path is named above, not modelled.
+- **The orchestration migration status (`ORCH-1`).** Whether MOGNO still runs the custom `mgn-*` stack or has moved to Bluesky/sophys is an open question.
+- **The PSS permit signals and shutters (`PSS-1`).** Absent from public sources, carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_mogno_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the MOGNO team to confirm before the model can be trusted.*
+
+MOGNO was reverse-engineered from two published papers (Campoi et al. 2025, the software architecture; Archilha et al. 2022, the beamline) and the public [Sirius MOGNO facility page](https://lnls.cnpem.br/facilities/mogno/). Unlike the NSLS-II and Diamond scaffolds, there is no public controls configuration to read, so MOGNO carries no real control handles at all: the device families are inferred from the papers, and every handle, model, and PV namespace is an open question. This is CORA's first Sirius Site and first South American facility. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The source type (permanent-magnet dipole vs superbend), field, and the energy-selection mechanism. | A 3.2 T dipole / superbend bound to `InsertionDevice`, recorded as a Supply (PhotonBeam) at the Site. | The source Asset detail. |
+| SRC-2 | Nice-to-have | The working energy set: the hardware paper gives 21.5 / 39.0 / 67.7 keV, the facility page 22 / 39 / 67.5 keV. | The three quasi-monochromatic working energies; exact values pending. | The energy working points. |
+| MACHINE-1 | Nice-to-have | The Sirius storage-ring state MOGNO reads. | Observe-only machine state, a loose `StorageRing`; exact read pending. | The machine-state observation. |
+| OPT-1 | Blocks-go-live | The focusing-mirror count, geometry (elliptical set vs KB pair), coatings, and handles. | Elliptical / KB-style focusing mirrors bound to `Mirror`, demagnifying to ~100-120 nm. | The mirror Assets. |
+| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
+
+### Sample stations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The nanotomography rotation stage (model, encoder, max speed, handle). | A `RotaryStage`, the master clock for hardware-triggered acquisition. | The nano rotation Asset. |
+| STAGE-2 | Blocks-go-live | The nanotomography fine sample positioner (the piezo "tripod" axes and model). | A `LinearStage`; axis set a per-Asset setting. | The nano sample-positioner Asset. |
+| STAGE-3 | Blocks-go-live | The microtomography station stages (rotation and positioner models, axes, handles). | A `RotaryStage` and a `LinearStage`, mirroring the nano station at coarser resolution. | The micro-station Assets. |
+
+### Detector and data
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CAM-1 | Blocks-go-live | The detector roster and per-station pairing: which of Pimega (Si photon-counting), the sCMOS indirect chain, and the CdTe Medipix/Mobipix are installed and active at each station. | One detector position bound to `Camera` until staff confirm; the FXI multi-camera precedent. | The detector Assets. |
+| CAM-2 | Nice-to-have | The scintillator material and thickness and the Optique Peter microscope objective set for the indirect chain. | A `Scintillator` (e.g. LuAG:Ce) coupled via a microscope. | The indirect-chain detail. |
+| MAG-1 | Nice-to-have | The cone-beam magnification rule (how sample-along-cone position maps to magnification). | A `PseudoAxis` over the sample and detector distances; rule deferred. The FXI Magnification precedent. | The magnification Asset. |
+| DATA-1 | Blocks-go-live | The acquisition file format and layout: HDF5 / NeXus / DXchange `exchange/data` + flat + dark, and the metadata schema injected into the file. | A single main data file carrying projections, flat, dark, and metadata; format pending. | The data-of-record interface. |
+
+### Control, compute, and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | The EPICS PV namespaces, the TATU trigger handles, and the motion-controller boxes. None are in public sources. | EPICS IOCs + a TATU FPGA trigger as the floor, with the handles carried confirm. | Verifying each Asset's control handle. |
+| ORCH-1 | Blocks-go-live | Does MOGNO still run the custom `mgn-*` PyEpics stack, or has it migrated to Bluesky/sophys? | The custom `mgn-devices` / `mgn-routines` / `mgn-control-guis` stack today, with Bluesky a future target. | The orchestration seam CORA conducts over. |
+| COMPUTE-1 | Nice-to-have | The reconstruction HPC cluster name, scheduler (SLURM?), GPU resources, and shared storage path. | `ssc-raft` (CUDA) submitted to an HPC cluster over SSH; cluster specifics pending. | The compute leg. |
+| PSS-1 | Blocks-go-live | The Sirius personnel-safety permit signals and the photon / front-end shutters. | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| GOV-1 | Nice-to-have | The Sirius operator pool and safety-review structure (site-level). | Carried pending on the Sirius Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/mogno/questions.md b/docs/deployments/mogno/questions.md
deleted file mode 100644
index 1f9096b9486..00000000000
--- a/docs/deployments/mogno/questions.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Open questions
-
-*What CORA needs the MOGNO team to confirm before the model can be trusted.*
-
-MOGNO was reverse-engineered from two published papers (Campoi et al. 2025, the software architecture; Archilha et al. 2022, the beamline) and the public [Sirius MOGNO facility page](https://lnls.cnpem.br/facilities/mogno/). Unlike the NSLS-II and Diamond scaffolds, there is no public controls configuration to read, so MOGNO carries no real control handles at all: the device families are inferred from the papers, and every handle, model, and PV namespace is an open question. This is CORA's first Sirius Site and first South American facility. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The source type (permanent-magnet dipole vs superbend), field, and the energy-selection mechanism. | A 3.2 T dipole / superbend bound to `InsertionDevice`, recorded as a Supply (PhotonBeam) at the Site. | The source Asset detail. |
-| SRC-2 | Nice-to-have | The working energy set: the hardware paper gives 21.5 / 39.0 / 67.7 keV, the facility page 22 / 39 / 67.5 keV. | The three quasi-monochromatic working energies; exact values pending. | The energy working points. |
-| MACHINE-1 | Nice-to-have | The Sirius storage-ring state MOGNO reads. | Observe-only machine state, a loose `StorageRing`; exact read pending. | The machine-state observation. |
-| OPT-1 | Blocks-go-live | The focusing-mirror count, geometry (elliptical set vs KB pair), coatings, and handles. | Elliptical / KB-style focusing mirrors bound to `Mirror`, demagnifying to ~100-120 nm. | The mirror Assets. |
-| OPT-2 | Nice-to-have | The beam-defining slit blade-axis map and handles. | Slits bound to `Slit`. | The slit Asset detail. |
-
-## Sample stations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The nanotomography rotation stage (model, encoder, max speed, handle). | A `RotaryStage`, the master clock for hardware-triggered acquisition. | The nano rotation Asset. |
-| STAGE-2 | Blocks-go-live | The nanotomography fine sample positioner (the piezo "tripod" axes and model). | A `LinearStage`; axis set a per-Asset setting. | The nano sample-positioner Asset. |
-| STAGE-3 | Blocks-go-live | The microtomography station stages (rotation and positioner models, axes, handles). | A `RotaryStage` and a `LinearStage`, mirroring the nano station at coarser resolution. | The micro-station Assets. |
-
-## Detector and data
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CAM-1 | Blocks-go-live | The detector roster and per-station pairing: which of Pimega (Si photon-counting), the sCMOS indirect chain, and the CdTe Medipix/Mobipix are installed and active at each station. | One detector position bound to `Camera` until staff confirm; the FXI multi-camera precedent. | The detector Assets. |
-| CAM-2 | Nice-to-have | The scintillator material and thickness and the Optique Peter microscope objective set for the indirect chain. | A `Scintillator` (e.g. LuAG:Ce) coupled via a microscope. | The indirect-chain detail. |
-| MAG-1 | Nice-to-have | The cone-beam magnification rule (how sample-along-cone position maps to magnification). | A `PseudoAxis` over the sample and detector distances; rule deferred. The FXI Magnification precedent. | The magnification Asset. |
-| DATA-1 | Blocks-go-live | The acquisition file format and layout: HDF5 / NeXus / DXchange `exchange/data` + flat + dark, and the metadata schema injected into the file. | A single main data file carrying projections, flat, dark, and metadata; format pending. | The data-of-record interface. |
-
-## Control, compute, and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | The EPICS PV namespaces, the TATU trigger handles, and the motion-controller boxes. None are in public sources. | EPICS IOCs + a TATU FPGA trigger as the floor, with the handles carried confirm. | Verifying each Asset's control handle. |
-| ORCH-1 | Blocks-go-live | Does MOGNO still run the custom `mgn-*` PyEpics stack, or has it migrated to Bluesky/sophys? | The custom `mgn-devices` / `mgn-routines` / `mgn-control-guis` stack today, with Bluesky a future target. | The orchestration seam CORA conducts over. |
-| COMPUTE-1 | Nice-to-have | The reconstruction HPC cluster name, scheduler (SLURM?), GPU resources, and shared storage path. | `ssc-raft` (CUDA) submitted to an HPC cluster over SSH; cluster specifics pending. | The compute leg. |
-| PSS-1 | Blocks-go-live | The Sirius personnel-safety permit signals and the photon / front-end shutters. | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| GOV-1 | Nice-to-have | The Sirius operator pool and safety-review structure (site-level). | Carried pending on the Sirius Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/mogno/techniques.md b/docs/deployments/mogno/techniques.md
deleted file mode 100644
index 243aba65841..00000000000
--- a/docs/deployments/mogno/techniques.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Techniques
-
-*What the modelled part of MOGNO is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../sirius/index.md#the-techniques-adapted-here) is how a facility adapts it. MOGNO runs cone-beam X-ray tomography, which is already in CORA's catalog, so the Method below renders linked and the practice is carried pending until the technique enters scope (`TECH-1`).
-
-## Cone-beam micro and nanotomography
-
-MOGNO illuminates the sample with a quasi-monochromatic divergent (cone) beam and records projections as the sample rotates. Because the geometry is cone-beam, moving the sample along the cone between the secondary source and the detector changes the magnification, so a single instrument spans nanotomography (at the elliptical-mirror nanofocus) and microtomography (large field of view) by sample position. Phase contrast comes from propagation over the sample-to-detector distance, and time-resolved (4D) tomography from fast continuous rotation.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Cone-beam X-ray tomography | `tomography` | projections over a rotation on the [nanotomography](sample.md) and [microtomography](sample.md) stations, hardware-triggered by the [TATU timing unit](controls.md); reuses the graduated `tomography` Method the APS 2-BM pilot and NSLS-II FXI share; practice pending (`TECH-1`) |
-
-Tomography at MOGNO needs the [rotation axis](sample.md) as the master clock, the [TATU trigger](controls.md) to hardware-sync projection acquisition, the [detector chain](detector.md) to record the projections plus flat and dark fields, and the [cone-beam magnification axis](detector.md) to set the resolution-and-field-of-view working point.
-
-## A familiar technique on a third facility
-
-MOGNO is the tomography spine reaching a third facility after the APS 2-BM bending-magnet micro-CT pilot and the NSLS-II FXI transmission microscope. It coins no new Method: the same `tomography` Method covers micro and nano variants, exactly as 2-BM uses it for both. What MOGNO reinforces is not the technique but the surrounding model, the cone-beam magnification as a `PseudoAxis`, the FPGA trigger as a `TimingController`, and the seam against a custom (non-Bluesky) orchestration layer.
-
-The streaming and continuous-rotation tomography variants the catalog already carries (`streaming_tomography`, `continuous_rotation_tomography`) are plausible for MOGNO's 4D time-resolved work, but are not asserted here without a source; they would be added as practices once staff confirm the acquisition modes.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the rotation ranges and speeds, the projection counts, the flat and dark field cadence, the per-energy and per-station alignment routines, and the reconstruction parameters) are not written yet; they join as the deployment approaches the point where CORA drives MOGNO. The reconstruction step (`ssc-raft` on the HPC cluster) is named on [Model](model.md#the-compute-axis-reconstruction-named-not-built) as the compute axis, not modelled here. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/mx3/governance.md b/docs/deployments/mx3/governance.md
deleted file mode 100644
index c5f7d8e876d..00000000000
--- a/docs/deployments/mx3/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at MX3 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [Australian Synchrotron Site](../as/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the device library (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Australian Synchrotron Site. An MX3 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site; MX3 being a new Site is exactly the test that the Federation / Access kernel ports unchanged.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer, and it holds the same across all four control planes (a command to the Eiger over REST or the robot over TCP is gated exactly as an EPICS motor move is). The facility proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Unattended autonomous collection
-
-MX3's throughput model is unattended: the ISARA robot mounts a crystal, the MD3 centres it, the Eiger collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/mx3/model.md b/docs/deployments/mx3/model.md
deleted file mode 100644
index f1a4c065233..00000000000
--- a/docs/deployments/mx3/model.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's MX3 content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at MX3 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (MX3-OH optics, MX3-EH experiment) |
-| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [Australian Synchrotron Site](../as/index.md), [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines. Left out on purpose:
-
-- **No new Family.** MX3's novelty is the Site and its control plane, not its devices: the MD3 goniometer binds the graduated `Goniometer` (the i03 MX precedent), the detectors `Camera`, the DMM `Monochromator`, the cryojet `TemperatureController`, the attenuator `Filter`, the flux monitor `FluxMonitor`, the beamstop `BeamStop`, the shutters `Shutter`, the stages `LinearStage` / `MotionController`.
-- **The reused loose family.** `StorageRing` (the ring-current monitor) is bound loose, already allowlisted from earlier deployments; MX3 coins no new loose family. The MD3 backlight binds the catalog `Backlight` Family (graduated across the MX / imaging fleet). The beam-position monitor binds the graduated catalog `BeamPositionMonitor`, which presents `Sensor`, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux.
-- **The heterogeneous control plane.** MX3 drives EPICS, the MXCuBE Exporter protocol (MD3), the SIMPLON REST API (Eiger), and a TCP robot client (ISARA). This is modelled as `ControlPort` adapters, not new aggregates; the three non-EPICS devices carry no PV and route their host / endpoint to deployment config (GONIO-1, DET-1, ROBOT-1). See [Controls](controls.md).
-- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 shape, not a new device family.
-- **The beam-steering controller.** The closed-loop PID steering paired with the BPM (`MX3DAQIOC04:`) fits no existing family cleanly; the BPM half binds `PositionMonitor` and the steering controller is a deferred new-device question (STEER-1).
-- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods (`mx_data_collection` / `grid_scan` / `sample_exchange`), recorded as Practices on the Site; MX3 reinforces the case without coining any (TECH-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/mx3/notes.md b/docs/deployments/mx3/notes.md
new file mode 100644
index 00000000000..a0dc89cd4b2
--- /dev/null
+++ b/docs/deployments/mx3/notes.md
@@ -0,0 +1,108 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at MX3: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [Australian Synchrotron Practice](../as/index.md#the-techniques-adapted-here). MX3 reuses the MX Methods Diamond [I03](../i03/notes.md#techniques) introduced, so it coins nothing new.*
+
+MX3's technique, rotation MX, is the macromolecular-crystallography shape CORA already saw at i03 (and, in its serial form, at i24 and LCLS-MFX). The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog, exactly as at i03.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the Eiger; the i03 Method, pending (TECH-1) |
+| Grid scan | `grid_scan` | fast grid scan for sample location / centring on the MD3 (TECH-1) |
+| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
+
+All three are recorded as pending [Practices](../as/index.md#the-techniques-adapted-here) on the Australian Synchrotron Site, reusing the same Method names Diamond i03 carries.
+
+### Why the Methods are reused, not coined
+
+MX3 brings a new Site, not a new technique. Rotation MX, grid-scan centring, and robot sample exchange are the i03 shapes, so MX3 binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and MX3 reinforces the case at a further facility (after Diamond i03 and NSLS-II FMX / AMX). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the Eiger presents Detector via `Camera`), so nothing new is needed in the device model either.
+
+The autonomous sample exchange reuses the i03 / i24 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1). Indexing and integration of the diffraction frames are `ComputePort` work, not beamline Methods.
+
+The genuinely new thing MX3 contributes is below the technique layer: a sixth Site and a heterogeneous control plane (see [Controls](controls.md)), which the technique vocabulary rides over unchanged.
+
+## Governance
+
+*Who may act at MX3 and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [Australian Synchrotron Site](../as/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the device library (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the Australian Synchrotron Site. An MX3 beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site; MX3 being a new Site is exactly the test that the Federation / Access kernel ports unchanged.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer, and it holds the same across all four control planes (a command to the Eiger over REST or the robot over TCP is gated exactly as an EPICS motor move is). The facility proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Unattended autonomous collection
+
+MX3's throughput model is unattended: the ISARA robot mounts a crystal, the MD3 centres it, the Eiger collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's MX3 content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at MX3 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (MX3-OH optics, MX3-EH experiment) |
+| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [Australian Synchrotron Site](../as/index.md), [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines. Left out on purpose:
+
+- **No new Family.** MX3's novelty is the Site and its control plane, not its devices: the MD3 goniometer binds the graduated `Goniometer` (the i03 MX precedent), the detectors `Camera`, the DMM `Monochromator`, the cryojet `TemperatureController`, the attenuator `Filter`, the flux monitor `FluxMonitor`, the beamstop `BeamStop`, the shutters `Shutter`, the stages `LinearStage` / `MotionController`.
+- **The reused loose family.** `StorageRing` (the ring-current monitor) is bound loose, already allowlisted from earlier deployments; MX3 coins no new loose family. The MD3 backlight binds the catalog `Backlight` Family (graduated across the MX / imaging fleet). The beam-position monitor binds the graduated catalog `BeamPositionMonitor`, which presents `Sensor`, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux.
+- **The heterogeneous control plane.** MX3 drives EPICS, the MXCuBE Exporter protocol (MD3), the SIMPLON REST API (Eiger), and a TCP robot client (ISARA). This is modelled as `ControlPort` adapters, not new aggregates; the three non-EPICS devices carry no PV and route their host / endpoint to deployment config (GONIO-1, DET-1, ROBOT-1). See [Controls](controls.md).
+- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 shape, not a new device family.
+- **The beam-steering controller.** The closed-loop PID steering paired with the BPM (`MX3DAQIOC04:`) fits no existing family cleanly; the BPM half binds `PositionMonitor` and the steering controller is a deferred new-device question (STEER-1).
+- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods (`mx_data_collection` / `grid_scan` / `sample_exchange`), recorded as Practices on the Site; MX3 reinforces the case without coining any (TECH-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the Australian Synchrotron / MX3 team to confirm. This model is reverse-engineered from public open source (the [`AustralianSynchrotron/mx3-beamline-library`](https://github.com/AustralianSynchrotron/mx3-beamline-library) device library): the EPICS PVs are read from it, but vendor identities, physical positions, the source, and the non-EPICS subsystem endpoints are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The insertion-device / front-end source: MX3 is an undulator beamline, but no source PV is in the library, only the storage-ring current monitor (`SR11BCM01:CURRENT_MONITOR`). | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the photon-shutter enable / status PVs (`MX3FE01SHT01`, `MX3BLSH01SHT01`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? The library exposes no enclosure structure. | An optics hutch plus an experiment hutch (the MD3 / Eiger / robot). | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The double-multilayer monochromator coating stripes and range, and the attenuator foil set. Both (`MX3MONO01`, `MX3FLT05`) are in source. | One Monochromator and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
+| OPT-1 | Nice-to-have | The beam-conditioning optics not in the library: mirrors and any standalone slits (the `devices/optics.py` stub is empty). | None modelled; the `MX3FLT05` unit carries the beam-size readback. | The mirror / slit Assets. |
+| ENERGY-1 | Nice-to-have | Does MX3 scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
+
+### Sample, detector, robot
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer host / port (it is driven over the MXCuBE Exporter protocol at `MD3_ADDRESS:MD3_PORT`, an env-config default in the library, not a baked PV), and the full axis set behind the Exporter property names. | A `Goniometer` Asset (omega / kappa / phi + centring / alignment) over the Exporter seam; the host is deployment config. | The Goniometer interface and axes. |
+| DET-1 | Blocks-go-live | The DECTRIS Eiger model (16M / 4M) and its SIMPLON REST endpoint (`SIMPLON_API`, an env-config default in the library). | An Eiger `Camera` over the SIMPLON REST seam; the endpoint is deployment config. | The detector Model and interface. |
+| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (a TCP client at `ROBOT_HOST`, mount / unmount trajectories gated on the MD3 state). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the i03 / i24 loops. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
+| DIAG-1 | Nice-to-have | The flux and beam-position channel maps; the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor / PositionMonitor bindings. |
+| STEER-1 | Nice-to-have | The closed-loop beam-steering controller (`MX3DAQIOC04:` PID + DAC paired with the BPM): is it a device Family of its own, or a settings-only feedback variant? It fits no existing family cleanly. | The BPM half binds the graduated catalog `PositionMonitor`; the PID steering controller is named but not modelled. | The beam-steering device boundary. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs (the Australian Synchrotron Power Brick PMAC behind the `MX3STG..MOT..` axes). | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the MX Capabilities (rotation data collection, grid scan) enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i03 opened; MX3 reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
diff --git a/docs/deployments/mx3/questions.md b/docs/deployments/mx3/questions.md
deleted file mode 100644
index 417ce6ddb1a..00000000000
--- a/docs/deployments/mx3/questions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Open questions
-
-*What CORA needs the Australian Synchrotron / MX3 team to confirm. This model is reverse-engineered from public open source (the [`AustralianSynchrotron/mx3-beamline-library`](https://github.com/AustralianSynchrotron/mx3-beamline-library) device library): the EPICS PVs are read from it, but vendor identities, physical positions, the source, and the non-EPICS subsystem endpoints are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The insertion-device / front-end source: MX3 is an undulator beamline, but no source PV is in the library, only the storage-ring current monitor (`SR11BCM01:CURRENT_MONITOR`). | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the photon-shutter enable / status PVs (`MX3FE01SHT01`, `MX3BLSH01SHT01`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? The library exposes no enclosure structure. | An optics hutch plus an experiment hutch (the MD3 / Eiger / robot). | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The double-multilayer monochromator coating stripes and range, and the attenuator foil set. Both (`MX3MONO01`, `MX3FLT05`) are in source. | One Monochromator and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
-| OPT-1 | Nice-to-have | The beam-conditioning optics not in the library: mirrors and any standalone slits (the `devices/optics.py` stub is empty). | None modelled; the `MX3FLT05` unit carries the beam-size readback. | The mirror / slit Assets. |
-| ENERGY-1 | Nice-to-have | Does MX3 scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
-
-## Sample, detector, robot
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer host / port (it is driven over the MXCuBE Exporter protocol at `MD3_ADDRESS:MD3_PORT`, an env-config default in the library, not a baked PV), and the full axis set behind the Exporter property names. | A `Goniometer` Asset (omega / kappa / phi + centring / alignment) over the Exporter seam; the host is deployment config. | The Goniometer interface and axes. |
-| DET-1 | Blocks-go-live | The DECTRIS Eiger model (16M / 4M) and its SIMPLON REST endpoint (`SIMPLON_API`, an env-config default in the library). | An Eiger `Camera` over the SIMPLON REST seam; the endpoint is deployment config. | The detector Model and interface. |
-| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (a TCP client at `ROBOT_HOST`, mount / unmount trajectories gated on the MD3 state). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the i03 / i24 loops. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
-| DIAG-1 | Nice-to-have | The flux and beam-position channel maps; the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux). | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor / PositionMonitor bindings. |
-| STEER-1 | Nice-to-have | The closed-loop beam-steering controller (`MX3DAQIOC04:` PID + DAC paired with the BPM): is it a device Family of its own, or a settings-only feedback variant? It fits no existing family cleanly. | The BPM half binds the graduated catalog `PositionMonitor`; the PID steering controller is named but not modelled. | The beam-steering device boundary. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs (the Australian Synchrotron Power Brick PMAC behind the `MX3STG..MOT..` axes). | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the MX Capabilities (rotation data collection, grid scan) enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i03 opened; MX3 reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
diff --git a/docs/deployments/mx3/techniques.md b/docs/deployments/mx3/techniques.md
deleted file mode 100644
index 30824b44cc7..00000000000
--- a/docs/deployments/mx3/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What CORA would run at MX3: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [Australian Synchrotron Practice](../as/index.md#the-techniques-adapted-here). MX3 reuses the MX Methods Diamond [I03](../i03/techniques.md) introduced, so it coins nothing new.*
-
-MX3's technique, rotation MX, is the macromolecular-crystallography shape CORA already saw at i03 (and, in its serial form, at i24 and LCLS-MFX). The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog, exactly as at i03.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the Eiger; the i03 Method, pending (TECH-1) |
-| Grid scan | `grid_scan` | fast grid scan for sample location / centring on the MD3 (TECH-1) |
-| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
-
-All three are recorded as pending [Practices](../as/index.md#the-techniques-adapted-here) on the Australian Synchrotron Site, reusing the same Method names Diamond i03 carries.
-
-## Why the Methods are reused, not coined
-
-MX3 brings a new Site, not a new technique. Rotation MX, grid-scan centring, and robot sample exchange are the i03 shapes, so MX3 binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and MX3 reinforces the case at a further facility (after Diamond i03 and NSLS-II FMX / AMX). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the Eiger presents Detector via `Camera`), so nothing new is needed in the device model either.
-
-The autonomous sample exchange reuses the i03 / i24 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1). Indexing and integration of the diffraction frames are `ComputePort` work, not beamline Methods.
-
-The genuinely new thing MX3 contributes is below the technique layer: a sixth Site and a heterogeneous control plane (see [Controls](controls.md)), which the technique vocabulary rides over unchanged.
diff --git a/docs/deployments/p01/governance.md b/docs/deployments/p01/governance.md
deleted file mode 100644
index fa7e42af425..00000000000
--- a/docs/deployments/p01/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P01, and the trust shape that will gate it. First cut.*
-
-Governance at P01 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P01 is CORA's first PETRA III beamline, so the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P01 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P01, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the two optics and three experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P01 also carries the hazard classes that come with its endstations: the high-resolution-monochromator stack and the KB optics are precision instruments inside interlocked hutches, and the five-hutch layout means several enclosures gate the beam in series. Those land with the instruments that bring them when the deployment firms up.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P01, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p01/model.md b/docs/deployments/p01/model.md
deleted file mode 100644
index b057f25dda1..00000000000
--- a/docs/deployments/p01/model.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P01 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P01 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (coupled mono energy) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P01 new
-
-P01 is a new Site's first beamline, and two things genuinely new at the modelling level. It is **CORA's first PETRA III beamline** and a further **Tango / Sardana control floor** (after MAX IV and ALBA). Its science is hard X-ray dynamics: nuclear resonant scattering in EH1, diffraction in EH2, and RIXS in EH3, across 2.5-80 keV.
-
-- **The control plane (`CTRL-1`).** PETRA III runs Tango with Sardana as the scan layer. P01 is the first deployment whose device handles were read from a DESY OnlineXML registry, the Tango analog of the ESRF BLISS Beacon config and the APS Guarneri `devices.yml`. The OnlineXML extractor that produced the candidate is `reverse_engineer/` in the (private) `xmap/research` repo (the `--source onlinexml` path).
-- **The technique branch (`TECH-1`).** NRS and RIXS are new to CORA's catalog but reuse the IXS / RIXS slugs already carried pending across the fleet, so no Method is coined now.
-
-## No new families (the optics / motion spine reuses the fleet precedent)
-
-P01 coins no new Family. The monochromators bind `Monochromator` and the coupled energy is a `PseudoAxis`; the mirrors (deflection and KB) bind `Mirror`; the slits bind `Slit`; the CRL binds `Transfocator`; the undulator binds `InsertionDevice`; the stages bind `LinearStage` / `RotaryStage` / `Table`; the EH2 sample circle binds `Goniometer`; the BPM / ion chamber / diamond monitor bind `FluxMonitor`. Nothing in the catalog changes.
-
-The one binding worth calling out: the EH2 sample circle is modelled as a **`Goniometer`** Asset (the catalog Family), not the composed **`Diffractometer`** Assembly. The OnlineXML exposes only theta / two-theta; the `Diffractometer` Assembly requires a goniometer plus a detector arm plus a reciprocal-space layer, none of which the registry confirms. This follows the catalog's own guidance (the TARDIS E6C precedent) and is carried `DIFF-1`.
-
-## The control plane
-
-P01 sits on the PETRA III Tango device floor with Sardana as the scan / motion SCADA layer (Pool / MacroServer / MeasurementGroup, Spock CLI, Taurus UIs). A motion axis is a Tango motor device (`p01/motor/<hutch>.<n>`), a coupled axis is a virtual-motor executor (`p01/vmexecutor/<name>`), and a scan is a Sardana macro. The handles are read from P01's public OnlineXML registry and carried confirm; the device servers live in `tango-ds/deviceclasses`, the Sardana fork in `fsec-sardana` (`CTRL-1`). The NRS / RIXS acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, conducting over the Tango floor rather than owning it. The NeXus file-writing (the `nexdatas` chain) is plumbing CORA observes, not data it owns.
-
-## Deliberately not here yet
-
-- **The detector devices (`DET-1`).** The OnlineXML carries detector positioning stages, not the detector device servers; the APD / RIXS / diffraction detectors are named, not bound.
-- **The physical optics detail (`MONO-1`, `NRS-1`, `OPT-1`).** The DCM crystal cut, which HRM is in beam per isotope, the mirror coatings, the KB bend radii, and the CRL recipe are carried confirm-pending.
-- **The goniometer geometry (`DIFF-1`).** The EH2 circle count beyond theta / two-theta, and whether it composes a Diffractometer Assembly, is pending.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The NRS / RIXS Methods (`TECH-1`).** Whether these enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the IXS / RIXS slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p01_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p01/notes.md b/docs/deployments/p01/notes.md
new file mode 100644
index 00000000000..95105103b2e
--- /dev/null
+++ b/docs/deployments/p01/notes.md
@@ -0,0 +1,143 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P01 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P01 runs hard X-ray dynamics techniques (nuclear resonant scattering and resonant inelastic scattering) that earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### Nuclear resonant scattering (EH1)
+
+P01 sets the X-ray energy onto a Moessbauer isotope's nuclear resonance with the [double-crystal monochromator](source.md), then carves a meV / Moessbauer-energy bandwidth with the [high-resolution monochromator stack](sample.md) (the four nested / channel-cut HRMs). Scanning the high-resolution-monochromator energy axis while reading the time- and energy-resolved detector signal produces the nuclear inelastic / resonant spectrum.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Nuclear resonant scattering / nuclear inelastic scattering | `inelastic_x_ray_scattering` | the high-resolution-monochromator energy scan reading the avalanche-photodiode signal; no catalog Method fits, reuses the IXS slug ESRF ID28 / NSLS-II IXS share, a further consumer (`TECH-1`) |
+
+### Resonant inelastic X-ray scattering (EH3)
+
+P01's EH3 endstation focuses the beam with the [KB mirror pair](sample.md) onto the sample and analyzes the inelastically scattered photons on the spectrometer arm, scanning the incident energy against the analyzed energy to map the excitation spectrum.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | KB-focused incident beam analyzed on the EH3 spectrometer; reuses the RIXS slug SIX / ESRF ID32 share, a further consumer (`TECH-1`) |
+
+### Diffraction (EH2)
+
+P01's EH2 endstation carries a theta / two-theta [goniometer](sample.md) reading a detector on a positioning stage, for hard X-ray diffraction. The catalog carries no general diffraction Method today; the technique is noted, not bound, pending confirmation of the endstation's routine use (`TECH-1`, `DIFF-1`).
+
+### A new technique branch on familiar vocabulary
+
+P01 is the fleet's NRS / RIXS dynamics beamline. Its techniques are new to CORA's catalog (which is tomography- and MX-centric today), but they reuse the inelastic- and resonant-inelastic-scattering slugs already carried pending across the fleet (ESRF ID28 IXS, ESRF ID32 / SIX RIXS, NSLS-II IXS), so none forces a new Method to be coined now. The instrument anatomy reuses existing Families end to end: the monochromators bind `Monochromator`, the KB mirrors `Mirror`, the lens `Transfocator`, the stages `LinearStage` / `RotaryStage` / `Table`, the sample circle `Goniometer`.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the high-resolution-monochromator energy-scan sequences and their exposures, the RIXS incident-energy scans, the diffraction scans) are not written yet; they join as the deployment approaches the point where CORA drives P01. Whether the NRS / RIXS Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P01, and the trust shape that will gate it. First cut.*
+
+Governance at P01 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P01 is CORA's first PETRA III beamline, so the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P01 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P01, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the two optics and three experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P01 also carries the hazard classes that come with its endstations: the high-resolution-monochromator stack and the KB optics are precision instruments inside interlocked hutches, and the five-hutch layout means several enclosures gate the beam in series. Those land with the instruments that bring them when the deployment firms up.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P01, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P01 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P01 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (coupled mono energy) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P01 new
+
+P01 is a new Site's first beamline, and two things genuinely new at the modelling level. It is **CORA's first PETRA III beamline** and a further **Tango / Sardana control floor** (after MAX IV and ALBA). Its science is hard X-ray dynamics: nuclear resonant scattering in EH1, diffraction in EH2, and RIXS in EH3, across 2.5-80 keV.
+
+- **The control plane (`CTRL-1`).** PETRA III runs Tango with Sardana as the scan layer. P01 is the first deployment whose device handles were read from a DESY OnlineXML registry, the Tango analog of the ESRF BLISS Beacon config and the APS Guarneri `devices.yml`. The OnlineXML extractor that produced the candidate is `reverse_engineer/` in the (private) `xmap/research` repo (the `--source onlinexml` path).
+- **The technique branch (`TECH-1`).** NRS and RIXS are new to CORA's catalog but reuse the IXS / RIXS slugs already carried pending across the fleet, so no Method is coined now.
+
+### No new families (the optics / motion spine reuses the fleet precedent)
+
+P01 coins no new Family. The monochromators bind `Monochromator` and the coupled energy is a `PseudoAxis`; the mirrors (deflection and KB) bind `Mirror`; the slits bind `Slit`; the CRL binds `Transfocator`; the undulator binds `InsertionDevice`; the stages bind `LinearStage` / `RotaryStage` / `Table`; the EH2 sample circle binds `Goniometer`; the BPM / ion chamber / diamond monitor bind `FluxMonitor`. Nothing in the catalog changes.
+
+The one binding worth calling out: the EH2 sample circle is modelled as a **`Goniometer`** Asset (the catalog Family), not the composed **`Diffractometer`** Assembly. The OnlineXML exposes only theta / two-theta; the `Diffractometer` Assembly requires a goniometer plus a detector arm plus a reciprocal-space layer, none of which the registry confirms. This follows the catalog's own guidance (the TARDIS E6C precedent) and is carried `DIFF-1`.
+
+### The control plane
+
+P01 sits on the PETRA III Tango device floor with Sardana as the scan / motion SCADA layer (Pool / MacroServer / MeasurementGroup, Spock CLI, Taurus UIs). A motion axis is a Tango motor device (`p01/motor/<hutch>.<n>`), a coupled axis is a virtual-motor executor (`p01/vmexecutor/<name>`), and a scan is a Sardana macro. The handles are read from P01's public OnlineXML registry and carried confirm; the device servers live in `tango-ds/deviceclasses`, the Sardana fork in `fsec-sardana` (`CTRL-1`). The NRS / RIXS acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, conducting over the Tango floor rather than owning it. The NeXus file-writing (the `nexdatas` chain) is plumbing CORA observes, not data it owns.
+
+### Deliberately not here yet
+
+- **The detector devices (`DET-1`).** The OnlineXML carries detector positioning stages, not the detector device servers; the APD / RIXS / diffraction detectors are named, not bound.
+- **The physical optics detail (`MONO-1`, `NRS-1`, `OPT-1`).** The DCM crystal cut, which HRM is in beam per isotope, the mirror coatings, the KB bend radii, and the CRL recipe are carried confirm-pending.
+- **The goniometer geometry (`DIFF-1`).** The EH2 circle count beyond theta / two-theta, and whether it composes a Diffractometer Assembly, is pending.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The NRS / RIXS Methods (`TECH-1`).** Whether these enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the IXS / RIXS slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p01_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P01 team to confirm before the model can be trusted.*
+
+P01 was reverse-engineered from P01's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p01](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p01), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no physical detail (crystal cuts, energy ranges, bend radii, detector models). P01 is CORA's first PETRA III beamline and a further Tango / Sardana control floor (after MAX IV and ALBA). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: two optics hutches (OH1, OH2) feeding three experiment hutches (EH1, EH2, EH3), or a different layout? | Two `p01-oh*` optics hutches and three `p01-eh*` experiment hutches, read from the OnlineXML host names. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters, and whether gap_a/gap_b/taper_a/taper_b mean two sections or a canted arrangement. | An undulator source, 2.5-80 keV; gap / taper virtual axes only. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The Asset grouping of the registry's per-axis device list into instruments (one monochromator, one mirror, one sample stage). | The groupings on the [device pages](index.md), inferred from the axis name prefixes. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MONO-1 | Blocks-go-live | The double-crystal monochromator crystal cut (Si 111 / 311) and energy range. | A DCM bound to `Monochromator`; Bragg / energy virtual axes read from the registry. | The monochromator modelling. |
+| OPT-1 | Nice-to-have | The deflection-mirror coatings / stripes and incidence angles, the KB bend radii and focal sizes, the CRL lens count / material, and the diamond-monitor / RIXS-pre-optic roles. | Two OH1 mirrors and the EH3 KB pair bound to `Mirror`; the CRL bound to `Transfocator`; the diamond monitor bound to `FluxMonitor`; handles read, physical detail pending. | The optics Asset detail. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| NRS-1 | Blocks-go-live | The four EH1 high-resolution monochromators (400 / 1064 / 3D / 3W): which is in beam per Moessbauer isotope and resolution, and how the `hrm_ener` virtual axis couples them. | Four `Monochromator` Assets plus a `HighResMonoEnergy` `PseudoAxis`; selection per isotope pending. | The NRS instrument modelling. |
+| DIFF-1 | Blocks-go-live | The EH2 diffractometer geometry: the full circle count beyond theta / two-theta, and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (theta / two-theta), not the composed Diffractometer Assembly, until a detector arm is confirmed. | The diffractometer modelling. |
+| SAMPLE-1 | Nice-to-have | The EH3 RIXS sample-stage axes and sample-environment detail. | A `LinearStage` (x / y / b / rot / tilt) read from the registry. | The sample-stage modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector models per endstation (the EH1 NRS avalanche photodiode, the EH2 diffraction detector, the EH3 RIXS spectrometer detector), which the OnlineXML does not carry as motor rows. | Detector positioning stages bound to `LinearStage`; the detector devices named, not bound. | The detector modelling. |
+| DIAG-1 | Nice-to-have | The beam-position-monitor, ion-chamber, and diamond-monitor handles and roles. | `FluxMonitor` positioning stages read from the registry. | The diagnostics modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P01 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do nuclear resonant scattering and RIXS enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `inelastic_x_ray_scattering` and `resonant_inelastic_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p01/questions.md b/docs/deployments/p01/questions.md
deleted file mode 100644
index acf0a5dadc6..00000000000
--- a/docs/deployments/p01/questions.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Open questions
-
-*What CORA needs the P01 team to confirm before the model can be trusted.*
-
-P01 was reverse-engineered from P01's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p01](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p01), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no physical detail (crystal cuts, energy ranges, bend radii, detector models). P01 is CORA's first PETRA III beamline and a further Tango / Sardana control floor (after MAX IV and ALBA). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: two optics hutches (OH1, OH2) feeding three experiment hutches (EH1, EH2, EH3), or a different layout? | Two `p01-oh*` optics hutches and three `p01-eh*` experiment hutches, read from the OnlineXML host names. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters, and whether gap_a/gap_b/taper_a/taper_b mean two sections or a canted arrangement. | An undulator source, 2.5-80 keV; gap / taper virtual axes only. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The Asset grouping of the registry's per-axis device list into instruments (one monochromator, one mirror, one sample stage). | The groupings on the [device pages](index.md), inferred from the axis name prefixes. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MONO-1 | Blocks-go-live | The double-crystal monochromator crystal cut (Si 111 / 311) and energy range. | A DCM bound to `Monochromator`; Bragg / energy virtual axes read from the registry. | The monochromator modelling. |
-| OPT-1 | Nice-to-have | The deflection-mirror coatings / stripes and incidence angles, the KB bend radii and focal sizes, the CRL lens count / material, and the diamond-monitor / RIXS-pre-optic roles. | Two OH1 mirrors and the EH3 KB pair bound to `Mirror`; the CRL bound to `Transfocator`; the diamond monitor bound to `FluxMonitor`; handles read, physical detail pending. | The optics Asset detail. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| NRS-1 | Blocks-go-live | The four EH1 high-resolution monochromators (400 / 1064 / 3D / 3W): which is in beam per Moessbauer isotope and resolution, and how the `hrm_ener` virtual axis couples them. | Four `Monochromator` Assets plus a `HighResMonoEnergy` `PseudoAxis`; selection per isotope pending. | The NRS instrument modelling. |
-| DIFF-1 | Blocks-go-live | The EH2 diffractometer geometry: the full circle count beyond theta / two-theta, and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (theta / two-theta), not the composed Diffractometer Assembly, until a detector arm is confirmed. | The diffractometer modelling. |
-| SAMPLE-1 | Nice-to-have | The EH3 RIXS sample-stage axes and sample-environment detail. | A `LinearStage` (x / y / b / rot / tilt) read from the registry. | The sample-stage modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector models per endstation (the EH1 NRS avalanche photodiode, the EH2 diffraction detector, the EH3 RIXS spectrometer detector), which the OnlineXML does not carry as motor rows. | Detector positioning stages bound to `LinearStage`; the detector devices named, not bound. | The detector modelling. |
-| DIAG-1 | Nice-to-have | The beam-position-monitor, ion-chamber, and diamond-monitor handles and roles. | `FluxMonitor` positioning stages read from the registry. | The diagnostics modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P01 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do nuclear resonant scattering and RIXS enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `inelastic_x_ray_scattering` and `resonant_inelastic_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p01/techniques.md b/docs/deployments/p01/techniques.md
deleted file mode 100644
index 41d5262a140..00000000000
--- a/docs/deployments/p01/techniques.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Techniques
-
-*What the modelled part of P01 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P01 runs hard X-ray dynamics techniques (nuclear resonant scattering and resonant inelastic scattering) that earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## Nuclear resonant scattering (EH1)
-
-P01 sets the X-ray energy onto a Moessbauer isotope's nuclear resonance with the [double-crystal monochromator](source.md), then carves a meV / Moessbauer-energy bandwidth with the [high-resolution monochromator stack](sample.md) (the four nested / channel-cut HRMs). Scanning the high-resolution-monochromator energy axis while reading the time- and energy-resolved detector signal produces the nuclear inelastic / resonant spectrum.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Nuclear resonant scattering / nuclear inelastic scattering | `inelastic_x_ray_scattering` | the high-resolution-monochromator energy scan reading the avalanche-photodiode signal; no catalog Method fits, reuses the IXS slug ESRF ID28 / NSLS-II IXS share, a further consumer (`TECH-1`) |
-
-## Resonant inelastic X-ray scattering (EH3)
-
-P01's EH3 endstation focuses the beam with the [KB mirror pair](sample.md) onto the sample and analyzes the inelastically scattered photons on the spectrometer arm, scanning the incident energy against the analyzed energy to map the excitation spectrum.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | KB-focused incident beam analyzed on the EH3 spectrometer; reuses the RIXS slug SIX / ESRF ID32 share, a further consumer (`TECH-1`) |
-
-## Diffraction (EH2)
-
-P01's EH2 endstation carries a theta / two-theta [goniometer](sample.md) reading a detector on a positioning stage, for hard X-ray diffraction. The catalog carries no general diffraction Method today; the technique is noted, not bound, pending confirmation of the endstation's routine use (`TECH-1`, `DIFF-1`).
-
-## A new technique branch on familiar vocabulary
-
-P01 is the fleet's NRS / RIXS dynamics beamline. Its techniques are new to CORA's catalog (which is tomography- and MX-centric today), but they reuse the inelastic- and resonant-inelastic-scattering slugs already carried pending across the fleet (ESRF ID28 IXS, ESRF ID32 / SIX RIXS, NSLS-II IXS), so none forces a new Method to be coined now. The instrument anatomy reuses existing Families end to end: the monochromators bind `Monochromator`, the KB mirrors `Mirror`, the lens `Transfocator`, the stages `LinearStage` / `RotaryStage` / `Table`, the sample circle `Goniometer`.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the high-resolution-monochromator energy-scan sequences and their exposures, the RIXS incident-energy scans, the diffraction scans) are not written yet; they join as the deployment approaches the point where CORA drives P01. Whether the NRS / RIXS Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p02/governance.md b/docs/deployments/p02/governance.md
deleted file mode 100644
index 4bfbd5a612d..00000000000
--- a/docs/deployments/p02/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P02, and the trust shape that will gate it. First cut.*
-
-Governance at P02 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P02 is CORA's eighth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P02 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P02, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the OH1 optics and the two endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). A P02-specific note: P02 owns the OH1 high-heatload optics hutch shared with P03, so the optics enclosure's access state couples to the neighbouring beamline, part of the `PSS-1` question.
-
-P02 also carries the hazard classes that come with its endstations: a high-energy (~60 keV) beam, in-situ furnaces (the Anton-Paar) at P02.1, and the diamond-anvil-cell high-pressure environment at P02.2. Those land with the instruments that bring them when the deployment firms up; the pressure cell is modelled as a sample-environment `PressureCell` Asset, not a beam-steering device CORA drives.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P02, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p02/model.md b/docs/deployments/p02/model.md
deleted file mode 100644
index 83b5187e1de..00000000000
--- a/docs/deployments/p02/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P02 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P02 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P02 new
-
-P02 is an eighth beamline at an existing Site, and the fleet's high-energy diffraction beamline with two branches: P02.1 (powder / total scattering / PDF, ~60 keV) and P02.2 (extreme conditions, diamond-anvil cell). At the modelling level it brings the fleet's **second diamond-anvil-cell** endstation, binding the catalog `PressureCell` Family (graduated across 13-id and P02, with P02 the second consumer that earned it).
-
-## No new families (the DAC reuses the 13-id PressureCell)
-
-P02 coins no new Family. The monochromator binds `Monochromator`; the bendable HFM / VFM mirrors bind `Mirror`; the slits bind `Slit`; the sample stages bind `LinearStage`; the sample environment binds `TemperatureController`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`; the beam monitor binds `FluxMonitor`; and the diamond-anvil cell binds the catalog `PressureCell`.
-
-Adding P02 as `PressureCell`'s second consumer crossed the rule-of-three promotion threshold, so the Family graduated to the catalog (earned across 13-id and P02, `PRESSURE-1`), following the path the POLAR-family `PhaseRetarder`, `PolarizationAnalyzer`, and `Magnet` siblings took to catalog Families. This is the graduation guard working as designed.
-
-## The control plane
-
-P02 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the bendable HFM / VFM mirrors (curvature / ellipticity attribute motors), the Pilatus 1M + PerkinElmer high-energy detectors, and the Anton-Paar / Lakeshore sample environment. The handles are read from P02's public OnlineXML registry and carried confirm (`CTRL-1`). P02 owns the OH1 high-heatload optics hutch shared with P03. The powder / total-scattering / high-pressure acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
-- **The optics detail (`OPT-1`).** The DCM crystal cut and the bendable-mirror coatings / focusing recipes are carried confirm-pending.
-- **The motor-bank axis roles (`GROUP-1`).** The eh1a/b and eh2a/b banks carry no per-axis role; grouped as stage Assets.
-- **The pressure-cell control (`PRESSURE-1`).** The diamond-anvil-cell membrane / gas-loading / pressure control is not in the registry; the `PressureCell` Family is the catalog one (graduated across 13-id and P02), with the membrane / load control detail pending.
-- **The detector roster (`DET-1`).** The detector models, the powder-vs-PDF detector roles, and the P02.2 diffraction area detector are named, not fully bound.
-- **The CH dummy stubs (`STUB-1`).** The CH1 / CH2 `tangomotor` dummies are test / placeholder devices, noted not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The diffraction Methods (`TECH-1`).** Whether powder diffraction / total scattering enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p02_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p02/notes.md b/docs/deployments/p02/notes.md
new file mode 100644
index 00000000000..db92feae5d6
--- /dev/null
+++ b/docs/deployments/p02/notes.md
@@ -0,0 +1,144 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P02 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P02's diffraction techniques reuse Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
+
+### Powder diffraction (P02.1)
+
+P02.1 illuminates a powder / polycrystalline sample with a high-energy (~60 keV) monochromatic beam and reads the Debye-Scherrer rings on the [Pilatus 1M area detector](detector.md), with in-situ temperature control for parametric studies.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-energy powder diffraction | `powder_diffraction` | the powder sample read by the Pilatus 1M; reuses the `powder_diffraction` slug i11 / XPD share, a further consumer (`TECH-1`) |
+
+### Total scattering / PDF (P02.1)
+
+P02.1 also collects total scattering to high momentum transfer (the high-energy beam plus the [PerkinElmer flat-panel](detector.md)) for pair-distribution-function analysis of local / disordered structure.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Total scattering / pair-distribution-function | `total_scattering` | high-Q total scattering on the PerkinElmer flat-panel; reuses the `total_scattering` slug i15-1 / XPD share, a further consumer (`TECH-1`) |
+
+### High-pressure diffraction (P02.2)
+
+P02.2 puts the sample in a [diamond-anvil cell](sample.md) and collects diffraction under high pressure (and variable temperature), for extreme-conditions studies.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Diamond-anvil-cell high-pressure diffraction | `powder_diffraction` | high-pressure diffraction in the DAC; reuses the `powder_diffraction` slug, a further consumer (`TECH-1`, `PRESSURE-1`) |
+
+### A high-energy diffraction beamline on familiar vocabulary
+
+P02 is the fleet's high-energy powder / total-scattering beamline and its first diamond-anvil-cell extreme-conditions endstation. Its techniques reuse the `powder_diffraction` and `total_scattering` slugs already carried pending across the fleet (Diamond i11 / i15-1, NSLS-II XPD), so none forces a new Method now. The instrument anatomy reuses existing Families end to end: the monochromator binds `Monochromator`, the bendable mirrors `Mirror`, the detectors `Camera`, the sample environment `TemperatureController`, and the high-pressure cell the catalog `PressureCell` (graduated across 13-id and P02, with P02 the second consumer that earned it).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the powder-ring integration sequences, the high-Q PDF collection, the pressure-ramp diffraction loops) are not written yet; they join as the deployment approaches the point where CORA drives P02. Whether the diffraction Methods or the PressureCell Family enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P02, and the trust shape that will gate it. First cut.*
+
+Governance at P02 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P02 is CORA's eighth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P02 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P02, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the OH1 optics and the two endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). A P02-specific note: P02 owns the OH1 high-heatload optics hutch shared with P03, so the optics enclosure's access state couples to the neighbouring beamline, part of the `PSS-1` question.
+
+P02 also carries the hazard classes that come with its endstations: a high-energy (~60 keV) beam, in-situ furnaces (the Anton-Paar) at P02.1, and the diamond-anvil-cell high-pressure environment at P02.2. Those land with the instruments that bring them when the deployment firms up; the pressure cell is modelled as a sample-environment `PressureCell` Asset, not a beam-steering device CORA drives.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P02, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P02 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P02 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P02 new
+
+P02 is an eighth beamline at an existing Site, and the fleet's high-energy diffraction beamline with two branches: P02.1 (powder / total scattering / PDF, ~60 keV) and P02.2 (extreme conditions, diamond-anvil cell). At the modelling level it brings the fleet's **second diamond-anvil-cell** endstation, binding the catalog `PressureCell` Family (graduated across 13-id and P02, with P02 the second consumer that earned it).
+
+### No new families (the DAC reuses the 13-id PressureCell)
+
+P02 coins no new Family. The monochromator binds `Monochromator`; the bendable HFM / VFM mirrors bind `Mirror`; the slits bind `Slit`; the sample stages bind `LinearStage`; the sample environment binds `TemperatureController`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`; the beam monitor binds `FluxMonitor`; and the diamond-anvil cell binds the catalog `PressureCell`.
+
+Adding P02 as `PressureCell`'s second consumer crossed the rule-of-three promotion threshold, so the Family graduated to the catalog (earned across 13-id and P02, `PRESSURE-1`), following the path the POLAR-family `PhaseRetarder`, `PolarizationAnalyzer`, and `Magnet` siblings took to catalog Families. This is the graduation guard working as designed.
+
+### The control plane
+
+P02 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the bendable HFM / VFM mirrors (curvature / ellipticity attribute motors), the Pilatus 1M + PerkinElmer high-energy detectors, and the Anton-Paar / Lakeshore sample environment. The handles are read from P02's public OnlineXML registry and carried confirm (`CTRL-1`). P02 owns the OH1 high-heatload optics hutch shared with P03. The powder / total-scattering / high-pressure acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
+- **The optics detail (`OPT-1`).** The DCM crystal cut and the bendable-mirror coatings / focusing recipes are carried confirm-pending.
+- **The motor-bank axis roles (`GROUP-1`).** The eh1a/b and eh2a/b banks carry no per-axis role; grouped as stage Assets.
+- **The pressure-cell control (`PRESSURE-1`).** The diamond-anvil-cell membrane / gas-loading / pressure control is not in the registry; the `PressureCell` Family is the catalog one (graduated across 13-id and P02), with the membrane / load control detail pending.
+- **The detector roster (`DET-1`).** The detector models, the powder-vs-PDF detector roles, and the P02.2 diffraction area detector are named, not fully bound.
+- **The CH dummy stubs (`STUB-1`).** The CH1 / CH2 `tangomotor` dummies are test / placeholder devices, noted not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The diffraction Methods (`TECH-1`).** Whether powder diffraction / total scattering enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p02_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P02 team to confirm before the model can be trusted.*
+
+P02 was reverse-engineered from P02's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p02](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p02), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, pressure-cell detail, or energy calibration. P02 is CORA's eighth PETRA III beamline and the fleet's second diamond-anvil-cell deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a shared OH1 optics hutch feeding a P02.1 powder endstation and a P02.2 extreme-conditions endstation? | A `p02-oh1` optics hutch and `p02-1-powder` / `p02-2-extreme` endstations, read from the device-name prefixes. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`eh1a/b`, `eh2a/b`, the OH1 bank). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+| STUB-1 | Nice-to-have | The CH1 / CH2 `tangomotor` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The CH stub status. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The DCM crystal cut, the bendable HFM / VFM mirror coatings and focusing recipes, and the slit / CRL detail. | A DCM `Monochromator`, two bendable `Mirror`s, and `Slit`s; physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| PRESSURE-1 | Blocks-go-live | The P02.2 diamond-anvil-cell control: the membrane / gas-loading / pressure-ramp interface, and the cell's positioning stages. | A `PressureCell` Asset (the catalog Family, graduated across 13-id and P02); membrane / load control pending. | The pressure-cell modelling. |
+| TEMP-1 | Nice-to-have | The P02.1 sample-environment sensor / setpoint handles (Anton-Paar, Eurotherm, Lakeshore). | `TemperatureController` controllers; in-situ furnace / cryo. | The sample-environment modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per branch, the powder-vs-PDF detector roles (Pilatus 1M vs PerkinElmer), and the P02.2 high-pressure diffraction area detector. | `Camera` area detectors plus `EnergyDispersiveSpectrometer` fluorescence; roles pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P02 device, the shared OH1 optics with P03, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; OH1 shared with P03. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics access coupling with P03, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do powder diffraction and total scattering / PDF enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `powder_diffraction` / `total_scattering` slugs i11 / i15-1 / XPD share; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p02/questions.md b/docs/deployments/p02/questions.md
deleted file mode 100644
index be854ec3b1f..00000000000
--- a/docs/deployments/p02/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the P02 team to confirm before the model can be trusted.*
-
-P02 was reverse-engineered from P02's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p02](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p02), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, pressure-cell detail, or energy calibration. P02 is CORA's eighth PETRA III beamline and the fleet's second diamond-anvil-cell deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a shared OH1 optics hutch feeding a P02.1 powder endstation and a P02.2 extreme-conditions endstation? | A `p02-oh1` optics hutch and `p02-1-powder` / `p02-2-extreme` endstations, read from the device-name prefixes. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`eh1a/b`, `eh2a/b`, the OH1 bank). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-| STUB-1 | Nice-to-have | The CH1 / CH2 `tangomotor` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The CH stub status. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The DCM crystal cut, the bendable HFM / VFM mirror coatings and focusing recipes, and the slit / CRL detail. | A DCM `Monochromator`, two bendable `Mirror`s, and `Slit`s; physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| PRESSURE-1 | Blocks-go-live | The P02.2 diamond-anvil-cell control: the membrane / gas-loading / pressure-ramp interface, and the cell's positioning stages. | A `PressureCell` Asset (the catalog Family, graduated across 13-id and P02); membrane / load control pending. | The pressure-cell modelling. |
-| TEMP-1 | Nice-to-have | The P02.1 sample-environment sensor / setpoint handles (Anton-Paar, Eurotherm, Lakeshore). | `TemperatureController` controllers; in-situ furnace / cryo. | The sample-environment modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per branch, the powder-vs-PDF detector roles (Pilatus 1M vs PerkinElmer), and the P02.2 high-pressure diffraction area detector. | `Camera` area detectors plus `EnergyDispersiveSpectrometer` fluorescence; roles pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P02 device, the shared OH1 optics with P03, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; OH1 shared with P03. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics access coupling with P03, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do powder diffraction and total scattering / PDF enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `powder_diffraction` / `total_scattering` slugs i11 / i15-1 / XPD share; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p02/techniques.md b/docs/deployments/p02/techniques.md
deleted file mode 100644
index 00a5b112676..00000000000
--- a/docs/deployments/p02/techniques.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Techniques
-
-*What the modelled part of P02 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P02's diffraction techniques reuse Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
-
-## Powder diffraction (P02.1)
-
-P02.1 illuminates a powder / polycrystalline sample with a high-energy (~60 keV) monochromatic beam and reads the Debye-Scherrer rings on the [Pilatus 1M area detector](detector.md), with in-situ temperature control for parametric studies.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-energy powder diffraction | `powder_diffraction` | the powder sample read by the Pilatus 1M; reuses the `powder_diffraction` slug i11 / XPD share, a further consumer (`TECH-1`) |
-
-## Total scattering / PDF (P02.1)
-
-P02.1 also collects total scattering to high momentum transfer (the high-energy beam plus the [PerkinElmer flat-panel](detector.md)) for pair-distribution-function analysis of local / disordered structure.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Total scattering / pair-distribution-function | `total_scattering` | high-Q total scattering on the PerkinElmer flat-panel; reuses the `total_scattering` slug i15-1 / XPD share, a further consumer (`TECH-1`) |
-
-## High-pressure diffraction (P02.2)
-
-P02.2 puts the sample in a [diamond-anvil cell](sample.md) and collects diffraction under high pressure (and variable temperature), for extreme-conditions studies.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Diamond-anvil-cell high-pressure diffraction | `powder_diffraction` | high-pressure diffraction in the DAC; reuses the `powder_diffraction` slug, a further consumer (`TECH-1`, `PRESSURE-1`) |
-
-## A high-energy diffraction beamline on familiar vocabulary
-
-P02 is the fleet's high-energy powder / total-scattering beamline and its first diamond-anvil-cell extreme-conditions endstation. Its techniques reuse the `powder_diffraction` and `total_scattering` slugs already carried pending across the fleet (Diamond i11 / i15-1, NSLS-II XPD), so none forces a new Method now. The instrument anatomy reuses existing Families end to end: the monochromator binds `Monochromator`, the bendable mirrors `Mirror`, the detectors `Camera`, the sample environment `TemperatureController`, and the high-pressure cell the catalog `PressureCell` (graduated across 13-id and P02, with P02 the second consumer that earned it).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the powder-ring integration sequences, the high-Q PDF collection, the pressure-ramp diffraction loops) are not written yet; they join as the deployment approaches the point where CORA drives P02. Whether the diffraction Methods or the PressureCell Family enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p03/governance.md b/docs/deployments/p03/governance.md
deleted file mode 100644
index 6a62c5a10c9..00000000000
--- a/docs/deployments/p03/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P03, and the trust shape that will gate it. First cut.*
-
-Governance at P03 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P03 is CORA's fifth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01, P04, P06, P11), until DESY staff confirm them (`GOV-1`). P03 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P03, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the shared optics and the two endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). The nanofocus GINIX experiment shutter is read from the registry but its safety role is not (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-A P03-specific governance note: P03 shares its high-heatload optics with P02, so the optics enclosure's safety and access state is coupled to the neighbouring beamline; how the shared-optics permit is modelled is part of the `HOST-1` / `PSS-1` questions.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P03, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p03/model.md b/docs/deployments/p03/model.md
deleted file mode 100644
index 74eb52f9909..00000000000
--- a/docs/deployments/p03/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P03 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P03 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P03 new
-
-P03 is a fifth beamline at an existing Site, and the fleet's entry into small-angle / wide-angle scattering. It is the MiNaXS beamline: micro- and nanofocus SAXS / WAXS at 9-23 keV across two endstations (the microfocus endstation and the nanofocus GINIX endstation with its waveguide nano-focusing). It brings a two-endstation-sharing-one-optics-chain layout, the shared P02 / P03 high-heatload optics, and two new Tango motion-controller protocols (Galil DMC slit controllers, SmarPod controllers), but no new Family or Method.
-
-## No new families (the scattering instrument reuses existing vocabulary)
-
-P03 coins no new Family. The multilayer monochromator binds `Monochromator`; the mirrors bind `Mirror`; the CRL and GINIX hexapods bind `Hexapod`; the waveguide stages bind `LinearStage`; the slits bind `Slit`; the sample rotation binds `RotaryStage`; the sample environment binds `TemperatureController`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`; the shutter binds `Shutter`. Nothing in the catalog changes.
-
-## The control plane
-
-P03 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, and adds two controller protocols new to the set: Galil DMC slit controllers and SmarPod controllers (the GINIX waveguide). The handles are read from P03's public OnlineXML registry and carried confirm (`CTRL-1`); the shared P02 / P03 optics mean the first defining slit reports on the P02 host (`HOST-1`). The SAXS / WAXS acquisition (the sample scan coupled to the Pilatus, the GINIX waveguide-scanning nano-imaging) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
-- **The optics physical detail (`OPT-1`).** The multilayer d-spacing, the mirror coatings, and the CRL / waveguide focal sizes are carried confirm-pending.
-- **The motor-bank axis roles (`GROUP-1`).** The `expmi_mot` and `mot` banks carry no per-axis role in the registry; grouped as sample-stage Assets, roles pending.
-- **The GINIX geometry (`SAMPLE-1`).** The waveguide-to-sample geometry and the sample-hexapod / rotation detail are pending.
-- **The detector roster (`DET-1`).** The SAXS-vs-WAXS detector assignment, the sample-to-detector distance, and the detector models are named, not fully bound.
-- **The host mapping (`HOST-1`).** The shared P02 / P03 optics host and the bare-host Lambda are flagged; whether shared Tango DB or registry artifact is pending.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The scattering Methods (`TECH-1`).** Whether SAXS / WAXS enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p03_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p03/notes.md b/docs/deployments/p03/notes.md
new file mode 100644
index 00000000000..c6a28b12173
--- /dev/null
+++ b/docs/deployments/p03/notes.md
@@ -0,0 +1,134 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P03 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P03 runs small- and wide-angle X-ray scattering, which earns no catalog Method today, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
+
+### Small-angle X-ray scattering
+
+P03 focuses the beam (the multilayer monochromator feeding the CRL or the GINIX waveguide) to a micro or nano spot, illuminates the sample, and reads the small-angle scattering on the [Pilatus area detector](detector.md) at a distance.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Small-angle X-ray scattering (SAXS) | `small_angle_scattering` | the focused beam on the sample read by the Pilatus at a SAXS distance; reuses the `small_angle_scattering` slug, a further consumer (`TECH-1`) |
+
+### Wide-angle X-ray scattering
+
+The microfocus endstation's Pilatus 1M reads the wide-angle scattering simultaneously with the SAXS signal.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Wide-angle X-ray scattering (WAXS) | `wide_angle_scattering` | the Pilatus 1M reading the wide-angle signal; reuses the `wide_angle_scattering` slug, a further consumer (`TECH-1`) |
+
+### A new technique family on familiar vocabulary
+
+P03 is PETRA III's first SAXS / WAXS beamline. Its techniques reuse the `small_angle_scattering` and `wide_angle_scattering` slugs already in the catalog's method vocabulary (the same slugs the NSLS-II SMI / CMS and Diamond i22 scattering beamlines carry), so neither forces a new Method to be coined now. The instrument anatomy reuses existing Families: the monochromator binds `Monochromator`, the mirrors `Mirror`, the CRL and GINIX hexapods `Hexapod`, the slits `Slit`, the detectors `Camera`. The GINIX nanofocus adds a waveguide (modelled as a `Hexapod` carrier plus `LinearStage` waveguide stages) and a sample rotation (`RotaryStage`) that suits scanning / nano-imaging, but no new Family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the SAXS / WAXS exposure sequences, the GINIX scanning / waveguide alignment, the grazing-incidence variants) are not written yet; they join as the deployment approaches the point where CORA drives P03. Whether the scattering Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P03, and the trust shape that will gate it. First cut.*
+
+Governance at P03 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P03 is CORA's fifth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01, P04, P06, P11), until DESY staff confirm them (`GOV-1`). P03 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P03, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the shared optics and the two endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). The nanofocus GINIX experiment shutter is read from the registry but its safety role is not (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+A P03-specific governance note: P03 shares its high-heatload optics with P02, so the optics enclosure's safety and access state is coupled to the neighbouring beamline; how the shared-optics permit is modelled is part of the `HOST-1` / `PSS-1` questions.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P03, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P03 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P03 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P03 new
+
+P03 is a fifth beamline at an existing Site, and the fleet's entry into small-angle / wide-angle scattering. It is the MiNaXS beamline: micro- and nanofocus SAXS / WAXS at 9-23 keV across two endstations (the microfocus endstation and the nanofocus GINIX endstation with its waveguide nano-focusing). It brings a two-endstation-sharing-one-optics-chain layout, the shared P02 / P03 high-heatload optics, and two new Tango motion-controller protocols (Galil DMC slit controllers, SmarPod controllers), but no new Family or Method.
+
+### No new families (the scattering instrument reuses existing vocabulary)
+
+P03 coins no new Family. The multilayer monochromator binds `Monochromator`; the mirrors bind `Mirror`; the CRL and GINIX hexapods bind `Hexapod`; the waveguide stages bind `LinearStage`; the slits bind `Slit`; the sample rotation binds `RotaryStage`; the sample environment binds `TemperatureController`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`; the shutter binds `Shutter`. Nothing in the catalog changes.
+
+### The control plane
+
+P03 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, and adds two controller protocols new to the set: Galil DMC slit controllers and SmarPod controllers (the GINIX waveguide). The handles are read from P03's public OnlineXML registry and carried confirm (`CTRL-1`); the shared P02 / P03 optics mean the first defining slit reports on the P02 host (`HOST-1`). The SAXS / WAXS acquisition (the sample scan coupled to the Pilatus, the GINIX waveguide-scanning nano-imaging) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
+- **The optics physical detail (`OPT-1`).** The multilayer d-spacing, the mirror coatings, and the CRL / waveguide focal sizes are carried confirm-pending.
+- **The motor-bank axis roles (`GROUP-1`).** The `expmi_mot` and `mot` banks carry no per-axis role in the registry; grouped as sample-stage Assets, roles pending.
+- **The GINIX geometry (`SAMPLE-1`).** The waveguide-to-sample geometry and the sample-hexapod / rotation detail are pending.
+- **The detector roster (`DET-1`).** The SAXS-vs-WAXS detector assignment, the sample-to-detector distance, and the detector models are named, not fully bound.
+- **The host mapping (`HOST-1`).** The shared P02 / P03 optics host and the bare-host Lambda are flagged; whether shared Tango DB or registry artifact is pending.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The scattering Methods (`TECH-1`).** Whether SAXS / WAXS enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p03_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P03 team to confirm before the model can be trusted.*
+
+P03 was reverse-engineered from P03's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p03](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p03), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no focal sizes, multilayer d-spacing, or energy calibration. P03 is CORA's fifth PETRA III beamline and its first SAXS / WAXS beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: shared optics feeding a microfocus endstation and a nanofocus GINIX endstation? | A `p03-optics` section (shared with P02) and two `p03-microfocus` / `p03-nanofocus` endstations. | The Enclosure grouping. |
+| HOST-1 | Nice-to-have | The first defining slit reports on the P02 optics host (`haspp02oh1`) and a Lambda on the bare `petra3` host. Shared Tango DB hosts, or registry artifacts? | The shared P02 / P03 optics are homed in `p03-optics`; the hosts are flagged. | The device-to-host mapping. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`expmi_mot01..64` microfocus, `mot01..40` nanofocus). | Grouped as sample-stage Assets carrying the bank prefix; per-axis roles pending. | The sample-stage Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
+| OPT-1 | Blocks-go-live | The multilayer monochromator d-spacing, the mirror coatings, and the CRL / GINIX-waveguide focal sizes. | A multilayer `Monochromator`, two `Mirror`s, a CRL `Hexapod`, and the GINIX waveguide; handles read, physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Nice-to-have | The GINIX waveguide-to-sample geometry and the sample-hexapod / rotation detail. | A `Hexapod` sample stage and a `RotaryStage` rotation; geometry pending. | The GINIX sample modelling. |
+| TEMP-1 | Nice-to-have | The Eurotherm 2604 sample-environment sensor / setpoint handles. | A `TemperatureController` sample environment. | The temperature-control modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per experiment, the SAXS-vs-WAXS assignment (Pilatus 300k / 1M), the sample-to-detector distance, and the fluorescence-detector channel count. | `Camera` Pilatus detectors plus `EnergyDispersiveSpectrometer` MCA / XIA detectors; assignment pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P03 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the photon / front-end shutters, and the role of the GINIX experiment shutter (absent / partial in the OnlineXML). | Permit leaves and shutters to be named; the GINIX shutter bound to `Shutter`, safety role pending. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level), and the shared-optics permit coupling with P02. | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do small-angle and wide-angle X-ray scattering enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `small_angle_scattering` and `wide_angle_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p03/questions.md b/docs/deployments/p03/questions.md
deleted file mode 100644
index 1415da2345b..00000000000
--- a/docs/deployments/p03/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the P03 team to confirm before the model can be trusted.*
-
-P03 was reverse-engineered from P03's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p03](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p03), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no focal sizes, multilayer d-spacing, or energy calibration. P03 is CORA's fifth PETRA III beamline and its first SAXS / WAXS beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: shared optics feeding a microfocus endstation and a nanofocus GINIX endstation? | A `p03-optics` section (shared with P02) and two `p03-microfocus` / `p03-nanofocus` endstations. | The Enclosure grouping. |
-| HOST-1 | Nice-to-have | The first defining slit reports on the P02 optics host (`haspp02oh1`) and a Lambda on the bare `petra3` host. Shared Tango DB hosts, or registry artifacts? | The shared P02 / P03 optics are homed in `p03-optics`; the hosts are flagged. | The device-to-host mapping. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`expmi_mot01..64` microfocus, `mot01..40` nanofocus). | Grouped as sample-stage Assets carrying the bank prefix; per-axis roles pending. | The sample-stage Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
-| OPT-1 | Blocks-go-live | The multilayer monochromator d-spacing, the mirror coatings, and the CRL / GINIX-waveguide focal sizes. | A multilayer `Monochromator`, two `Mirror`s, a CRL `Hexapod`, and the GINIX waveguide; handles read, physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Nice-to-have | The GINIX waveguide-to-sample geometry and the sample-hexapod / rotation detail. | A `Hexapod` sample stage and a `RotaryStage` rotation; geometry pending. | The GINIX sample modelling. |
-| TEMP-1 | Nice-to-have | The Eurotherm 2604 sample-environment sensor / setpoint handles. | A `TemperatureController` sample environment. | The temperature-control modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per experiment, the SAXS-vs-WAXS assignment (Pilatus 300k / 1M), the sample-to-detector distance, and the fluorescence-detector channel count. | `Camera` Pilatus detectors plus `EnergyDispersiveSpectrometer` MCA / XIA detectors; assignment pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P03 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the photon / front-end shutters, and the role of the GINIX experiment shutter (absent / partial in the OnlineXML). | Permit leaves and shutters to be named; the GINIX shutter bound to `Shutter`, safety role pending. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level), and the shared-optics permit coupling with P02. | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do small-angle and wide-angle X-ray scattering enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `small_angle_scattering` and `wide_angle_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p03/techniques.md b/docs/deployments/p03/techniques.md
deleted file mode 100644
index 3dfc1a208dc..00000000000
--- a/docs/deployments/p03/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P03 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P03 runs small- and wide-angle X-ray scattering, which earns no catalog Method today, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
-
-## Small-angle X-ray scattering
-
-P03 focuses the beam (the multilayer monochromator feeding the CRL or the GINIX waveguide) to a micro or nano spot, illuminates the sample, and reads the small-angle scattering on the [Pilatus area detector](detector.md) at a distance.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Small-angle X-ray scattering (SAXS) | `small_angle_scattering` | the focused beam on the sample read by the Pilatus at a SAXS distance; reuses the `small_angle_scattering` slug, a further consumer (`TECH-1`) |
-
-## Wide-angle X-ray scattering
-
-The microfocus endstation's Pilatus 1M reads the wide-angle scattering simultaneously with the SAXS signal.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Wide-angle X-ray scattering (WAXS) | `wide_angle_scattering` | the Pilatus 1M reading the wide-angle signal; reuses the `wide_angle_scattering` slug, a further consumer (`TECH-1`) |
-
-## A new technique family on familiar vocabulary
-
-P03 is PETRA III's first SAXS / WAXS beamline. Its techniques reuse the `small_angle_scattering` and `wide_angle_scattering` slugs already in the catalog's method vocabulary (the same slugs the NSLS-II SMI / CMS and Diamond i22 scattering beamlines carry), so neither forces a new Method to be coined now. The instrument anatomy reuses existing Families: the monochromator binds `Monochromator`, the mirrors `Mirror`, the CRL and GINIX hexapods `Hexapod`, the slits `Slit`, the detectors `Camera`. The GINIX nanofocus adds a waveguide (modelled as a `Hexapod` carrier plus `LinearStage` waveguide stages) and a sample rotation (`RotaryStage`) that suits scanning / nano-imaging, but no new Family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the SAXS / WAXS exposure sequences, the GINIX scanning / waveguide alignment, the grazing-incidence variants) are not written yet; they join as the deployment approaches the point where CORA drives P03. Whether the scattering Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p04/governance.md b/docs/deployments/p04/governance.md
deleted file mode 100644
index 56d24eedfaf..00000000000
--- a/docs/deployments/p04/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P04, and the trust shape that will gate it. First cut.*
-
-Governance at P04 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P04 is CORA's second PETRA III beamline, not its first: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01), until DESY staff confirm them (`GOV-1`). P04 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P04, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics section and the two experiment endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P04, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p04/model.md b/docs/deployments/p04/model.md
deleted file mode 100644
index f5c88a1bda5..00000000000
--- a/docs/deployments/p04/model.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P04 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P04 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (incident-energy axis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P04 new
-
-P04 is a second beamline at an existing Site, and PETRA III's entry into the soft X-ray regime (the fleet's soft X-ray line was opened by NSLS-II SIX). It **binds the catalog `GratingMonochromator` Family** (introduced at SIX, graduated at CSX): its monochromator is a plane-grating monochromator (the soft X-ray analog of the crystal `Monochromator`), not the Bragg crystal mono the hard X-ray beamlines use. Its science is soft X-ray spectroscopy at 250-3000 eV (XAS via total electron yield, and photoemission), fed by a variable-polarization APPLE-II-type undulator.
-
-## No new families (the one new binding is already in the catalog)
-
-P04 coins no new Family. The plane-grating monochromator binds the catalog `GratingMonochromator` (its first deployment, but the Family exists); the undulator binds `InsertionDevice`; the mirrors bind `Mirror`; the slits bind `Slit`; the sample manipulators bind `Manipulator`; the diagnostic cameras bind `Camera`; the electrometers bind `FluxMonitor`; the virtual axes bind `PseudoAxis`; and the motorized phosphor screens bind the catalog `Screen` Family (the 2-BM `FLAG-1` precedent). Nothing in the catalog changes.
-
-## The control plane
-
-P04 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as P01. The soft X-ray specifics are the device classes (the `MonoP04` plane-grating monochromator, the `UndulatorP04` variable-polarization undulator, the SmarPod-style `spk` mirror controllers, the `Keithley6517A` electrometers, the `TangoVimba` diagnostic cameras). The handles are read from P04's public OnlineXML registry and carried confirm (`CTRL-1`); some optics report on the `haspp04exp2` host but are the optics section (`HOST-1`). The soft X-ray absorption acquisition (the undulator + PGM photon-energy scan read against the electrometer) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The undulator polarization control (`SRC-1`).** The OnlineXML exposes the gap, not the APPLE-II row-phase / polarization axes; carried pending.
-- **The optics physical detail (`OPT-1`).** The grating line densities, the included-angle / c-value mode, the mirror coatings, and the exit-slit calibration are carried confirm-pending.
-- **The manipulator axis roles (`GROUP-1`).** The `exp1_mot01..16` and `ps2.01..14` banks carry no per-axis role in the registry; grouped as `Manipulator` Assets, roles pending.
-- **The EXSU2 sub-roles (`EXSU-1`).** The exit-shutter unit's slit / bpm / baffle breakdown is pending.
-- **The detection channels (`DET-1`).** The electrometer measured channels and the photoemission analyzer (not a motor row) are named, not bound.
-- **The host mapping (`HOST-1`).** The optics report on the experiment host; whether this is a shared Tango DB or a registry artifact is pending.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The soft X-ray Methods (`TECH-1`).** Whether XAS and photoemission enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p04_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p04/notes.md b/docs/deployments/p04/notes.md
new file mode 100644
index 00000000000..3aad8856957
--- /dev/null
+++ b/docs/deployments/p04/notes.md
@@ -0,0 +1,128 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P04 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P04 runs soft X-ray spectroscopy, which earns no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### Soft X-ray absorption spectroscopy
+
+P04 sets the photon energy (250-3000 eV) by coupling the [variable-polarization undulator](source.md) and the [plane-grating monochromator](source.md), then scans it across an absorption edge while reading the sample drain current on the [electrometer](detector.md) (total electron yield).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Soft X-ray absorption (XAS / NEXAFS) | `xas_spectroscopy` | the undulator + PGM photon-energy scan reading the Keithley electrometer; reuses the `xas_spectroscopy` slug four sites share, a further consumer (`TECH-1`) |
+
+### Photoemission
+
+P04's variable polarization and soft X-ray energy range suit photoemission on the EXP endstations (the analyzer is an endstation instrument not exposed as a motor in the registry).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Soft X-ray photoemission | `angle_resolved_photoemission` | photoemission on the EXP endstations; reuses the `angle_resolved_photoemission` slug, a further consumer (`TECH-1`) |
+
+### A new technique regime on mostly familiar vocabulary
+
+P04 is the fleet's soft X-ray spectroscopy beamline. Its energy regime is new (250-3000 eV, below the hard X-ray beamlines), and it forces the one genuinely new device binding, the `GratingMonochromator` (the soft X-ray analog of the crystal `Monochromator`). The techniques themselves reuse the `xas_spectroscopy` and `angle_resolved_photoemission` slugs already carried pending across the fleet, so neither forces a new Method to be coined now. The rest of the instrument anatomy reuses existing Families: the undulator binds `InsertionDevice`, the mirrors `Mirror`, the slits `Slit`, the manipulators `Manipulator`, the diagnostics `Camera` / `FluxMonitor` / `Screen`.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the photon-energy-scan sequences and their dwell times, the polarization switching, the photoemission analyzer sweeps) are not written yet; they join as the deployment approaches the point where CORA drives P04. Whether the soft X-ray Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P04, and the trust shape that will gate it. First cut.*
+
+Governance at P04 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P04 is CORA's second PETRA III beamline, not its first: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01), until DESY staff confirm them (`GOV-1`). P04 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P04, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics section and the two experiment endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P04, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P04 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P04 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (incident-energy axis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P04 new
+
+P04 is a second beamline at an existing Site, and PETRA III's entry into the soft X-ray regime (the fleet's soft X-ray line was opened by NSLS-II SIX). It **binds the catalog `GratingMonochromator` Family** (introduced at SIX, graduated at CSX): its monochromator is a plane-grating monochromator (the soft X-ray analog of the crystal `Monochromator`), not the Bragg crystal mono the hard X-ray beamlines use. Its science is soft X-ray spectroscopy at 250-3000 eV (XAS via total electron yield, and photoemission), fed by a variable-polarization APPLE-II-type undulator.
+
+### No new families (the one new binding is already in the catalog)
+
+P04 coins no new Family. The plane-grating monochromator binds the catalog `GratingMonochromator` (its first deployment, but the Family exists); the undulator binds `InsertionDevice`; the mirrors bind `Mirror`; the slits bind `Slit`; the sample manipulators bind `Manipulator`; the diagnostic cameras bind `Camera`; the electrometers bind `FluxMonitor`; the virtual axes bind `PseudoAxis`; and the motorized phosphor screens bind the catalog `Screen` Family (the 2-BM `FLAG-1` precedent). Nothing in the catalog changes.
+
+### The control plane
+
+P04 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as P01. The soft X-ray specifics are the device classes (the `MonoP04` plane-grating monochromator, the `UndulatorP04` variable-polarization undulator, the SmarPod-style `spk` mirror controllers, the `Keithley6517A` electrometers, the `TangoVimba` diagnostic cameras). The handles are read from P04's public OnlineXML registry and carried confirm (`CTRL-1`); some optics report on the `haspp04exp2` host but are the optics section (`HOST-1`). The soft X-ray absorption acquisition (the undulator + PGM photon-energy scan read against the electrometer) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The undulator polarization control (`SRC-1`).** The OnlineXML exposes the gap, not the APPLE-II row-phase / polarization axes; carried pending.
+- **The optics physical detail (`OPT-1`).** The grating line densities, the included-angle / c-value mode, the mirror coatings, and the exit-slit calibration are carried confirm-pending.
+- **The manipulator axis roles (`GROUP-1`).** The `exp1_mot01..16` and `ps2.01..14` banks carry no per-axis role in the registry; grouped as `Manipulator` Assets, roles pending.
+- **The EXSU2 sub-roles (`EXSU-1`).** The exit-shutter unit's slit / bpm / baffle breakdown is pending.
+- **The detection channels (`DET-1`).** The electrometer measured channels and the photoemission analyzer (not a motor row) are named, not bound.
+- **The host mapping (`HOST-1`).** The optics report on the experiment host; whether this is a shared Tango DB or a registry artifact is pending.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The soft X-ray Methods (`TECH-1`).** Whether XAS and photoemission enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p04_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P04 team to confirm before the model can be trusted.*
+
+P04 was reverse-engineered from P04's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p04](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p04), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no grating line densities, polarization modes, or energy calibration. P04 is CORA's second PETRA III beamline and PETRA III's first soft X-ray / grating-monochromator deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a soft X-ray optics section feeding two experiment endstations (EXP1, EXP2)? | A `p04-optics` section and two `p04-exp*` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
+| HOST-1 | Nice-to-have | The optics (undulator, PGM, mirrors, exit slits) report on the `haspp04exp2` Tango host. Is that a shared Tango DB host for the optics, or a registry artifact? | The optics are the optics section (`p04-optics`); the host is flagged. | The optics-to-host mapping. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the manipulator banks (`exp1_mot01..16`, `ps2.01..14`, `exp2_mot06/08`). | Grouped as `Manipulator` Assets carrying the handles; per-axis roles pending. | The sample-stage Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The variable-polarization undulator: the polarization modes (H / V / circular) and the row-phase axes that set them. | An APPLE-II-type undulator, 250-3000 eV; gap read, row-phase axes pending. | The source Asset detail. |
+| OPT-1 | Blocks-go-live | The plane-grating monochromator grating line densities and mode (included angle / c-value), the three mirror coatings and roles, and the exit-slit calibration. | A `GratingMonochromator`, three `Mirror`s, and exit `Slit`s; handles read, physical detail pending. | The optics modelling. |
+
+### Sample and detection
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| EXSU-1 | Nice-to-have | The EXP2 exit-shutter unit (EXSU2) sub-roles: slit (Spalt), translation, beam-position monitor, baffle. | Modelled as a beam-defining `Slit`; the bpm / baffle roles pending. | The EXSU2 modelling. |
+| DET-1 | Blocks-go-live | The electrometer measured channels (drain current vs I0) and the photoemission analyzer (the endstation spectrometer, not a motor row). | `FluxMonitor` electrometers; the analyzer named, not bound. | The detection modelling. |
+| DIAG-1 | Nice-to-have | The EXP2 diagnostic-screen positions and the camera-to-screen mapping. | Motorized `Screen`s imaged by `Camera`s; positions pending. | The diagnostics modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P04 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do soft X-ray absorption and photoemission enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `xas_spectroscopy` and `angle_resolved_photoemission` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p04/questions.md b/docs/deployments/p04/questions.md
deleted file mode 100644
index b30892a69ef..00000000000
--- a/docs/deployments/p04/questions.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Open questions
-
-*What CORA needs the P04 team to confirm before the model can be trusted.*
-
-P04 was reverse-engineered from P04's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p04](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p04), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no grating line densities, polarization modes, or energy calibration. P04 is CORA's second PETRA III beamline and PETRA III's first soft X-ray / grating-monochromator deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a soft X-ray optics section feeding two experiment endstations (EXP1, EXP2)? | A `p04-optics` section and two `p04-exp*` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
-| HOST-1 | Nice-to-have | The optics (undulator, PGM, mirrors, exit slits) report on the `haspp04exp2` Tango host. Is that a shared Tango DB host for the optics, or a registry artifact? | The optics are the optics section (`p04-optics`); the host is flagged. | The optics-to-host mapping. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the manipulator banks (`exp1_mot01..16`, `ps2.01..14`, `exp2_mot06/08`). | Grouped as `Manipulator` Assets carrying the handles; per-axis roles pending. | The sample-stage Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The variable-polarization undulator: the polarization modes (H / V / circular) and the row-phase axes that set them. | An APPLE-II-type undulator, 250-3000 eV; gap read, row-phase axes pending. | The source Asset detail. |
-| OPT-1 | Blocks-go-live | The plane-grating monochromator grating line densities and mode (included angle / c-value), the three mirror coatings and roles, and the exit-slit calibration. | A `GratingMonochromator`, three `Mirror`s, and exit `Slit`s; handles read, physical detail pending. | The optics modelling. |
-
-## Sample and detection
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| EXSU-1 | Nice-to-have | The EXP2 exit-shutter unit (EXSU2) sub-roles: slit (Spalt), translation, beam-position monitor, baffle. | Modelled as a beam-defining `Slit`; the bpm / baffle roles pending. | The EXSU2 modelling. |
-| DET-1 | Blocks-go-live | The electrometer measured channels (drain current vs I0) and the photoemission analyzer (the endstation spectrometer, not a motor row). | `FluxMonitor` electrometers; the analyzer named, not bound. | The detection modelling. |
-| DIAG-1 | Nice-to-have | The EXP2 diagnostic-screen positions and the camera-to-screen mapping. | Motorized `Screen`s imaged by `Camera`s; positions pending. | The diagnostics modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P04 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do soft X-ray absorption and photoemission enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `xas_spectroscopy` and `angle_resolved_photoemission` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p04/techniques.md b/docs/deployments/p04/techniques.md
deleted file mode 100644
index 4d23f9ec75f..00000000000
--- a/docs/deployments/p04/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P04 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P04 runs soft X-ray spectroscopy, which earns no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## Soft X-ray absorption spectroscopy
-
-P04 sets the photon energy (250-3000 eV) by coupling the [variable-polarization undulator](source.md) and the [plane-grating monochromator](source.md), then scans it across an absorption edge while reading the sample drain current on the [electrometer](detector.md) (total electron yield).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Soft X-ray absorption (XAS / NEXAFS) | `xas_spectroscopy` | the undulator + PGM photon-energy scan reading the Keithley electrometer; reuses the `xas_spectroscopy` slug four sites share, a further consumer (`TECH-1`) |
-
-## Photoemission
-
-P04's variable polarization and soft X-ray energy range suit photoemission on the EXP endstations (the analyzer is an endstation instrument not exposed as a motor in the registry).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Soft X-ray photoemission | `angle_resolved_photoemission` | photoemission on the EXP endstations; reuses the `angle_resolved_photoemission` slug, a further consumer (`TECH-1`) |
-
-## A new technique regime on mostly familiar vocabulary
-
-P04 is the fleet's soft X-ray spectroscopy beamline. Its energy regime is new (250-3000 eV, below the hard X-ray beamlines), and it forces the one genuinely new device binding, the `GratingMonochromator` (the soft X-ray analog of the crystal `Monochromator`). The techniques themselves reuse the `xas_spectroscopy` and `angle_resolved_photoemission` slugs already carried pending across the fleet, so neither forces a new Method to be coined now. The rest of the instrument anatomy reuses existing Families: the undulator binds `InsertionDevice`, the mirrors `Mirror`, the slits `Slit`, the manipulators `Manipulator`, the diagnostics `Camera` / `FluxMonitor` / `Screen`.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the photon-energy-scan sequences and their dwell times, the polarization switching, the photoemission analyzer sweeps) are not written yet; they join as the deployment approaches the point where CORA drives P04. Whether the soft X-ray Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p06/governance.md b/docs/deployments/p06/governance.md
deleted file mode 100644
index 1256da29e80..00000000000
--- a/docs/deployments/p06/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P06, and the trust shape that will gate it. First cut.*
-
-Governance at P06 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P06 is CORA's third PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01 and P04), until DESY staff confirm them (`GOV-1`). P06 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P06, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the mono hutch and the two probe endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P06 also carries the hazard classes that come with a dense nano-probe endstation: hexapods, KB-lens stacks, and piezo scanners moving in close quarters inside interlocked hutches. Those land with the instruments that bring them when the deployment firms up.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P06, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p06/model.md b/docs/deployments/p06/model.md
deleted file mode 100644
index 16b3392806f..00000000000
--- a/docs/deployments/p06/model.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P06 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P06 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (KB lens fine axes) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P06 new
-
-P06 is a third beamline at an existing Site, and the fleet's fullest scanning-probe instrument. It is a hard X-ray micro- and nano-probe: a focused beam rastered across a sample while a high-rate Maia XRF array and area detectors read each point, plus nano-tomography on the NC1 sample rotation. Its novelty is the density and diversity of the device tree (six motion-controller families, two endstations, the Maia array), not any new Family or Method.
-
-## No new families (the fullest catalog reuse yet)
-
-P06 coins no new Family. The Maia XRF array binds `EnergyDispersiveSpectrometer` (one Asset carrying its six sub-device handles); the hexapods (MC01 plus the two NC1 KB-lens carriers) bind `Hexapod`; the KB lens fine stages bind `PseudoAxis`; the scan, sample, pin, and nano stages bind `LinearStage`; the sample rotation binds `RotaryStage`; the monochromators bind `Monochromator`; the slits bind `Slit`; the undulator binds `InsertionDevice`; the BPMs bind `FluxMonitor`; and the area / view cameras bind `Camera`. Nothing in the catalog changes.
-
-## The control plane
-
-P06 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as P01 / P04, but with the most controller diversity yet: OMS steppers, Aerotech fly-scan controllers, SmarAct piezo / hexapod controllers, a hexapod controller, PI and SMC-Hydra fine-stage controllers, and a Pegasus rotation controller, reading the Maia array and the Eiger / Lambda / Pilatus / PCO detectors. The handles are read from P06's public OnlineXML registry and carried confirm (`CTRL-1`); several detectors report on a bare `p06` / `petra3` host (`HOST-1`). The scanning fluorescence acquisition is a continuous-motion Aerotech fly-scan coupled to the Maia readout; CORA's edge conducts that over its `ControlPort` and is barred from the deterministic real-time fly-scan loop by construction.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap / harmonic / taper, not the period; carried pending.
-- **The optics physical detail (`OPT-1`).** The DCM crystal cut, the multilayer d-spacing, and the KB focal sizes are carried confirm-pending.
-- **The motor-bank axis roles (`GROUP-1`).** The `mono_mot`, `mi_mot`, and `nat_mot` banks carry no per-axis role in the registry; grouped as stage Assets, roles pending.
-- **The fly-scan parameters (`SCAN-1`).** The Aerotech raster trajectories and the motion-detector triggering coupling are not in the registry.
-- **The detector roster (`DET-1`).** The operative detectors per experiment, the Maia element count, and the area-detector models are named, not fully bound; the Maia sub-device split is a modelling question.
-- **The host mapping (`HOST-1`).** Several detectors report on a bare host; whether that is a shared Tango DB or a registry artifact is pending.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The scanning / nano-tomography Methods (`TECH-1`).** Whether these enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p06_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p06/notes.md b/docs/deployments/p06/notes.md
new file mode 100644
index 00000000000..b377f1b5bf7
--- /dev/null
+++ b/docs/deployments/p06/notes.md
@@ -0,0 +1,135 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P06 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P06 runs hard X-ray scanning-probe microscopy and nano-tomography, reusing Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
+
+### Scanning fluorescence / diffraction microscopy
+
+P06 focuses the beam (the multilayer or crystal monochromator feeding the KB optics) to a micro or nano spot, then rasters the sample across it with the [Aerotech scan stage](sample.md) while the [Maia XRF array](detector.md) reads the fluorescence at each point (and the area detectors read scattering / diffraction).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Scanning X-ray fluorescence / diffraction microscopy | `scanning_fluorescence_microscopy` | the Aerotech raster fly-scan over the micro / nano focus reading the Maia array; reuses the slug 2-ID / XFM / LIX / ESRF ID16B share, a further consumer (`TECH-1`) |
+
+### Nano-tomography
+
+The NC1 nano-probe carries a Pegasus sample rotation (`samr`); rotating the sample in the nano-focused beam while reading the area detector gives nano-tomography.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Hard X-ray nano-tomography | `tomography` | the NC1 sample rotation + area detector; reuses the catalog `tomography` Method (the 2-BM / FXI / ID19 lineage), a further consumer (`TECH-1`) |
+
+### A dense instrument on familiar vocabulary
+
+P06 is the fleet's fullest scanning-probe beamline, but it coins no new vocabulary. Its techniques reuse the `scanning_fluorescence_microscopy` and `tomography` slugs already carried across the fleet, and its instrument anatomy reuses existing Families: the monochromators bind `Monochromator`, the hexapods `Hexapod`, the scan stages `LinearStage`, the Maia array `EnergyDispersiveSpectrometer`, the area detectors `Camera`. The novelty is in the density and diversity of the device tree (six controller families, two endstations, the Maia array), not in any new Family or Method.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the raster fly-scan trajectories and dwell times, the Maia mapping readout, the nano-tomography rotation sequences) are not written yet; they join as the deployment approaches the point where CORA drives P06. Whether the scanning / nano-tomography Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P06, and the trust shape that will gate it. First cut.*
+
+Governance at P06 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P06 is CORA's third PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01 and P04), until DESY staff confirm them (`GOV-1`). P06 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P06, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the mono hutch and the two probe endstations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P06 also carries the hazard classes that come with a dense nano-probe endstation: hexapods, KB-lens stacks, and piezo scanners moving in close quarters inside interlocked hutches. Those land with the instruments that bring them when the deployment firms up.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P06, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P06 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P06 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (KB lens fine axes) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P06 new
+
+P06 is a third beamline at an existing Site, and the fleet's fullest scanning-probe instrument. It is a hard X-ray micro- and nano-probe: a focused beam rastered across a sample while a high-rate Maia XRF array and area detectors read each point, plus nano-tomography on the NC1 sample rotation. Its novelty is the density and diversity of the device tree (six motion-controller families, two endstations, the Maia array), not any new Family or Method.
+
+### No new families (the fullest catalog reuse yet)
+
+P06 coins no new Family. The Maia XRF array binds `EnergyDispersiveSpectrometer` (one Asset carrying its six sub-device handles); the hexapods (MC01 plus the two NC1 KB-lens carriers) bind `Hexapod`; the KB lens fine stages bind `PseudoAxis`; the scan, sample, pin, and nano stages bind `LinearStage`; the sample rotation binds `RotaryStage`; the monochromators bind `Monochromator`; the slits bind `Slit`; the undulator binds `InsertionDevice`; the BPMs bind `FluxMonitor`; and the area / view cameras bind `Camera`. Nothing in the catalog changes.
+
+### The control plane
+
+P06 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as P01 / P04, but with the most controller diversity yet: OMS steppers, Aerotech fly-scan controllers, SmarAct piezo / hexapod controllers, a hexapod controller, PI and SMC-Hydra fine-stage controllers, and a Pegasus rotation controller, reading the Maia array and the Eiger / Lambda / Pilatus / PCO detectors. The handles are read from P06's public OnlineXML registry and carried confirm (`CTRL-1`); several detectors report on a bare `p06` / `petra3` host (`HOST-1`). The scanning fluorescence acquisition is a continuous-motion Aerotech fly-scan coupled to the Maia readout; CORA's edge conducts that over its `ControlPort` and is barred from the deterministic real-time fly-scan loop by construction.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap / harmonic / taper, not the period; carried pending.
+- **The optics physical detail (`OPT-1`).** The DCM crystal cut, the multilayer d-spacing, and the KB focal sizes are carried confirm-pending.
+- **The motor-bank axis roles (`GROUP-1`).** The `mono_mot`, `mi_mot`, and `nat_mot` banks carry no per-axis role in the registry; grouped as stage Assets, roles pending.
+- **The fly-scan parameters (`SCAN-1`).** The Aerotech raster trajectories and the motion-detector triggering coupling are not in the registry.
+- **The detector roster (`DET-1`).** The operative detectors per experiment, the Maia element count, and the area-detector models are named, not fully bound; the Maia sub-device split is a modelling question.
+- **The host mapping (`HOST-1`).** Several detectors report on a bare host; whether that is a shared Tango DB or a registry artifact is pending.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The scanning / nano-tomography Methods (`TECH-1`).** Whether these enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p06_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P06 team to confirm before the model can be trusted.*
+
+P06 was reverse-engineered from P06's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p06](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p06), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no focal sizes, detector models, or energy calibration. P06 is CORA's third PETRA III beamline and its fullest scanning-probe deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics / mono hutch feeding two scanning-probe endstations (MC01 micro, NC1 nano)? | A `p06-mono` hutch and two `p06-mc01` / `p06-nc1` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
+| HOST-1 | Nice-to-have | Several detectors (Lambda, the detector pool) report on a bare `p06` / `petra3` Tango host. Is that a shared detector host, or a registry artifact? | The detectors are homed in the endstation that operates them; the host is flagged. | The detector-to-host mapping. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`mono_mot`, `mi_mot01..84`, `nat_mot01..32`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The sample / instrument-stage Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap / harmonic / taper read, period pending. | The source Asset detail. |
+| OPT-1 | Blocks-go-live | The DCM crystal cut, the multilayer monochromator d-spacing, and the KB-lens focal sizes (horizontal and vertical). | A DCM + a multilayer `Monochromator`, two KB `Hexapod` carriers; handles read, physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SCAN-1 | Blocks-go-live | The Aerotech fly-scan raster trajectories and the motion-detector triggering coupling (MC01 and NC1). | `LinearStage` scan stages with a continuous fly-scan role; parameters pending. | The scanning-acquisition modelling. |
+| SAMPLE-1 | Nice-to-have | The NC1 SmarAct sample-piezo axes and the Pegasus sample-rotation detail (the nano-tomography axis). | A `LinearStage` piezo stack and a `RotaryStage` rotation; axis set pending. | The sample-stage modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per experiment, the Maia element count, and the area-detector models (Eiger / Lambda / Pilatus / PCO variants). | A Maia `EnergyDispersiveSpectrometer` (one Asset, six sub-devices), XIA fluorescence, and `Camera` area detectors; models pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P06 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do scanning fluorescence / diffraction microscopy and nano-tomography enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `scanning_fluorescence_microscopy` and `tomography` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p06/questions.md b/docs/deployments/p06/questions.md
deleted file mode 100644
index 4cc9f6a0b42..00000000000
--- a/docs/deployments/p06/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the P06 team to confirm before the model can be trusted.*
-
-P06 was reverse-engineered from P06's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p06](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p06), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no focal sizes, detector models, or energy calibration. P06 is CORA's third PETRA III beamline and its fullest scanning-probe deployment. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics / mono hutch feeding two scanning-probe endstations (MC01 micro, NC1 nano)? | A `p06-mono` hutch and two `p06-mc01` / `p06-nc1` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
-| HOST-1 | Nice-to-have | Several detectors (Lambda, the detector pool) report on a bare `p06` / `petra3` Tango host. Is that a shared detector host, or a registry artifact? | The detectors are homed in the endstation that operates them; the host is flagged. | The detector-to-host mapping. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`mono_mot`, `mi_mot01..84`, `nat_mot01..32`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The sample / instrument-stage Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap / harmonic / taper read, period pending. | The source Asset detail. |
-| OPT-1 | Blocks-go-live | The DCM crystal cut, the multilayer monochromator d-spacing, and the KB-lens focal sizes (horizontal and vertical). | A DCM + a multilayer `Monochromator`, two KB `Hexapod` carriers; handles read, physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SCAN-1 | Blocks-go-live | The Aerotech fly-scan raster trajectories and the motion-detector triggering coupling (MC01 and NC1). | `LinearStage` scan stages with a continuous fly-scan role; parameters pending. | The scanning-acquisition modelling. |
-| SAMPLE-1 | Nice-to-have | The NC1 SmarAct sample-piezo axes and the Pegasus sample-rotation detail (the nano-tomography axis). | A `LinearStage` piezo stack and a `RotaryStage` rotation; axis set pending. | The sample-stage modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per experiment, the Maia element count, and the area-detector models (Eiger / Lambda / Pilatus / PCO variants). | A Maia `EnergyDispersiveSpectrometer` (one Asset, six sub-devices), XIA fluorescence, and `Camera` area detectors; models pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P06 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do scanning fluorescence / diffraction microscopy and nano-tomography enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `scanning_fluorescence_microscopy` and `tomography` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p06/techniques.md b/docs/deployments/p06/techniques.md
deleted file mode 100644
index 0072e72a17a..00000000000
--- a/docs/deployments/p06/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P06 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P06 runs hard X-ray scanning-probe microscopy and nano-tomography, reusing Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
-
-## Scanning fluorescence / diffraction microscopy
-
-P06 focuses the beam (the multilayer or crystal monochromator feeding the KB optics) to a micro or nano spot, then rasters the sample across it with the [Aerotech scan stage](sample.md) while the [Maia XRF array](detector.md) reads the fluorescence at each point (and the area detectors read scattering / diffraction).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Scanning X-ray fluorescence / diffraction microscopy | `scanning_fluorescence_microscopy` | the Aerotech raster fly-scan over the micro / nano focus reading the Maia array; reuses the slug 2-ID / XFM / LIX / ESRF ID16B share, a further consumer (`TECH-1`) |
-
-## Nano-tomography
-
-The NC1 nano-probe carries a Pegasus sample rotation (`samr`); rotating the sample in the nano-focused beam while reading the area detector gives nano-tomography.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Hard X-ray nano-tomography | `tomography` | the NC1 sample rotation + area detector; reuses the catalog `tomography` Method (the 2-BM / FXI / ID19 lineage), a further consumer (`TECH-1`) |
-
-## A dense instrument on familiar vocabulary
-
-P06 is the fleet's fullest scanning-probe beamline, but it coins no new vocabulary. Its techniques reuse the `scanning_fluorescence_microscopy` and `tomography` slugs already carried across the fleet, and its instrument anatomy reuses existing Families: the monochromators bind `Monochromator`, the hexapods `Hexapod`, the scan stages `LinearStage`, the Maia array `EnergyDispersiveSpectrometer`, the area detectors `Camera`. The novelty is in the density and diversity of the device tree (six controller families, two endstations, the Maia array), not in any new Family or Method.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the raster fly-scan trajectories and dwell times, the Maia mapping readout, the nano-tomography rotation sequences) are not written yet; they join as the deployment approaches the point where CORA drives P06. Whether the scanning / nano-tomography Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p07/governance.md b/docs/deployments/p07/governance.md
deleted file mode 100644
index 2f3733b6018..00000000000
--- a/docs/deployments/p07/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P07, and the trust shape that will gate it. First cut.*
-
-Governance at P07 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P07 carries a governance wrinkle the other PETRA III beamlines do not: it is **jointly operated by Helmholtz-Zentrum Hereon (2/3) and DESY (1/3)** (`OPERATOR-1`). How that joint operation maps to CORA's Federation / Trust model (a single Site with a shared operator pool, or two Federation participants sharing a beamline) is a facility-governance question carried pending. For this first cut, P07 is modelled as a beamline on the PETRA III Site, with the Hereon stake noted on the [index](index.md) and as a question; the DESY / Hereon operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance) (`GOV-1`).
-
-P07 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P07, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the two experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). P07 also carries the hazard classes that come with its endstations: a high-energy beam, the 17 T superconducting magnet and its liquid-helium cryogen, and the Linkam furnace; those land with the instruments that bring them when the deployment firms up.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P07, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p07/model.md b/docs/deployments/p07/model.md
deleted file mode 100644
index 579d0c4f46f..00000000000
--- a/docs/deployments/p07/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P07 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P07 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P07 new
-
-P07 is an eleventh beamline at an existing Site, and the facility's high-energy materials-science beamline, jointly operated by Helmholtz-Zentrum Hereon (2/3) and DESY (1/3). Its distinguishing capabilities are high-energy diffraction for engineering materials and a 17 T high-field magnet endstation. At the modelling level it is a reuse-and-reinforce deployment, plus a governance note (the joint operation).
-
-## No new families
-
-P07 coins no new Family. The multi-bounce mono binds `Monochromator`; the four-circle diffractometer `Goniometer`; the hexapod `Hexapod`; the 17 T magnet the graduated catalog `Magnet` Family (a further consumer, after 4-ID / i10-1 / ID32 / P09); the Linkam stage `TemperatureController`; the slits `Slit`; the stages `LinearStage`; the detectors `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes.
-
-## The control plane
-
-P07 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, despite the Hereon / DESY joint operation (the beamline controls are the PETRA III stack). Its distinctive devices are the multi-bounce DCM (resolved axes), the 17 T magnet, and the Linkam stage. The handles are read from P07's public OnlineXML registry and carried confirm (`CTRL-1`); only the EH2 registry slice is public. The high-energy diffraction / high-field acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The joint-operation governance (`OPERATOR-1`).** The Hereon (2/3) + DESY (1/3) operation is a facility-governance fact carried as a question; how it maps to CORA's Federation / Trust model is pending.
-- **The undulator parameters (`SRC-1`).** The gap / taper are read; the period is not exposed.
-- **The optics detail (`OPT-1`).** The multi-bounce DCM crystal cut and the OH optics are carried confirm-pending.
-- **The diffractometer structure (`DIFF-1`).** The four-circle count and the detector arm are pending; modelled as a `Goniometer` Asset.
-- **The motor-bank axis roles (`GROUP-1`).** The `exp*` / `oh*` banks carry no per-axis role; grouped as stage Assets.
-- **The magnet detail (`MAG-1`).** The 17 T field and control are pending; the Family is the graduated catalog `Magnet` (a further consumer, its per-Asset field detail pending).
-- **The detector roster (`DET-1`).** The models and the EH2B detection are named, not fully bound.
-- **The other hutches (`HOST-1`).** Only the EH2 slice is public; EH1 / EH3 / EH4 are noted, not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The diffraction Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p07_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p07/notes.md b/docs/deployments/p07/notes.md
new file mode 100644
index 00000000000..a74030264a3
--- /dev/null
+++ b/docs/deployments/p07/notes.md
@@ -0,0 +1,138 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P07 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P07's diffraction and high-field techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### High-energy materials-science diffraction
+
+P07 uses a high-energy monochromatic beam to study engineering materials (bulk diffraction, residual stress, texture, in-situ deformation), reading the diffraction on the [four-circle diffractometer](sample.md) and the [Pilatus / PerkinElmer detectors](detector.md).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-energy diffraction | `diffraction` | bulk / engineering diffraction on the four-circle diffractometer + area detectors; reuses the `diffraction` slug, a further consumer (`TECH-1`) |
+
+### High-field materials science
+
+P07's EH2 endstation carries a 17 T high-field magnet for studies under applied magnetic field.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-field magnetic scattering | `magnetic_scattering` | scattering / diffraction in the 17 T magnet; reuses the `magnetic_scattering` slug P09 / 4-ID share, a further consumer (`TECH-1`) |
+
+### A high-energy materials beamline on familiar vocabulary
+
+P07 is the fleet's high-energy materials-science beamline. Its techniques reuse the `diffraction` and `magnetic_scattering` slugs already carried across the fleet, so none forces a new Method now. The instrument anatomy reuses existing Families: the multi-bounce mono binds `Monochromator`, the four-circle diffractometer `Goniometer`, the 17 T magnet the graduated catalog `Magnet` Family, the Linkam stage `TemperatureController`, the detectors `Camera`. The in-situ sample environment (the Linkam heating / cooling, the magnet) suits operando materials studies but coins no new Family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the diffraction / stress-mapping scans, the in-situ deformation / temperature ramps, the high-field scans) are not written yet; they join as the deployment approaches the point where CORA drives P07. Whether the diffraction Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P07, and the trust shape that will gate it. First cut.*
+
+Governance at P07 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P07 carries a governance wrinkle the other PETRA III beamlines do not: it is **jointly operated by Helmholtz-Zentrum Hereon (2/3) and DESY (1/3)** (`OPERATOR-1`). How that joint operation maps to CORA's Federation / Trust model (a single Site with a shared operator pool, or two Federation participants sharing a beamline) is a facility-governance question carried pending. For this first cut, P07 is modelled as a beamline on the PETRA III Site, with the Hereon stake noted on the [index](index.md) and as a question; the DESY / Hereon operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance) (`GOV-1`).
+
+P07 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P07, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the two experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). P07 also carries the hazard classes that come with its endstations: a high-energy beam, the 17 T superconducting magnet and its liquid-helium cryogen, and the Linkam furnace; those land with the instruments that bring them when the deployment firms up.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P07, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P07 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P07 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P07 new
+
+P07 is an eleventh beamline at an existing Site, and the facility's high-energy materials-science beamline, jointly operated by Helmholtz-Zentrum Hereon (2/3) and DESY (1/3). Its distinguishing capabilities are high-energy diffraction for engineering materials and a 17 T high-field magnet endstation. At the modelling level it is a reuse-and-reinforce deployment, plus a governance note (the joint operation).
+
+### No new families
+
+P07 coins no new Family. The multi-bounce mono binds `Monochromator`; the four-circle diffractometer `Goniometer`; the hexapod `Hexapod`; the 17 T magnet the graduated catalog `Magnet` Family (a further consumer, after 4-ID / i10-1 / ID32 / P09); the Linkam stage `TemperatureController`; the slits `Slit`; the stages `LinearStage`; the detectors `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes.
+
+### The control plane
+
+P07 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, despite the Hereon / DESY joint operation (the beamline controls are the PETRA III stack). Its distinctive devices are the multi-bounce DCM (resolved axes), the 17 T magnet, and the Linkam stage. The handles are read from P07's public OnlineXML registry and carried confirm (`CTRL-1`); only the EH2 registry slice is public. The high-energy diffraction / high-field acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The joint-operation governance (`OPERATOR-1`).** The Hereon (2/3) + DESY (1/3) operation is a facility-governance fact carried as a question; how it maps to CORA's Federation / Trust model is pending.
+- **The undulator parameters (`SRC-1`).** The gap / taper are read; the period is not exposed.
+- **The optics detail (`OPT-1`).** The multi-bounce DCM crystal cut and the OH optics are carried confirm-pending.
+- **The diffractometer structure (`DIFF-1`).** The four-circle count and the detector arm are pending; modelled as a `Goniometer` Asset.
+- **The motor-bank axis roles (`GROUP-1`).** The `exp*` / `oh*` banks carry no per-axis role; grouped as stage Assets.
+- **The magnet detail (`MAG-1`).** The 17 T field and control are pending; the Family is the graduated catalog `Magnet` (a further consumer, its per-Asset field detail pending).
+- **The detector roster (`DET-1`).** The models and the EH2B detection are named, not fully bound.
+- **The other hutches (`HOST-1`).** Only the EH2 slice is public; EH1 / EH3 / EH4 are noted, not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The diffraction Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p07_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P07 team to confirm before the model can be trusted.*
+
+P07 was reverse-engineered from P07's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p07](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p07), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, magnet field, or energy calibration. P07 is CORA's eleventh PETRA III beamline, jointly operated by Helmholtz-Zentrum Hereon and DESY. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding an EH2 main and an EH2B secondary hutch, plus other hutches (EH1 / EH3 / EH4)? | A `p07-oh2` optics hutch and `p07-eh2` / `p07-eh2b` endstations, from the registry slice. | The Enclosure grouping. |
+| OPERATOR-1 | Blocks-go-live | The Hereon (2/3) + DESY (1/3) joint operation: how does it map to CORA's Federation / Trust model? | A beamline on the PETRA III Site with a shared operator pool; the Hereon stake noted. | The operator / governance model. |
+| HOST-1 | Nice-to-have | The other P07 hutches (EH1 / EH3 / EH4) are not in the public EH2 registry slice. Where are they? | Only EH2 / EH2B modelled; the others noted, not modelled. | The full hutch roster. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`exp*`, `oh*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap / taper read, period pending. | The source Asset detail. |
+| OPT-1 | Blocks-go-live | The multi-bounce DCM crystal cut and energy range, and the OH optics. | A multi-bounce `Monochromator`; physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The four-circle Eulerian diffractometer geometry and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (e4cv + two-theta), not the composed Diffractometer Assembly. | The diffractometer modelling. |
+| MAG-1 | Blocks-go-live | The 17 T magnet field, cryogen, and control / ramp interface. | A 17 T superconducting `Magnet` (the graduated catalog Family, a further consumer); field and control pending. | The per-Asset magnet field / control detail. |
+| SAMPLE-1 | Nice-to-have | The EH2 sample-hexapod geometry and the Linkam stage handles. | A `Hexapod` + a `TemperatureController`; geometry pending. | The sample modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per hutch, the Pilatus / PerkinElmer models (the `_old` controller suffix), and the EH2B detection. | `Camera` area detectors plus `EnergyDispersiveSpectrometer` MCAs; models pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P07 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY / Hereon personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the magnet liquid-helium supply. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY / Hereon operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do high-energy diffraction and high-field materials science enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `diffraction` / `magnetic_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p07/questions.md b/docs/deployments/p07/questions.md
deleted file mode 100644
index 2a5d0d1d917..00000000000
--- a/docs/deployments/p07/questions.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Open questions
-
-*What CORA needs the P07 team to confirm before the model can be trusted.*
-
-P07 was reverse-engineered from P07's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p07](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p07), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, magnet field, or energy calibration. P07 is CORA's eleventh PETRA III beamline, jointly operated by Helmholtz-Zentrum Hereon and DESY. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding an EH2 main and an EH2B secondary hutch, plus other hutches (EH1 / EH3 / EH4)? | A `p07-oh2` optics hutch and `p07-eh2` / `p07-eh2b` endstations, from the registry slice. | The Enclosure grouping. |
-| OPERATOR-1 | Blocks-go-live | The Hereon (2/3) + DESY (1/3) joint operation: how does it map to CORA's Federation / Trust model? | A beamline on the PETRA III Site with a shared operator pool; the Hereon stake noted. | The operator / governance model. |
-| HOST-1 | Nice-to-have | The other P07 hutches (EH1 / EH3 / EH4) are not in the public EH2 registry slice. Where are they? | Only EH2 / EH2B modelled; the others noted, not modelled. | The full hutch roster. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`exp*`, `oh*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap / taper read, period pending. | The source Asset detail. |
-| OPT-1 | Blocks-go-live | The multi-bounce DCM crystal cut and energy range, and the OH optics. | A multi-bounce `Monochromator`; physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The four-circle Eulerian diffractometer geometry and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (e4cv + two-theta), not the composed Diffractometer Assembly. | The diffractometer modelling. |
-| MAG-1 | Blocks-go-live | The 17 T magnet field, cryogen, and control / ramp interface. | A 17 T superconducting `Magnet` (the graduated catalog Family, a further consumer); field and control pending. | The per-Asset magnet field / control detail. |
-| SAMPLE-1 | Nice-to-have | The EH2 sample-hexapod geometry and the Linkam stage handles. | A `Hexapod` + a `TemperatureController`; geometry pending. | The sample modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per hutch, the Pilatus / PerkinElmer models (the `_old` controller suffix), and the EH2B detection. | `Camera` area detectors plus `EnergyDispersiveSpectrometer` MCAs; models pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P07 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY / Hereon personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the magnet liquid-helium supply. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY / Hereon operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do high-energy diffraction and high-field materials science enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `diffraction` / `magnetic_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p07/techniques.md b/docs/deployments/p07/techniques.md
deleted file mode 100644
index 6db5ddcd9bf..00000000000
--- a/docs/deployments/p07/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P07 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P07's diffraction and high-field techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## High-energy materials-science diffraction
-
-P07 uses a high-energy monochromatic beam to study engineering materials (bulk diffraction, residual stress, texture, in-situ deformation), reading the diffraction on the [four-circle diffractometer](sample.md) and the [Pilatus / PerkinElmer detectors](detector.md).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-energy diffraction | `diffraction` | bulk / engineering diffraction on the four-circle diffractometer + area detectors; reuses the `diffraction` slug, a further consumer (`TECH-1`) |
-
-## High-field materials science
-
-P07's EH2 endstation carries a 17 T high-field magnet for studies under applied magnetic field.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-field magnetic scattering | `magnetic_scattering` | scattering / diffraction in the 17 T magnet; reuses the `magnetic_scattering` slug P09 / 4-ID share, a further consumer (`TECH-1`) |
-
-## A high-energy materials beamline on familiar vocabulary
-
-P07 is the fleet's high-energy materials-science beamline. Its techniques reuse the `diffraction` and `magnetic_scattering` slugs already carried across the fleet, so none forces a new Method now. The instrument anatomy reuses existing Families: the multi-bounce mono binds `Monochromator`, the four-circle diffractometer `Goniometer`, the 17 T magnet the graduated catalog `Magnet` Family, the Linkam stage `TemperatureController`, the detectors `Camera`. The in-situ sample environment (the Linkam heating / cooling, the magnet) suits operando materials studies but coins no new Family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the diffraction / stress-mapping scans, the in-situ deformation / temperature ramps, the high-field scans) are not written yet; they join as the deployment approaches the point where CORA drives P07. Whether the diffraction Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p08/governance.md b/docs/deployments/p08/governance.md
deleted file mode 100644
index ab39ec3cdd0..00000000000
--- a/docs/deployments/p08/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P08, and the trust shape that will gate it. First cut.*
-
-Governance at P08 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P08 is CORA's twelfth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P08 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P08, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the experiment endstation) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P08, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p08/model.md b/docs/deployments/p08/model.md
deleted file mode 100644
index a6bab921cc5..00000000000
--- a/docs/deployments/p08/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P08 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P08 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P08 new
-
-P08 is a twelfth beamline at an existing Site, the facility's high-resolution diffraction beamline (surface / interface diffraction, reflectivity, high-resolution powder / single-crystal). At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level, distinguished mainly by its rich detector set.
-
-## No new families
-
-P08 coins no new Family. The DCM and multilayer mono bind `Monochromator`; the CRL `Transfocator`; the absorber `Filter`; the six-circle Kohzu diffractometer `Goniometer`; the hexapod `Hexapod`; the slits `Slit`; the detectors `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes. The Mythen2 strip detector is modelled as a `Camera` for now (a fold-vs-promote question for the catalog owner, the P10 precedent).
-
-## The control plane
-
-P08 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the Kohzu six-circle diffractometer controller and the breadth of detectors (Eiger / Pilatus / Mythen / PerkinElmer / Vortex). The handles are read from P08's public OnlineXML registry and carried confirm (`CTRL-1`). The high-resolution diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The gap is read; the period is not exposed.
-- **The optics detail (`OPT-1`).** The DCM / multilayer crystal cut and the CRL detail are carried confirm-pending.
-- **The diffractometer structure (`DIFF-1`, `GROUP-1`).** The six-circle Kohzu geometry and the per-axis `diff*` bank roles are pending; modelled as a `Goniometer` Asset.
-- **The sample hexapod geometry (`SAMPLE-1`).** Carried confirm-pending.
-- **The detector roster (`DET-1`).** The models, the operative roster, and the Mythen fold-vs-promote are named, not fully bound.
-- **The shared Lambda host (`HOST-1`).** A Lambda reports on the bare `petra3` host.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p08_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p08/notes.md b/docs/deployments/p08/notes.md
new file mode 100644
index 00000000000..d5b09a20628
--- /dev/null
+++ b/docs/deployments/p08/notes.md
@@ -0,0 +1,124 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P08 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P08's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### High-resolution diffraction
+
+P08 uses a high-resolution monochromatic beam on a six-circle [diffractometer](sample.md) to measure surface / interface diffraction, reflectivity (XRR), and high-resolution powder / single-crystal diffraction, reading the [Eiger / Pilatus / Mythen detectors](detector.md).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-resolution diffraction / reflectivity | `diffraction` | surface / interface diffraction and reflectivity on the six-circle Kohzu diffractometer + area / strip detectors; reuses the `diffraction` slug P07 share, a further consumer (`TECH-1`) |
+
+### A diffraction beamline on familiar vocabulary
+
+P08 is the fleet's high-resolution diffraction beamline. Its technique reuses the `diffraction` slug already carried pending across the fleet, so it forces no new Method now. The instrument anatomy reuses existing Families: the monochromators bind `Monochromator`, the six-circle diffractometer `Goniometer`, the CRL `Transfocator`, the hexapod `Hexapod`, the detectors `Camera` / `EnergyDispersiveSpectrometer`. The rich detector set (Eiger / Pilatus / Mythen / PerkinElmer / Vortex) suits the breadth of diffraction modes but coins no new Family.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the reflectivity / rocking-curve scans, the reciprocal-space mapping, the high-resolution powder collection) are not written yet; they join as the deployment approaches the point where CORA drives P08. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P08, and the trust shape that will gate it. First cut.*
+
+Governance at P08 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P08 is CORA's twelfth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P08 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P08, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the experiment endstation) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P08, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P08 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P08 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P08 new
+
+P08 is a twelfth beamline at an existing Site, the facility's high-resolution diffraction beamline (surface / interface diffraction, reflectivity, high-resolution powder / single-crystal). At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level, distinguished mainly by its rich detector set.
+
+### No new families
+
+P08 coins no new Family. The DCM and multilayer mono bind `Monochromator`; the CRL `Transfocator`; the absorber `Filter`; the six-circle Kohzu diffractometer `Goniometer`; the hexapod `Hexapod`; the slits `Slit`; the detectors `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes. The Mythen2 strip detector is modelled as a `Camera` for now (a fold-vs-promote question for the catalog owner, the P10 precedent).
+
+### The control plane
+
+P08 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the Kohzu six-circle diffractometer controller and the breadth of detectors (Eiger / Pilatus / Mythen / PerkinElmer / Vortex). The handles are read from P08's public OnlineXML registry and carried confirm (`CTRL-1`). The high-resolution diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The gap is read; the period is not exposed.
+- **The optics detail (`OPT-1`).** The DCM / multilayer crystal cut and the CRL detail are carried confirm-pending.
+- **The diffractometer structure (`DIFF-1`, `GROUP-1`).** The six-circle Kohzu geometry and the per-axis `diff*` bank roles are pending; modelled as a `Goniometer` Asset.
+- **The sample hexapod geometry (`SAMPLE-1`).** Carried confirm-pending.
+- **The detector roster (`DET-1`).** The models, the operative roster, and the Mythen fold-vs-promote are named, not fully bound.
+- **The shared Lambda host (`HOST-1`).** A Lambda reports on the bare `petra3` host.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p08_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P08 team to confirm before the model can be trusted.*
+
+P08 was reverse-engineered from P08's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p08](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p08), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts or energy calibration. P08 is CORA's twelfth PETRA III beamline, the high-resolution diffraction beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding the diffractometer experiment endstation? | A `p08-oh` optics hutch and a `p08-eh` endstation. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the `diff*` Kohzu diffractometer / sample bank. | Grouped as the `Goniometer` Asset carrying the bank prefix; per-axis roles pending. | The diffractometer Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The DCM and multilayer monochromator crystal cuts / d-spacing, and the CRL detail. | A DCM + a multilayer `Monochromator` and a `Transfocator` CRL; physical detail pending. | The optics modelling. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The six-circle Kohzu diffractometer geometry and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (kozhue6cctrl + diff*), not the composed Diffractometer Assembly. | The diffractometer modelling. |
+| SAMPLE-1 | Nice-to-have | The sample hexapod geometry. | A `Hexapod`; geometry pending. | The sample modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per experiment, the models (Eiger 1M / Pilatus / Mythen2 / PerkinElmer / Vortex), and whether the Mythen strip detector warrants a distinct Family. | A `Camera` suite plus a `EnergyDispersiveSpectrometer` Vortex; the Mythen modelled as a `Camera` for now. | The detector modelling. |
+| HOST-1 | Nice-to-have | A shared Lambda detector reports on the bare `petra3` host. Shared host, or registry artifact? | The Lambda is noted; the host is flagged. | The detector-to-host mapping. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P08 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does high-resolution diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p08/questions.md b/docs/deployments/p08/questions.md
deleted file mode 100644
index fc8e9ae4db0..00000000000
--- a/docs/deployments/p08/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the P08 team to confirm before the model can be trusted.*
-
-P08 was reverse-engineered from P08's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p08](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p08), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts or energy calibration. P08 is CORA's twelfth PETRA III beamline, the high-resolution diffraction beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding the diffractometer experiment endstation? | A `p08-oh` optics hutch and a `p08-eh` endstation. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the `diff*` Kohzu diffractometer / sample bank. | Grouped as the `Goniometer` Asset carrying the bank prefix; per-axis roles pending. | The diffractometer Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The DCM and multilayer monochromator crystal cuts / d-spacing, and the CRL detail. | A DCM + a multilayer `Monochromator` and a `Transfocator` CRL; physical detail pending. | The optics modelling. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The six-circle Kohzu diffractometer geometry and whether it composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset (kozhue6cctrl + diff*), not the composed Diffractometer Assembly. | The diffractometer modelling. |
-| SAMPLE-1 | Nice-to-have | The sample hexapod geometry. | A `Hexapod`; geometry pending. | The sample modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per experiment, the models (Eiger 1M / Pilatus / Mythen2 / PerkinElmer / Vortex), and whether the Mythen strip detector warrants a distinct Family. | A `Camera` suite plus a `EnergyDispersiveSpectrometer` Vortex; the Mythen modelled as a `Camera` for now. | The detector modelling. |
-| HOST-1 | Nice-to-have | A shared Lambda detector reports on the bare `petra3` host. Shared host, or registry artifact? | The Lambda is noted; the host is flagged. | The detector-to-host mapping. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P08 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does high-resolution diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p08/techniques.md b/docs/deployments/p08/techniques.md
deleted file mode 100644
index cff14091c4d..00000000000
--- a/docs/deployments/p08/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P08 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P08's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## High-resolution diffraction
-
-P08 uses a high-resolution monochromatic beam on a six-circle [diffractometer](sample.md) to measure surface / interface diffraction, reflectivity (XRR), and high-resolution powder / single-crystal diffraction, reading the [Eiger / Pilatus / Mythen detectors](detector.md).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-resolution diffraction / reflectivity | `diffraction` | surface / interface diffraction and reflectivity on the six-circle Kohzu diffractometer + area / strip detectors; reuses the `diffraction` slug P07 share, a further consumer (`TECH-1`) |
-
-## A diffraction beamline on familiar vocabulary
-
-P08 is the fleet's high-resolution diffraction beamline. Its technique reuses the `diffraction` slug already carried pending across the fleet, so it forces no new Method now. The instrument anatomy reuses existing Families: the monochromators bind `Monochromator`, the six-circle diffractometer `Goniometer`, the CRL `Transfocator`, the hexapod `Hexapod`, the detectors `Camera` / `EnergyDispersiveSpectrometer`. The rich detector set (Eiger / Pilatus / Mythen / PerkinElmer / Vortex) suits the breadth of diffraction modes but coins no new Family.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the reflectivity / rocking-curve scans, the reciprocal-space mapping, the high-resolution powder collection) are not written yet; they join as the deployment approaches the point where CORA drives P08. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p09/governance.md b/docs/deployments/p09/governance.md
deleted file mode 100644
index 3e919a3c203..00000000000
--- a/docs/deployments/p09/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P09, and the trust shape that will gate it. First cut.*
-
-Governance at P09 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P09 is CORA's seventh PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P09 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P09, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the three areas) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P09 also carries the hazard classes that come with a high-field magnetism endstation: a 14 T superconducting magnet and its liquid-helium cryogen, a stored-energy and field hazard that gates access to the MAG endstation. Those land with the instruments that bring them when the deployment firms up; the magnet is modelled as a sample-environment `Magnet` Asset, not a beam-steering device CORA drives.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P09, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p09/model.md b/docs/deployments/p09/model.md
deleted file mode 100644
index f6db0dff853..00000000000
--- a/docs/deployments/p09/model.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P09 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P09 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P09 new
-
-P09 is a seventh beamline at an existing Site, and the richest of the PETRA III set in technique breadth: resonant elastic X-ray scattering and HAXPES (MONO), diffraction (DIF), and high-field magnetism / XMCD (MAG, a 14 T magnet). At the modelling level it is the **second consumer of the polarization / magnetism vocabulary** the APS 4-ID deployment introduced: the phase retarder, the polarization analyzer, and the high-field magnet.
-
-## No new families (the 4-ID vocabulary ports cleanly)
-
-P09 coins no new Family. It binds the catalog `PhaseRetarder` Family (P09 was the second consumer, the rule-of-three signal with P22 that earned it into the catalog) and the graduated catalog `PolarizationAnalyzer` Family (earned across 4-ID / i10 / ID32 / P09, presenting Positioner) for its analyzer. Its 14 T magnet binds the graduated catalog `Magnet` Family (earned across 4-ID + i10-1 + ID32; presents `Regulator`), a further consumer. The diffractometers bind the catalog `Goniometer` Family (not the composed `Diffractometer` Assembly, the same call as P01 EH2); the optics bind `Monochromator` / `Mirror` / `Transfocator` / `Slit` / `Filter`; the sample environment binds `TemperatureController` / `Hexapod` / `LinearStage`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes.
-
-## The control plane
-
-P09 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its instrument diversity is high (OMS / VME58 steppers, Galil slits, PI + AttoCube piezos, a hexapod; PerkinElmer / Pilatus / Andor detectors, the SIS3302 digitizer, GPIB instruments). The handles are read from P09's public OnlineXML registry and carried confirm (`CTRL-1`). The resonant-scattering / magnetism acquisition (the energy / diffractometer / field scan with polarization switching) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the 4-ID seam.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
-- **The optics detail (`OPT-1`).** The DCM crystal cut, the mirror coatings, and the CRL detail are carried confirm-pending.
-- **The diffractometer structure (`DIFF-1`).** The MONO / DIF / MAG six-circle counts and detector arms are pending; modelled as `Goniometer` Assets, not `Diffractometer` Assemblies.
-- **The motor-bank axis roles (`GROUP-1`).** The MONO / DIF `p09/motor` banks carry no per-axis role; grouped as stage Assets.
-- **The polarization / magnet detail (`POL-1`, `MAG-1`).** The phase-retarder / analyzer geometry and the 14 T magnet field / control are pending; the polarization Families are the graduated catalog `PhaseRetarder` / `PolarizationAnalyzer`, and the magnet binds the graduated catalog `Magnet` Family (its per-Asset field / control detail pending).
-- **The detector roster (`DET-1`).** The detector models and the SIS3302 channel count (collapsed from the registry's ROI explosion) are named, not fully bound.
-- **The host mapping (`HOST-1`).** A shared Lambda reports on the bare `petra3` host; a stray `p07/hexapodsmall` row (a P07 device) is excluded from P09.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The resonant / magnetic Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p09_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p09/notes.md b/docs/deployments/p09/notes.md
new file mode 100644
index 00000000000..a4c311b73ee
--- /dev/null
+++ b/docs/deployments/p09/notes.md
@@ -0,0 +1,139 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P09 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P09's resonant-scattering, magnetic-scattering, and dichroism techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### Resonant elastic X-ray scattering
+
+P09 tunes the incident energy onto an absorption edge (the DCM) and measures the elastically scattered intensity on the six-circle [goniometer](sample.md), with the [phase retarder](sample.md) setting incident polarization and the [analyzer](sample.md) resolving the scattered polarization.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant elastic X-ray scattering | `resonant_scattering` | edge-tuned elastic scattering on the six-circle diffractometer + PerkinElmer / Pilatus, with polarization analysis; reuses the `resonant_scattering` slug 4-ID / i06 / i10 share, a further consumer (`TECH-1`) |
+
+### Magnetic scattering and dichroism
+
+P09's MAG endstation applies a 14 T field to the sample and measures the magnetic scattering / dichroism, with the phase retarder switching incident polarization for XMCD.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Magnetic scattering | `magnetic_scattering` | scattering in the 14 T high-field magnet; reuses the `magnetic_scattering` slug, a further consumer (`TECH-1`) |
+| X-ray magnetic circular / linear dichroism | `xmcd` | dichroism in the 14 T magnet with the phase retarder setting polarization; reuses the `xmcd` slug 4-ID / i06 / i10 share, a further consumer (`TECH-1`) |
+
+### A polarization / magnetism beamline on the 4-ID vocabulary
+
+P09 is the fleet's resonant-scattering and high-field-magnetism beamline. Its techniques are new to CORA's catalog (no resonant / magnetic Method is earned yet), but they reuse the slugs the APS 4-ID deployment and the Diamond i06 / i10 beamlines already carry pending, so none forces a new Method now. Crucially, the instrument anatomy reuses the polarization / magnetism Families 4-ID introduced: the phase retarder binds the catalog `PhaseRetarder` and the analyzer the catalog `PolarizationAnalyzer` (graduated across 4-ID / i10 / ID32 / P09, presenting Positioner), while the 14 T magnet binds the graduated catalog `Magnet` (earned across 4-ID + i10-1 + ID32), a further consumer. For `PhaseRetarder`, P09 was the rule-of-three signal (with P22) that earned it into the catalog. All recorded on [Model](#model).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the energy / diffractometer / field scan sequences, the polarization-switching dichroism loops) are not written yet; they join as the deployment approaches the point where CORA drives P09. Whether the resonant / magnetic Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P09, and the trust shape that will gate it. First cut.*
+
+Governance at P09 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P09 is CORA's seventh PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P09 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P09, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the three areas) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P09 also carries the hazard classes that come with a high-field magnetism endstation: a 14 T superconducting magnet and its liquid-helium cryogen, a stored-energy and field hazard that gates access to the MAG endstation. Those land with the instruments that bring them when the deployment firms up; the magnet is modelled as a sample-environment `Magnet` Asset, not a beam-steering device CORA drives.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P09, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P09 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P09 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P09 new
+
+P09 is a seventh beamline at an existing Site, and the richest of the PETRA III set in technique breadth: resonant elastic X-ray scattering and HAXPES (MONO), diffraction (DIF), and high-field magnetism / XMCD (MAG, a 14 T magnet). At the modelling level it is the **second consumer of the polarization / magnetism vocabulary** the APS 4-ID deployment introduced: the phase retarder, the polarization analyzer, and the high-field magnet.
+
+### No new families (the 4-ID vocabulary ports cleanly)
+
+P09 coins no new Family. It binds the catalog `PhaseRetarder` Family (P09 was the second consumer, the rule-of-three signal with P22 that earned it into the catalog) and the graduated catalog `PolarizationAnalyzer` Family (earned across 4-ID / i10 / ID32 / P09, presenting Positioner) for its analyzer. Its 14 T magnet binds the graduated catalog `Magnet` Family (earned across 4-ID + i10-1 + ID32; presents `Regulator`), a further consumer. The diffractometers bind the catalog `Goniometer` Family (not the composed `Diffractometer` Assembly, the same call as P01 EH2); the optics bind `Monochromator` / `Mirror` / `Transfocator` / `Slit` / `Filter`; the sample environment binds `TemperatureController` / `Hexapod` / `LinearStage`; the detectors bind `Camera` / `EnergyDispersiveSpectrometer`. Nothing in the catalog changes.
+
+### The control plane
+
+P09 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its instrument diversity is high (OMS / VME58 steppers, Galil slits, PI + AttoCube piezos, a hexapod; PerkinElmer / Pilatus / Andor detectors, the SIS3302 digitizer, GPIB instruments). The handles are read from P09's public OnlineXML registry and carried confirm (`CTRL-1`). The resonant-scattering / magnetism acquisition (the energy / diffractometer / field scan with polarization switching) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the 4-ID seam.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
+- **The optics detail (`OPT-1`).** The DCM crystal cut, the mirror coatings, and the CRL detail are carried confirm-pending.
+- **The diffractometer structure (`DIFF-1`).** The MONO / DIF / MAG six-circle counts and detector arms are pending; modelled as `Goniometer` Assets, not `Diffractometer` Assemblies.
+- **The motor-bank axis roles (`GROUP-1`).** The MONO / DIF `p09/motor` banks carry no per-axis role; grouped as stage Assets.
+- **The polarization / magnet detail (`POL-1`, `MAG-1`).** The phase-retarder / analyzer geometry and the 14 T magnet field / control are pending; the polarization Families are the graduated catalog `PhaseRetarder` / `PolarizationAnalyzer`, and the magnet binds the graduated catalog `Magnet` Family (its per-Asset field / control detail pending).
+- **The detector roster (`DET-1`).** The detector models and the SIS3302 channel count (collapsed from the registry's ROI explosion) are named, not fully bound.
+- **The host mapping (`HOST-1`).** A shared Lambda reports on the bare `petra3` host; a stray `p07/hexapodsmall` row (a P07 device) is excluded from P09.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The resonant / magnetic Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p09_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P09 team to confirm before the model can be trusted.*
+
+P09 was reverse-engineered from P09's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p09](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p09), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, magnet field, or energy calibration. P09 is CORA's seventh PETRA III beamline and the second consumer of the 4-ID polarization / magnetism vocabulary. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a MONO optics-and-resonant-scattering hutch, a DIF diffraction hutch, and a MAG magnetism endstation? | A `p09-mono` hutch and `p09-dif` / `p09-mag` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the MONO / DIF motor banks (`p09/motor/exp`, `p09/motor/dif`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+| HOST-1 | Nice-to-have | A shared Lambda detector reports on the bare `petra3` host, and the registry includes a `p07/hexapodsmall` row. Shared host / cross-beamline import? | The Lambda is noted unbound; the P07 device is excluded from P09. | The device-to-host mapping. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The DCM crystal cut, the mirror coatings, the CRL detail, and the absorber configuration. | A DCM `Monochromator`, two `Mirror`s, a `Transfocator` CRL, and `Filter` absorbers; physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The diffractometer circle counts (MONO / DIF / MAG) and whether each composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset per area (six-circle E6C), not the composed Diffractometer Assembly, until detector arms are confirmed. | The diffractometer modelling. |
+| POL-1 | Nice-to-have | The phase-retarder geometry (circles + AttoCube fine axes) and the polarization-analyzer detail. | The catalog `PhaseRetarder` Family and the catalog `PolarizationAnalyzer` Family (graduated across 4-ID / i10 / ID32 / P09); detail pending. | The polarization-instrument modelling. |
+| MAG-1 | Blocks-go-live | The MAG magnet field (14 T assumed), its cryogen, and its control / ramp interface. | A 14 T superconducting `Magnet` (the graduated catalog Family, a further consumer); field and control pending. | The per-Asset magnet field / control detail. |
+| SAMPLE-1 | Nice-to-have | The MAG sample-hexapod and PI-piezo geometry. | A `Hexapod` + `LinearStage` piezos; geometry pending. | The MAG sample modelling. |
+| TEMP-1 | Nice-to-have | The CryoCon / Lakeshore / LSCI sensor / setpoint handles. | `TemperatureController` controllers; cryogenic cooling. | The temperature-control modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per area, the PerkinElmer / Pilatus / Andor models, and the SIS3302 fluorescence channel count (collapsed from the registry's ROI explosion). | `Camera` area detectors plus an `EnergyDispersiveSpectrometer` SIS3302 / MCA; models pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P09 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the magnet liquid-helium supply. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do resonant scattering, magnetic scattering, and XMCD enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `resonant_scattering` / `magnetic_scattering` / `xmcd` slugs 4-ID / i06 / i10 share; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p09/questions.md b/docs/deployments/p09/questions.md
deleted file mode 100644
index 4ed5fd3be98..00000000000
--- a/docs/deployments/p09/questions.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Open questions
-
-*What CORA needs the P09 team to confirm before the model can be trusted.*
-
-P09 was reverse-engineered from P09's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p09](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p09), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, magnet field, or energy calibration. P09 is CORA's seventh PETRA III beamline and the second consumer of the 4-ID polarization / magnetism vocabulary. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a MONO optics-and-resonant-scattering hutch, a DIF diffraction hutch, and a MAG magnetism endstation? | A `p09-mono` hutch and `p09-dif` / `p09-mag` endstations, read from the OnlineXML host names. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the MONO / DIF motor banks (`p09/motor/exp`, `p09/motor/dif`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-| HOST-1 | Nice-to-have | A shared Lambda detector reports on the bare `petra3` host, and the registry includes a `p07/hexapodsmall` row. Shared host / cross-beamline import? | The Lambda is noted unbound; the P07 device is excluded from P09. | The device-to-host mapping. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The DCM crystal cut, the mirror coatings, the CRL detail, and the absorber configuration. | A DCM `Monochromator`, two `Mirror`s, a `Transfocator` CRL, and `Filter` absorbers; physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The diffractometer circle counts (MONO / DIF / MAG) and whether each composes a Diffractometer Assembly with a detector arm. | A `Goniometer` Asset per area (six-circle E6C), not the composed Diffractometer Assembly, until detector arms are confirmed. | The diffractometer modelling. |
-| POL-1 | Nice-to-have | The phase-retarder geometry (circles + AttoCube fine axes) and the polarization-analyzer detail. | The catalog `PhaseRetarder` Family and the catalog `PolarizationAnalyzer` Family (graduated across 4-ID / i10 / ID32 / P09); detail pending. | The polarization-instrument modelling. |
-| MAG-1 | Blocks-go-live | The MAG magnet field (14 T assumed), its cryogen, and its control / ramp interface. | A 14 T superconducting `Magnet` (the graduated catalog Family, a further consumer); field and control pending. | The per-Asset magnet field / control detail. |
-| SAMPLE-1 | Nice-to-have | The MAG sample-hexapod and PI-piezo geometry. | A `Hexapod` + `LinearStage` piezos; geometry pending. | The MAG sample modelling. |
-| TEMP-1 | Nice-to-have | The CryoCon / Lakeshore / LSCI sensor / setpoint handles. | `TemperatureController` controllers; cryogenic cooling. | The temperature-control modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per area, the PerkinElmer / Pilatus / Andor models, and the SIS3302 fluorescence channel count (collapsed from the registry's ROI explosion). | `Camera` area detectors plus an `EnergyDispersiveSpectrometer` SIS3302 / MCA; models pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P09 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the magnet liquid-helium supply. | Photon beam, cooling water, vacuum, and liquid helium. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do resonant scattering, magnetic scattering, and XMCD enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `resonant_scattering` / `magnetic_scattering` / `xmcd` slugs 4-ID / i06 / i10 share; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p09/techniques.md b/docs/deployments/p09/techniques.md
deleted file mode 100644
index 522b6f00ac8..00000000000
--- a/docs/deployments/p09/techniques.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Techniques
-
-*What the modelled part of P09 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P09's resonant-scattering, magnetic-scattering, and dichroism techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## Resonant elastic X-ray scattering
-
-P09 tunes the incident energy onto an absorption edge (the DCM) and measures the elastically scattered intensity on the six-circle [goniometer](sample.md), with the [phase retarder](sample.md) setting incident polarization and the [analyzer](sample.md) resolving the scattered polarization.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant elastic X-ray scattering | `resonant_scattering` | edge-tuned elastic scattering on the six-circle diffractometer + PerkinElmer / Pilatus, with polarization analysis; reuses the `resonant_scattering` slug 4-ID / i06 / i10 share, a further consumer (`TECH-1`) |
-
-## Magnetic scattering and dichroism
-
-P09's MAG endstation applies a 14 T field to the sample and measures the magnetic scattering / dichroism, with the phase retarder switching incident polarization for XMCD.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Magnetic scattering | `magnetic_scattering` | scattering in the 14 T high-field magnet; reuses the `magnetic_scattering` slug, a further consumer (`TECH-1`) |
-| X-ray magnetic circular / linear dichroism | `xmcd` | dichroism in the 14 T magnet with the phase retarder setting polarization; reuses the `xmcd` slug 4-ID / i06 / i10 share, a further consumer (`TECH-1`) |
-
-## A polarization / magnetism beamline on the 4-ID vocabulary
-
-P09 is the fleet's resonant-scattering and high-field-magnetism beamline. Its techniques are new to CORA's catalog (no resonant / magnetic Method is earned yet), but they reuse the slugs the APS 4-ID deployment and the Diamond i06 / i10 beamlines already carry pending, so none forces a new Method now. Crucially, the instrument anatomy reuses the polarization / magnetism Families 4-ID introduced: the phase retarder binds the catalog `PhaseRetarder` and the analyzer the catalog `PolarizationAnalyzer` (graduated across 4-ID / i10 / ID32 / P09, presenting Positioner), while the 14 T magnet binds the graduated catalog `Magnet` (earned across 4-ID + i10-1 + ID32), a further consumer. For `PhaseRetarder`, P09 was the rule-of-three signal (with P22) that earned it into the catalog. All recorded on [Model](model.md).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the energy / diffractometer / field scan sequences, the polarization-switching dichroism loops) are not written yet; they join as the deployment approaches the point where CORA drives P09. Whether the resonant / magnetic Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p10/governance.md b/docs/deployments/p10/governance.md
deleted file mode 100644
index e6e84419b6c..00000000000
--- a/docs/deployments/p10/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P10, and the trust shape that will gate it. First cut.*
-
-Governance at P10 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P10 is CORA's sixth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P10 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P10, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, including the P10 beam shutter, but not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the three experiment areas) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P10, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p10/model.md b/docs/deployments/p10/model.md
deleted file mode 100644
index 305f981c986..00000000000
--- a/docs/deployments/p10/model.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P10 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P10 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (coupled axes) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P10 new
-
-P10 is a sixth beamline at an existing Site, and a further XPCS beamline after the APS 8-ID and NSLS-II CHX exercises. Its science is coherent hard X-ray applications: XPCS, coherent diffraction imaging / ptychography, and coherent-beam diffraction, across three experiment areas. Its modelling first is the practice binding: P10's XPCS practice binds the **graduated** catalog `xpcs` Method directly, the first PETRA III practice whose Method is already earned (the others all carry pending practices). This is the reuse-earns-the-abstraction principle in action: a technique graduated at one facility (8-ID, EPICS) carries cleanly to another (PETRA III, Tango) without re-coining.
-
-## No new families
-
-P10 coins no new Family. The undulator binds `InsertionDevice`; the mono `Monochromator`; the CRL `Transfocator`; the hexapod `Hexapod`; the slits `Slit`; the mirrors `Mirror`; the two-theta arm `RotaryStage`; the sample / optics / nano stages `LinearStage`; the coupled axes `PseudoAxis`; the beam shutter `Shutter`; the wide detector suite `Camera`; the fluorescence detectors `EnergyDispersiveSpectrometer`; the LAB simulated diffractometer `Goniometer`. Nothing in the catalog changes. The Mythen strip detector is modelled as a `Camera` for now (a fold-vs-promote question deferred to the catalog owner, `DET-1`).
-
-## The control plane
-
-P10 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with the widest controller and detector diversity in the set (OMS, Galil DMC, SmarAct, AttoCube, hexapod, spk; Pilatus / Eiger / Lambda / PCO / Andor / Mythen / Quadro / Lima). The handles are read from P10's public OnlineXML registry and carried confirm (`CTRL-1`); the Lambda and Lima cameras report on a bare `p10` host (`HOST-1`). The XPCS acquisition (the coherent beam read by the high-frame-rate detector, the correlation computed downstream) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, and the correlation compute is `ComputePort` work, the same shape as the 8-ID XPCS seam.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
-- **The optics detail (`OPT-1`).** The DCM crystal cut, the optics-bank breakdown, the CRL focal sizes, and the mirror coatings are carried confirm-pending.
-- **The motor-bank axis roles (`GROUP-1`).** The `OPT_MOT`, `E1_MOT`, `E2_MOT` banks carry no per-axis role; grouped as stage Assets.
-- **The E2 / LCX sample detail (`SAMPLE-1`, `LCX-1`).** The sample-piezo / two-theta geometry and the LCX sub-station role are pending.
-- **The LAB status (`LAB-1`).** The LAB devices are simulation / test units; whether they are modelled as a live offline endstation or excluded is pending.
-- **The detector roster (`DET-1`).** The XPCS-detector assignment (Lambda vs Eiger), the detector models, and the Mythen fold-vs-promote are named, not fully bound.
-- **The host mapping (`HOST-1`).** The Lambda / Lima cameras report on a bare host; whether shared Tango DB or registry artifact is pending.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **`ptychography` Method (`TECH-1`).** Whether coherent imaging enters CORA's catalog is an owner decision; the practice renders unlinked, pending. (XPCS already binds the graduated Method.)
-- **The PSS permit signals (`PSS-1`).** The beam shutter is read but the permit leaves are not; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p10_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p10/notes.md b/docs/deployments/p10/notes.md
new file mode 100644
index 00000000000..1bca388a691
--- /dev/null
+++ b/docs/deployments/p10/notes.md
@@ -0,0 +1,135 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P10 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P10's primary technique, XPCS, is a graduated catalog Method (earned at the APS 8-ID), so its practice binds it directly; the coherent-imaging techniques reuse pending slugs (`TECH-1`).
+
+### X-ray photon correlation spectroscopy
+
+P10 illuminates the sample with a coherent beam and reads the speckle pattern on a high-frame-rate area detector (Lambda / Eiger); the intensity autocorrelation over time measures the sample dynamics.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray photon correlation spectroscopy (XPCS) | [`xpcs`](../../catalog/methods.md) | the coherent beam on the sample read by the high-frame-rate Lambda / Eiger, the correlation computed downstream; binds the graduated `xpcs` Method (earned at APS 8-ID), the second consumer |
+
+### Coherent diffraction imaging
+
+P10's E1 endstation focuses the coherent beam (the CRL) and records coherent diffraction patterns (the Quadro / Eiger) for ptychographic / coherent-diffraction reconstruction.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Coherent diffraction imaging / ptychography | `ptychography` | the focused coherent beam scanned across the sample, the diffraction recorded for phase retrieval; reuses the pending `ptychography` slug, a further consumer (`TECH-1`) |
+
+### A graduated Method meets a new facility
+
+P10 is a further XPCS beamline (after APS 8-ID and NSLS-II CHX). Unlike the other PETRA III beamlines (whose techniques are not yet earned and carry pending practices), P10's XPCS practice binds the graduated `xpcs` Method directly, reusing the abstraction the APS 8-ID deployment forced into the catalog. This is the reuse-earns-the-abstraction principle working as intended: a technique graduated at one facility carries cleanly to another on a different control plane. The coherent-imaging side reuses the pending `ptychography` slug; the instrument anatomy reuses existing Families (the CRL `Transfocator`, the hexapod `Hexapod`, the detector suite `Camera`).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the XPCS multi-tau / correlation sequences, the ptychographic scan trajectories, the coherent-diffraction exposures) are not written yet; they join as the deployment approaches the point where CORA drives P10. Whether `ptychography` enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P10, and the trust shape that will gate it. First cut.*
+
+Governance at P10 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P10 is CORA's sixth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P10 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P10, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, including the P10 beam shutter, but not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the three experiment areas) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P10, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P10 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P10 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (coupled axes) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P10 new
+
+P10 is a sixth beamline at an existing Site, and a further XPCS beamline after the APS 8-ID and NSLS-II CHX exercises. Its science is coherent hard X-ray applications: XPCS, coherent diffraction imaging / ptychography, and coherent-beam diffraction, across three experiment areas. Its modelling first is the practice binding: P10's XPCS practice binds the **graduated** catalog `xpcs` Method directly, the first PETRA III practice whose Method is already earned (the others all carry pending practices). This is the reuse-earns-the-abstraction principle in action: a technique graduated at one facility (8-ID, EPICS) carries cleanly to another (PETRA III, Tango) without re-coining.
+
+### No new families
+
+P10 coins no new Family. The undulator binds `InsertionDevice`; the mono `Monochromator`; the CRL `Transfocator`; the hexapod `Hexapod`; the slits `Slit`; the mirrors `Mirror`; the two-theta arm `RotaryStage`; the sample / optics / nano stages `LinearStage`; the coupled axes `PseudoAxis`; the beam shutter `Shutter`; the wide detector suite `Camera`; the fluorescence detectors `EnergyDispersiveSpectrometer`; the LAB simulated diffractometer `Goniometer`. Nothing in the catalog changes. The Mythen strip detector is modelled as a `Camera` for now (a fold-vs-promote question deferred to the catalog owner, `DET-1`).
+
+### The control plane
+
+P10 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with the widest controller and detector diversity in the set (OMS, Galil DMC, SmarAct, AttoCube, hexapod, spk; Pilatus / Eiger / Lambda / PCO / Andor / Mythen / Quadro / Lima). The handles are read from P10's public OnlineXML registry and carried confirm (`CTRL-1`); the Lambda and Lima cameras report on a bare `p10` host (`HOST-1`). The XPCS acquisition (the coherent beam read by the high-frame-rate detector, the correlation computed downstream) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, and the correlation compute is `ComputePort` work, the same shape as the 8-ID XPCS seam.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The OnlineXML exposes the gap, not the period; carried pending.
+- **The optics detail (`OPT-1`).** The DCM crystal cut, the optics-bank breakdown, the CRL focal sizes, and the mirror coatings are carried confirm-pending.
+- **The motor-bank axis roles (`GROUP-1`).** The `OPT_MOT`, `E1_MOT`, `E2_MOT` banks carry no per-axis role; grouped as stage Assets.
+- **The E2 / LCX sample detail (`SAMPLE-1`, `LCX-1`).** The sample-piezo / two-theta geometry and the LCX sub-station role are pending.
+- **The LAB status (`LAB-1`).** The LAB devices are simulation / test units; whether they are modelled as a live offline endstation or excluded is pending.
+- **The detector roster (`DET-1`).** The XPCS-detector assignment (Lambda vs Eiger), the detector models, and the Mythen fold-vs-promote are named, not fully bound.
+- **The host mapping (`HOST-1`).** The Lambda / Lima cameras report on a bare host; whether shared Tango DB or registry artifact is pending.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **`ptychography` Method (`TECH-1`).** Whether coherent imaging enters CORA's catalog is an owner decision; the practice renders unlinked, pending. (XPCS already binds the graduated Method.)
+- **The PSS permit signals (`PSS-1`).** The beam shutter is read but the permit leaves are not; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p10_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P10 team to confirm before the model can be trusted.*
+
+P10 was reverse-engineered from P10's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p10](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p10), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no coherence lengths, energy calibration, or physical positions. P10 is CORA's sixth PETRA III beamline and a further XPCS beamline (after APS 8-ID and NSLS-II CHX). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding three experiment areas (E1 coherent imaging, E2 XPCS / diffraction, LAB)? | A `p10-opt` hutch and three `p10-e1` / `p10-e2` / `p10-lab` areas. | The Enclosure grouping. |
+| LCX-1 | Nice-to-have | The LCX piezo sub-station: is it a distinct enclosure or a sample sub-stage within E2? | Modelled as a nano-positioning stage within the E2 enclosure. | The LCX placement. |
+| LAB-1 | Nice-to-have | The LAB area: is the simulated diffractometer a live offline endstation, or test-only (to exclude)? | Modelled as an offline `Goniometer` + detectors. | The LAB scope. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`OPT_MOT`, `E1_MOT01..97`, `E2_MOT01..96`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
+| OPT-1 | Blocks-go-live | The DCM crystal cut, the optics-bank breakdown (mirrors / slits / lenses), and the CRL focal sizes. | A DCM `Monochromator`, grouped optics stages, and an E1 CRL `Transfocator`; physical detail pending. | The optics modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Nice-to-have | The E2 sample-piezo / two-theta geometry and the LCX nano-positioner detail. | SmarAct / AttoCube `LinearStage` piezos and a `RotaryStage` two-theta arm; geometry pending. | The E2 / LCX sample modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector roster per experiment, the high-frame-rate XPCS-detector assignment (Lambda vs Eiger), the detector models, and whether the Mythen strip detector warrants a distinct Family. | A wide `Camera` suite plus `EnergyDispersiveSpectrometer` MCAs; the Mythen modelled as a `Camera` for now. | The detector modelling. |
+| HOST-1 | Nice-to-have | The Lambda and Lima cameras report on the bare `p10` host. Shared detector host, or registry artifact? | The cameras are homed in E2 (the XPCS detection stage); the host is flagged. | The detector-to-host mapping. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P10 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, and the role of the P10 beam shutter (read from the registry, safety role not). | Permit leaves to be named; the beam shutter bound to `Shutter`, safety role pending. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does coherent diffraction imaging / ptychography enter CORA's catalog as a Method? (XPCS already binds the graduated `xpcs` Method.) | Deferred: the coherent-imaging practice reuses the pending `ptychography` slug; XPCS is already earned. | The ptychography Capability. |
diff --git a/docs/deployments/p10/questions.md b/docs/deployments/p10/questions.md
deleted file mode 100644
index 806f19372af..00000000000
--- a/docs/deployments/p10/questions.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Open questions
-
-*What CORA needs the P10 team to confirm before the model can be trusted.*
-
-P10 was reverse-engineered from P10's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p10](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p10), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no coherence lengths, energy calibration, or physical positions. P10 is CORA's sixth PETRA III beamline and a further XPCS beamline (after APS 8-ID and NSLS-II CHX). Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding three experiment areas (E1 coherent imaging, E2 XPCS / diffraction, LAB)? | A `p10-opt` hutch and three `p10-e1` / `p10-e2` / `p10-lab` areas. | The Enclosure grouping. |
-| LCX-1 | Nice-to-have | The LCX piezo sub-station: is it a distinct enclosure or a sample sub-stage within E2? | Modelled as a nano-positioning stage within the E2 enclosure. | The LCX placement. |
-| LAB-1 | Nice-to-have | The LAB area: is the simulated diffractometer a live offline endstation, or test-only (to exclude)? | Modelled as an offline `Goniometer` + detectors. | The LAB scope. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`OPT_MOT`, `E1_MOT01..97`, `E2_MOT01..96`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; gap read, period pending. | The source Asset detail. |
-| OPT-1 | Blocks-go-live | The DCM crystal cut, the optics-bank breakdown (mirrors / slits / lenses), and the CRL focal sizes. | A DCM `Monochromator`, grouped optics stages, and an E1 CRL `Transfocator`; physical detail pending. | The optics modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Nice-to-have | The E2 sample-piezo / two-theta geometry and the LCX nano-positioner detail. | SmarAct / AttoCube `LinearStage` piezos and a `RotaryStage` two-theta arm; geometry pending. | The E2 / LCX sample modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector roster per experiment, the high-frame-rate XPCS-detector assignment (Lambda vs Eiger), the detector models, and whether the Mythen strip detector warrants a distinct Family. | A wide `Camera` suite plus `EnergyDispersiveSpectrometer` MCAs; the Mythen modelled as a `Camera` for now. | The detector modelling. |
-| HOST-1 | Nice-to-have | The Lambda and Lima cameras report on the bare `p10` host. Shared detector host, or registry artifact? | The cameras are homed in E2 (the XPCS detection stage); the host is flagged. | The detector-to-host mapping. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P10 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, and the role of the P10 beam shutter (read from the registry, safety role not). | Permit leaves to be named; the beam shutter bound to `Shutter`, safety role pending. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does coherent diffraction imaging / ptychography enter CORA's catalog as a Method? (XPCS already binds the graduated `xpcs` Method.) | Deferred: the coherent-imaging practice reuses the pending `ptychography` slug; XPCS is already earned. | The ptychography Capability. |
diff --git a/docs/deployments/p10/techniques.md b/docs/deployments/p10/techniques.md
deleted file mode 100644
index 941fcadb1d3..00000000000
--- a/docs/deployments/p10/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P10 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P10's primary technique, XPCS, is a graduated catalog Method (earned at the APS 8-ID), so its practice binds it directly; the coherent-imaging techniques reuse pending slugs (`TECH-1`).
-
-## X-ray photon correlation spectroscopy
-
-P10 illuminates the sample with a coherent beam and reads the speckle pattern on a high-frame-rate area detector (Lambda / Eiger); the intensity autocorrelation over time measures the sample dynamics.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray photon correlation spectroscopy (XPCS) | [`xpcs`](../../catalog/methods.md) | the coherent beam on the sample read by the high-frame-rate Lambda / Eiger, the correlation computed downstream; binds the graduated `xpcs` Method (earned at APS 8-ID), the second consumer |
-
-## Coherent diffraction imaging
-
-P10's E1 endstation focuses the coherent beam (the CRL) and records coherent diffraction patterns (the Quadro / Eiger) for ptychographic / coherent-diffraction reconstruction.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Coherent diffraction imaging / ptychography | `ptychography` | the focused coherent beam scanned across the sample, the diffraction recorded for phase retrieval; reuses the pending `ptychography` slug, a further consumer (`TECH-1`) |
-
-## A graduated Method meets a new facility
-
-P10 is a further XPCS beamline (after APS 8-ID and NSLS-II CHX). Unlike the other PETRA III beamlines (whose techniques are not yet earned and carry pending practices), P10's XPCS practice binds the graduated `xpcs` Method directly, reusing the abstraction the APS 8-ID deployment forced into the catalog. This is the reuse-earns-the-abstraction principle working as intended: a technique graduated at one facility carries cleanly to another on a different control plane. The coherent-imaging side reuses the pending `ptychography` slug; the instrument anatomy reuses existing Families (the CRL `Transfocator`, the hexapod `Hexapod`, the detector suite `Camera`).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the XPCS multi-tau / correlation sequences, the ptychographic scan trajectories, the coherent-diffraction exposures) are not written yet; they join as the deployment approaches the point where CORA drives P10. Whether `ptychography` enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p11/governance.md b/docs/deployments/p11/governance.md
deleted file mode 100644
index 29e0437baf0..00000000000
--- a/docs/deployments/p11/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P11, and the trust shape that will gate it. First cut.*
-
-Governance at P11 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P11 is CORA's fourth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01, P04, P06), until DESY staff confirm them (`GOV-1`). P11 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P11, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P11 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and (if present) an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P11, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p11/model.md b/docs/deployments/p11/model.md
deleted file mode 100644
index d39d1a4f268..00000000000
--- a/docs/deployments/p11/model.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P11 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P11 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P11 new
-
-P11 is a fourth beamline at an existing Site, and PETRA III's first macromolecular-crystallography beamline. Its science is high-throughput rotation MX (a crystal on a goniometer, cryostream-cooled, read by a Pilatus) plus coherent / full-field bio-imaging. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level.
-
-## No new families (the MX spine reuses the i03 precedent)
-
-P11 coins no new Family. The cryostream binds the graduated `TemperatureController`; the area detector binds `Camera`; the fluorescence detector binds `EnergyDispersiveSpectrometer`; the optics and experiment-hutch motions bind `LinearStage`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as MANACA and TPS 07A do), and the bio-imaging reuses `tomography`.
-
-## The honest limitation: a sparse registry
-
-Unlike P01 (named monochromators, KB mirrors) and P06 (named hexapods, Maia), the P11 OnlineXML does not label its goniometer or MX instruments: most of its devices are area-grouped motor banks (`oh_mot*`, `eh1/eh2/eh3_mot*`, the piezo bank). So this cut models the experiment hutch as grouped positioning stages with the MX instrument structure carried as a question (`MX-1`), rather than inventing a goniometer the registry does not name. This is the same posture the thinner reverse-engineered scaffolds take (FAXTOR's no-manifest, TPS 05A's inferred namespace): model what the source supports, flag the rest.
-
-## The control plane
-
-P11 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with the whole beamline on one Tango host (`haspp11oh`). The handles are read from P11's public OnlineXML registry and carried confirm (`CTRL-1`). The rotation-MX acquisition (the goniometer oscillation coupled to the Pilatus) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The OnlineXML exposes no undulator device; the source is carried pending.
-- **The optics breakdown (`OPT-1`).** The monochromator, mirrors, and slits are not individually labelled; the oh bank is grouped.
-- **The goniometer / MX structure (`MX-1`).** The registry does not name the goniometer; the eh banks are grouped, the MX instrument carried as a question.
-- **The motor-bank axis roles (`GROUP-1`).** The banks carry no per-axis role; grouped as stage Assets.
-- **The sample changer (`ROBOT-1`).** Not in the registry; would be a deferred sample-exchange Procedure, not a device.
-- **The detector model (`DET-1`).** The Pilatus variant and the geometry are named, not bound.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The MX Methods (`TECH-1`).** Whether MX and bio-imaging enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p11_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p11/notes.md b/docs/deployments/p11/notes.md
new file mode 100644
index 00000000000..f229775a940
--- /dev/null
+++ b/docs/deployments/p11/notes.md
@@ -0,0 +1,138 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P11 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P11 runs macromolecular crystallography and bio-imaging, reusing Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
+
+### Macromolecular crystallography
+
+P11 mounts a crystal on the goniometer (with cryostream cooling), rotates it through an oscillation, and reads frames on the [Pilatus area detector](detector.md). It is a high-throughput rotation-MX beamline.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the goniometer reading the Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS), a further consumer (`TECH-1`) |
+
+### Bio-imaging
+
+P11 also runs coherent / full-field bio-imaging on the experiment-hutch stages reading the area detector.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Bio-imaging | `tomography` | full-field / coherent imaging on the experiment-hutch stages + Pilatus; reuses the catalog `tomography` Method (the 2-BM / FXI lineage), a further consumer (`TECH-1`) |
+
+### A familiar beamline on familiar vocabulary
+
+P11 is the fleet's fourth-plus macromolecular-crystallography beamline and PETRA III's first. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, driven here through the PETRA III Tango / Sardana floor. It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet), and the bio-imaging reuses `tomography`; neither forces a new device Family. The automated sample changer, if present, would be a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the oscillation sequences and their exposures, the bio-imaging scans, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P11. Whether the MX Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P11, and the trust shape that will gate it. First cut.*
+
+Governance at P11 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P11 is CORA's fourth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines (with P01, P04, P06), until DESY staff confirm them (`GOV-1`). P11 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P11, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P11 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and (if present) an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P11, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P11 content lives, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P11 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P11 new
+
+P11 is a fourth beamline at an existing Site, and PETRA III's first macromolecular-crystallography beamline. Its science is high-throughput rotation MX (a crystal on a goniometer, cryostream-cooled, read by a Pilatus) plus coherent / full-field bio-imaging. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level.
+
+### No new families (the MX spine reuses the i03 precedent)
+
+P11 coins no new Family. The cryostream binds the graduated `TemperatureController`; the area detector binds `Camera`; the fluorescence detector binds `EnergyDispersiveSpectrometer`; the optics and experiment-hutch motions bind `LinearStage`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as MANACA and TPS 07A do), and the bio-imaging reuses `tomography`.
+
+### The honest limitation: a sparse registry
+
+Unlike P01 (named monochromators, KB mirrors) and P06 (named hexapods, Maia), the P11 OnlineXML does not label its goniometer or MX instruments: most of its devices are area-grouped motor banks (`oh_mot*`, `eh1/eh2/eh3_mot*`, the piezo bank). So this cut models the experiment hutch as grouped positioning stages with the MX instrument structure carried as a question (`MX-1`), rather than inventing a goniometer the registry does not name. This is the same posture the thinner reverse-engineered scaffolds take (FAXTOR's no-manifest, TPS 05A's inferred namespace): model what the source supports, flag the rest.
+
+### The control plane
+
+P11 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with the whole beamline on one Tango host (`haspp11oh`). The handles are read from P11's public OnlineXML registry and carried confirm (`CTRL-1`). The rotation-MX acquisition (the goniometer oscillation coupled to the Pilatus) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The OnlineXML exposes no undulator device; the source is carried pending.
+- **The optics breakdown (`OPT-1`).** The monochromator, mirrors, and slits are not individually labelled; the oh bank is grouped.
+- **The goniometer / MX structure (`MX-1`).** The registry does not name the goniometer; the eh banks are grouped, the MX instrument carried as a question.
+- **The motor-bank axis roles (`GROUP-1`).** The banks carry no per-axis role; grouped as stage Assets.
+- **The sample changer (`ROBOT-1`).** Not in the registry; would be a deferred sample-exchange Procedure, not a device.
+- **The detector model (`DET-1`).** The Pilatus variant and the geometry are named, not bound.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The MX Methods (`TECH-1`).** Whether MX and bio-imaging enter CORA's catalog is an owner decision; the Practices render unlinked, pending, reusing the existing slugs.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p11_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P11 team to confirm before the model can be trusted.*
+
+P11 was reverse-engineered from P11's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p11](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p11), branch `debian/jessie`) and a verified research brief, not from a live connection. The P11 registry is sparser in labelling than the other PETRA III beamlines: most devices are area-grouped motor banks whose per-axis roles are not exposed, so the goniometer and MX instruments are not individually resolvable. P11 is CORA's fourth PETRA III beamline and its first macromolecular-crystallography beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch and an experiment hutch? The registry exposes one Tango host (`haspp11oh`), so the split is inferred from device-name prefixes. | A `p11-oh` optics hutch and a `p11-eh` experiment hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator source (the OnlineXML exposes no undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_mot*`, `granite_mot*`, `eh1/eh2/eh3_mot*`, the piezo bank). | Grouped as area positioning stages carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator, mirrors, and slits within the oh / granite banks. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MX-1 | Blocks-build | The goniometer geometry and the MX instrument structure within the eh1 / eh2 / eh3 banks (the registry does not label them). | Grouped `LinearStage` experiment-hutch stages; the goniometer carried as a question. | The MX instrument modelling. |
+| TEMP-1 | Nice-to-have | The cryostream sensor / setpoint handles. | An Oxford Cryostream 700 bound to `TemperatureController`. | The temperature-control modelling. |
+| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop), if present. | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; not in the registry. | The sample-exchange modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The Pilatus detector variant (300k / 1M / 2M / 6M), the sample-to-detector geometry, and the XIA fluorescence detector channel count. | A `Camera` Pilatus plus an `EnergyDispersiveSpectrometer` XIA detector; model pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P11 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do rotation MX and bio-imaging enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the i03 `mx_data_collection` and the `tomography` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p11/questions.md b/docs/deployments/p11/questions.md
deleted file mode 100644
index ad12c30bb9a..00000000000
--- a/docs/deployments/p11/questions.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Open questions
-
-*What CORA needs the P11 team to confirm before the model can be trusted.*
-
-P11 was reverse-engineered from P11's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p11](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p11), branch `debian/jessie`) and a verified research brief, not from a live connection. The P11 registry is sparser in labelling than the other PETRA III beamlines: most devices are area-grouped motor banks whose per-axis roles are not exposed, so the goniometer and MX instruments are not individually resolvable. P11 is CORA's fourth PETRA III beamline and its first macromolecular-crystallography beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch and an experiment hutch? The registry exposes one Tango host (`haspp11oh`), so the split is inferred from device-name prefixes. | A `p11-oh` optics hutch and a `p11-eh` experiment hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator source (the OnlineXML exposes no undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_mot*`, `granite_mot*`, `eh1/eh2/eh3_mot*`, the piezo bank). | Grouped as area positioning stages carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator, mirrors, and slits within the oh / granite banks. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MX-1 | Blocks-build | The goniometer geometry and the MX instrument structure within the eh1 / eh2 / eh3 banks (the registry does not label them). | Grouped `LinearStage` experiment-hutch stages; the goniometer carried as a question. | The MX instrument modelling. |
-| TEMP-1 | Nice-to-have | The cryostream sensor / setpoint handles. | An Oxford Cryostream 700 bound to `TemperatureController`. | The temperature-control modelling. |
-| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop), if present. | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; not in the registry. | The sample-exchange modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The Pilatus detector variant (300k / 1M / 2M / 6M), the sample-to-detector geometry, and the XIA fluorescence detector channel count. | A `Camera` Pilatus plus an `EnergyDispersiveSpectrometer` XIA detector; model pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P11 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do rotation MX and bio-imaging enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the i03 `mx_data_collection` and the `tomography` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p11/techniques.md b/docs/deployments/p11/techniques.md
deleted file mode 100644
index 4b618d7e110..00000000000
--- a/docs/deployments/p11/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P11 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P11 runs macromolecular crystallography and bio-imaging, reusing Methods the fleet already carries pending, so the Methods below render unlinked until a technique enters scope (`TECH-1`).
-
-## Macromolecular crystallography
-
-P11 mounts a crystal on the goniometer (with cryostream cooling), rotates it through an oscillation, and reads frames on the [Pilatus area detector](detector.md). It is a high-throughput rotation-MX beamline.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the goniometer reading the Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS), a further consumer (`TECH-1`) |
-
-## Bio-imaging
-
-P11 also runs coherent / full-field bio-imaging on the experiment-hutch stages reading the area detector.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Bio-imaging | `tomography` | full-field / coherent imaging on the experiment-hutch stages + Pilatus; reuses the catalog `tomography` Method (the 2-BM / FXI lineage), a further consumer (`TECH-1`) |
-
-## A familiar beamline on familiar vocabulary
-
-P11 is the fleet's fourth-plus macromolecular-crystallography beamline and PETRA III's first. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, driven here through the PETRA III Tango / Sardana floor. It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet), and the bio-imaging reuses `tomography`; neither forces a new device Family. The automated sample changer, if present, would be a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the oscillation sequences and their exposures, the bio-imaging scans, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P11. Whether the MX Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p13/governance.md b/docs/deployments/p13/governance.md
deleted file mode 100644
index fd8f9389edb..00000000000
--- a/docs/deployments/p13/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P13, and the trust shape that will gate it. First cut.*
-
-Governance at P13 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P13 is CORA's first EMBL Hamburg beamline, and the first **sub-operator** on the PETRA III Site: the beamline shares the ring and Facility with the DESY beamlines but is operated by EMBL Hamburg, with its own staff and its own MXCuBE control domain. The EMBL Hamburg operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), distinct from the DESY pool that P01 / P06 / P11 share, until EMBL staff confirm them (`GOV-1`). P13 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P13, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The MXCuBE config carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The interlock at P13 is operated by DESY (the ring host) even where EMBL operates the beamline, so the boundary between the DESY-issued site clearance and the EMBL-operated experiment is itself a question (`GOV-1`). What is already settled is the shape: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P13 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
-
-The concrete Zone, Conduit, and Policy instances, and the EMBL operator pool, land when the deployment approaches the point where CORA drives P13, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p13/model.md b/docs/deployments/p13/model.md
deleted file mode 100644
index b05b4a1cc76..00000000000
--- a/docs/deployments/p13/model.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P13 content lives, the sub-operator seam it exercises, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P13 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P13 new
-
-P13 is CORA's first EMBL Hamburg beamline, and the first **sub-operator** at an existing Site: it sits on the PETRA III ring but is operated by EMBL Hamburg, not DESY, with its own control domain. Its science is rotation MX (a crystal on the EMBLMiniDiff, cryo-cooled, read by an Eiger or Pilatus). At the vocabulary level it is a reuse-and-reinforce deployment; the new thing it exercises is the **sub-operator seam**, not a new device or technique.
-
-## The sub-operator seam (the new modelling exercise)
-
-The PETRA III Site already carries the DESY house style (Tango / Sardana / OnlineXML). P13 adds a distinct control-domain *within* the same Site and Facility: EMBL Hamburg runs MXCuBE over the Exporter protocol (the microdiff host) and TINE channels. This is recorded as an EMBL-Hamburg house-style section on the [PETRA III Site](../petra-iii/index.md) descriptor, so the Site now documents two operators with two control floors on one ring (`SEAM-1`). It is the first time CORA models operator and control-floor heterogeneity below the Site boundary; the [seam model](../../architecture/index.md) treats the floor (EPICS / Tango / MXCuBE+Exporter+TINE) as the wall CORA's edge conducts over, never owns.
-
-## No new families (the MX spine reuses the i03 precedent)
-
-P13 coins no new Family. The EMBLMiniDiff binds the graduated `Goniometer`; the area detectors bind `Camera`; the XRF detector binds `EnergyDispersiveSpectrometer`; the aperture / beamstop / objective bind `Aperture` / `BeamStop` / `Objective`; the sample illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the optics motions bind `LinearStage`, the energy and detector distance `PseudoAxis`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as MANACA, TPS 07A, and P11 do).
-
-## The gain over P11: a config that names the instrument
-
-Unlike P11's OnlineXML (area-grouped motor banks, no named goniometer), EMBL's MXCuBE config names the EMBLMiniDiff and its omega / kappa / sample-centring axes, the aperture, the beamstop, the detectors by model. So P13's experiment hutch resolves into a real `Goniometer` instrument rather than grouped stages. This is the same "model what the source supports" posture P11 takes, but the richer source supports more: the limitation moves from "what is the instrument" to "what are its exact geometry and ranges" (`MX-1`).
-
-## The control plane
-
-P13 sits on EMBL Hamburg's MXCuBE + Exporter + TINE domain, distinct from the DESY Tango / Sardana floor, with the diffractometer motions Exporter-hosted (`p13md201.embl-hamburg.de:9001`) and the detector / energy / beam services on TINE (`/P13/...`). The handles are read from EMBL's public MXCuBE config and carried confirm (`CTRL-1`). The rotation-MX acquisition (the goniometer oscillation coupled to the Eiger) runs as an MXCuBE data-collection routine; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The MXCuBE config exposes the energy service, not the undulator device; the source is carried pending.
-- **The optics breakdown (`OPT-1`, `ENERGY-1`).** The monochromator and KB mirror Assets are not individually labelled; the motions are grouped, the energy carried as a pseudo-axis.
-- **The goniometer geometry (`MX-1`).** The EMBLMiniDiff is named and bound to `Goniometer`, but its kappa range and axis offsets are not in the config.
-- **The cryostream (`CRYO-1`).** Not a labelled device in the config; carried as a question, with the liquid nitrogen a Supply.
-- **The sample changer (`ROBOT-1`).** MXCuBE bookkeeping, not a device; a deferred sample-exchange Procedure.
-- **The detector model detail (`DET-1`).** The Eiger 16M and Pilatus 6M are named; the ROI modes and geometry are pending.
-- **The on-axis camera handle (`OAV-1`).** The viewing cameras carry no control handle in the config object.
-- **The handle freshness (`CTRL-1`).** The config is the upstream `develop` branch; some handles may lag the live beamline.
-- **The operator / safety boundary (`GOV-1`).** The EMBL-operated beamline on the DESY-hosted ring splits operator from interlock host; the boundary is pending.
-- **The MX Method (`TECH-1`).** Whether MX enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the existing slug.
-- **The PSS permit signals (`PSS-1`).** Not in the config; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p13_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p13/notes.md b/docs/deployments/p13/notes.md
new file mode 100644
index 00000000000..666fb80b52c
--- /dev/null
+++ b/docs/deployments/p13/notes.md
@@ -0,0 +1,140 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P13 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P13 runs macromolecular crystallography, reusing a Method the fleet already carries pending, so the Method below renders unlinked until a technique enters scope (`TECH-1`).
+
+### Macromolecular crystallography
+
+P13 mounts a crystal on the EMBLMiniDiff microdiffractometer (with cryostream cooling), rotates it through an oscillation, and reads frames on the [Eiger or Pilatus area detector](detector.md). It is a high-throughput rotation-MX beamline, with an XRF detector for anomalous-edge identification.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the EMBLMiniDiff reading the Eiger / Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS / P11), a further consumer (`TECH-1`) |
+
+### A familiar beamline on an unfamiliar floor
+
+P13 is the fleet's seventh macromolecular-crystallography beamline and CORA's first at EMBL Hamburg. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy. What is new is not the technique but the floor it runs on: where P11 drives MX through the DESY Tango / Sardana stack, P13 drives it through EMBL's MXCuBE over Exporter + TINE (`SEAM-1`). It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet); it forces no new device Family. The automated sample changer is a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the oscillation sequences and their exposures, the anomalous-edge scans, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P13. Whether the MX Method enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P13, and the trust shape that will gate it. First cut.*
+
+Governance at P13 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P13 is CORA's first EMBL Hamburg beamline, and the first **sub-operator** on the PETRA III Site: the beamline shares the ring and Facility with the DESY beamlines but is operated by EMBL Hamburg, with its own staff and its own MXCuBE control domain. The EMBL Hamburg operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), distinct from the DESY pool that P01 / P06 / P11 share, until EMBL staff confirm them (`GOV-1`). P13 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P13, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The MXCuBE config carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The interlock at P13 is operated by DESY (the ring host) even where EMBL operates the beamline, so the boundary between the DESY-issued site clearance and the EMBL-operated experiment is itself a question (`GOV-1`). What is already settled is the shape: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P13 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutch. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
+
+The concrete Zone, Conduit, and Policy instances, and the EMBL operator pool, land when the deployment approaches the point where CORA drives P13, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P13 content lives, the sub-operator seam it exercises, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P13 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P13 new
+
+P13 is CORA's first EMBL Hamburg beamline, and the first **sub-operator** at an existing Site: it sits on the PETRA III ring but is operated by EMBL Hamburg, not DESY, with its own control domain. Its science is rotation MX (a crystal on the EMBLMiniDiff, cryo-cooled, read by an Eiger or Pilatus). At the vocabulary level it is a reuse-and-reinforce deployment; the new thing it exercises is the **sub-operator seam**, not a new device or technique.
+
+### The sub-operator seam (the new modelling exercise)
+
+The PETRA III Site already carries the DESY house style (Tango / Sardana / OnlineXML). P13 adds a distinct control-domain *within* the same Site and Facility: EMBL Hamburg runs MXCuBE over the Exporter protocol (the microdiff host) and TINE channels. This is recorded as an EMBL-Hamburg house-style section on the [PETRA III Site](../petra-iii/index.md) descriptor, so the Site now documents two operators with two control floors on one ring (`SEAM-1`). It is the first time CORA models operator and control-floor heterogeneity below the Site boundary; the [seam model](../../architecture/index.md) treats the floor (EPICS / Tango / MXCuBE+Exporter+TINE) as the wall CORA's edge conducts over, never owns.
+
+### No new families (the MX spine reuses the i03 precedent)
+
+P13 coins no new Family. The EMBLMiniDiff binds the graduated `Goniometer`; the area detectors bind `Camera`; the XRF detector binds `EnergyDispersiveSpectrometer`; the aperture / beamstop / objective bind `Aperture` / `BeamStop` / `Objective`; the sample illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the optics motions bind `LinearStage`, the energy and detector distance `PseudoAxis`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as MANACA, TPS 07A, and P11 do).
+
+### The gain over P11: a config that names the instrument
+
+Unlike P11's OnlineXML (area-grouped motor banks, no named goniometer), EMBL's MXCuBE config names the EMBLMiniDiff and its omega / kappa / sample-centring axes, the aperture, the beamstop, the detectors by model. So P13's experiment hutch resolves into a real `Goniometer` instrument rather than grouped stages. This is the same "model what the source supports" posture P11 takes, but the richer source supports more: the limitation moves from "what is the instrument" to "what are its exact geometry and ranges" (`MX-1`).
+
+### The control plane
+
+P13 sits on EMBL Hamburg's MXCuBE + Exporter + TINE domain, distinct from the DESY Tango / Sardana floor, with the diffractometer motions Exporter-hosted (`p13md201.embl-hamburg.de:9001`) and the detector / energy / beam services on TINE (`/P13/...`). The handles are read from EMBL's public MXCuBE config and carried confirm (`CTRL-1`). The rotation-MX acquisition (the goniometer oscillation coupled to the Eiger) runs as an MXCuBE data-collection routine; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The MXCuBE config exposes the energy service, not the undulator device; the source is carried pending.
+- **The optics breakdown (`OPT-1`, `ENERGY-1`).** The monochromator and KB mirror Assets are not individually labelled; the motions are grouped, the energy carried as a pseudo-axis.
+- **The goniometer geometry (`MX-1`).** The EMBLMiniDiff is named and bound to `Goniometer`, but its kappa range and axis offsets are not in the config.
+- **The cryostream (`CRYO-1`).** Not a labelled device in the config; carried as a question, with the liquid nitrogen a Supply.
+- **The sample changer (`ROBOT-1`).** MXCuBE bookkeeping, not a device; a deferred sample-exchange Procedure.
+- **The detector model detail (`DET-1`).** The Eiger 16M and Pilatus 6M are named; the ROI modes and geometry are pending.
+- **The on-axis camera handle (`OAV-1`).** The viewing cameras carry no control handle in the config object.
+- **The handle freshness (`CTRL-1`).** The config is the upstream `develop` branch; some handles may lag the live beamline.
+- **The operator / safety boundary (`GOV-1`).** The EMBL-operated beamline on the DESY-hosted ring splits operator from interlock host; the boundary is pending.
+- **The MX Method (`TECH-1`).** Whether MX enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the existing slug.
+- **The PSS permit signals (`PSS-1`).** Not in the config; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p13_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P13 team to confirm before the model can be trusted.*
+
+P13 was reverse-engineered from EMBL Hamburg's own public MXCuBE HardwareObjects configuration ([github.com/mxcube/mxcubecore](https://github.com/mxcube/mxcubecore/tree/develop/mxcubecore/configuration/embl_hh_p13), `configuration/embl_hh_p13`), not from a live connection. EMBL publishes a richer config than the DESY OnlineXML, so the diffractometer and its axes are named (the experiment hutch resolves into a real `Goniometer`), but the exact geometry, the optics breakdown, and the safety / operator boundary are not in it. P13 is CORA's first EMBL Hamburg beamline and the first sub-operator on the PETRA III Site. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch and an experiment hutch? The split is inferred from the device prefixes and the MX layout. | A `p13-oh` optics hutch and a `p13-eh` experiment hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator source (the MXCuBE config exposes the energy service, not the undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the KB mirror motions (`/P13/P13Kb.CDI/*`). | Grouped as the optics-hutch focusing stage; per-mirror Assets pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and the KB mirrors within the focusing motions, and the aperture-size table. | Grouped `LinearStage` optics motions plus a beam-defining `Aperture`; the breakdown pending. | The optics modelling. |
+| ENERGY-1 | Nice-to-have | The energy / monochromator coupling behind the `TINEEnergy` service (`/P13/Energy/P13Energy`). | A `PseudoAxis` energy service; the mono motions it drives pending. | The energy modelling. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MX-1 | Blocks-build | The EMBLMiniDiff goniometer geometry (kappa range, axis offsets, the omega / kappa / centring axis assignment). | The EMBLMiniDiff bound to the graduated `Goniometer` with its named axes; the geometry carried as a question. | The MX instrument modelling. |
+| OAV-1 | Nice-to-have | The on-axis viewing objective (MicrodiffZoom) magnification and the on-axis / sample-changer camera handles. | An `Objective` zoom plus `Camera` viewing; the camera handle pending. | The OAV modelling. |
+| CRYO-1 | Nice-to-have | The cryostream (cooler model, sensor / setpoint handles); it is not a labelled device in the MXCuBE config. | Carried as a question; the liquid nitrogen a Supply observation, not a device. | The temperature-control modelling. |
+| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop). | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; MXCuBE bookkeeping, not a device. | The sample-exchange modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector models (Eiger 16M, Pilatus 6M read from the config), their ROI modes, and the sample-to-detector geometry. | Two `Camera` area detectors plus a derived `PseudoAxis` distance; the geometry pending. | The detector modelling. |
+| DIAG-1 | Nice-to-have | The beam-diagnostic service split (the BCU intensity / centring services and the pin-diode flux). | Grouped `FluxMonitor` diagnostics; the per-service split pending. | The diagnostic modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Exporter / TINE control handles per P13 device, and whether the upstream MXCuBE `develop` config matches the live beamline. | The handles read from the public MXCuBE config, carried pending; the floor is MXCuBE over Exporter + TINE. | Binding each Asset's control handle. |
+| SEAM-1 | Blocks-go-live | The EMBL Hamburg control domain: MXCuBE over Exporter (microdiff) + TINE, distinct from the DESY Tango / Sardana floor. | A sub-operator control-domain within the PETRA III Site; EMBL's house style recorded on the Site. | The seam and Site modelling. |
+| GOV-1 | Blocks-go-live | The EMBL Hamburg operator pool, the safety-review structure, and the boundary between the DESY-hosted ring interlock and the EMBL-operated beamline. | Carried pending on the PETRA III Site, distinct from the DESY pool; the operator / interlock boundary a question. | The governance principals. |
+| PSS-1 | Blocks-go-live | The personnel-safety permit signals and the photon / front-end shutters (absent from the MXCuBE config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does rotation MX enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the i03 `mx_data_collection` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p13/questions.md b/docs/deployments/p13/questions.md
deleted file mode 100644
index 5547bfe1dc3..00000000000
--- a/docs/deployments/p13/questions.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Open questions
-
-*What CORA needs the P13 team to confirm before the model can be trusted.*
-
-P13 was reverse-engineered from EMBL Hamburg's own public MXCuBE HardwareObjects configuration ([github.com/mxcube/mxcubecore](https://github.com/mxcube/mxcubecore/tree/develop/mxcubecore/configuration/embl_hh_p13), `configuration/embl_hh_p13`), not from a live connection. EMBL publishes a richer config than the DESY OnlineXML, so the diffractometer and its axes are named (the experiment hutch resolves into a real `Goniometer`), but the exact geometry, the optics breakdown, and the safety / operator boundary are not in it. P13 is CORA's first EMBL Hamburg beamline and the first sub-operator on the PETRA III Site. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch and an experiment hutch? The split is inferred from the device prefixes and the MX layout. | A `p13-oh` optics hutch and a `p13-eh` experiment hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator source (the MXCuBE config exposes the energy service, not the undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the KB mirror motions (`/P13/P13Kb.CDI/*`). | Grouped as the optics-hutch focusing stage; per-mirror Assets pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and the KB mirrors within the focusing motions, and the aperture-size table. | Grouped `LinearStage` optics motions plus a beam-defining `Aperture`; the breakdown pending. | The optics modelling. |
-| ENERGY-1 | Nice-to-have | The energy / monochromator coupling behind the `TINEEnergy` service (`/P13/Energy/P13Energy`). | A `PseudoAxis` energy service; the mono motions it drives pending. | The energy modelling. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MX-1 | Blocks-build | The EMBLMiniDiff goniometer geometry (kappa range, axis offsets, the omega / kappa / centring axis assignment). | The EMBLMiniDiff bound to the graduated `Goniometer` with its named axes; the geometry carried as a question. | The MX instrument modelling. |
-| OAV-1 | Nice-to-have | The on-axis viewing objective (MicrodiffZoom) magnification and the on-axis / sample-changer camera handles. | An `Objective` zoom plus `Camera` viewing; the camera handle pending. | The OAV modelling. |
-| CRYO-1 | Nice-to-have | The cryostream (cooler model, sensor / setpoint handles); it is not a labelled device in the MXCuBE config. | Carried as a question; the liquid nitrogen a Supply observation, not a device. | The temperature-control modelling. |
-| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop). | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; MXCuBE bookkeeping, not a device. | The sample-exchange modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector models (Eiger 16M, Pilatus 6M read from the config), their ROI modes, and the sample-to-detector geometry. | Two `Camera` area detectors plus a derived `PseudoAxis` distance; the geometry pending. | The detector modelling. |
-| DIAG-1 | Nice-to-have | The beam-diagnostic service split (the BCU intensity / centring services and the pin-diode flux). | Grouped `FluxMonitor` diagnostics; the per-service split pending. | The diagnostic modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Exporter / TINE control handles per P13 device, and whether the upstream MXCuBE `develop` config matches the live beamline. | The handles read from the public MXCuBE config, carried pending; the floor is MXCuBE over Exporter + TINE. | Binding each Asset's control handle. |
-| SEAM-1 | Blocks-go-live | The EMBL Hamburg control domain: MXCuBE over Exporter (microdiff) + TINE, distinct from the DESY Tango / Sardana floor. | A sub-operator control-domain within the PETRA III Site; EMBL's house style recorded on the Site. | The seam and Site modelling. |
-| GOV-1 | Blocks-go-live | The EMBL Hamburg operator pool, the safety-review structure, and the boundary between the DESY-hosted ring interlock and the EMBL-operated beamline. | Carried pending on the PETRA III Site, distinct from the DESY pool; the operator / interlock boundary a question. | The governance principals. |
-| PSS-1 | Blocks-go-live | The personnel-safety permit signals and the photon / front-end shutters (absent from the MXCuBE config). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does rotation MX enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the i03 `mx_data_collection` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p13/techniques.md b/docs/deployments/p13/techniques.md
deleted file mode 100644
index 789a836eb6c..00000000000
--- a/docs/deployments/p13/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P13 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P13 runs macromolecular crystallography, reusing a Method the fleet already carries pending, so the Method below renders unlinked until a technique enters scope (`TECH-1`).
-
-## Macromolecular crystallography
-
-P13 mounts a crystal on the EMBLMiniDiff microdiffractometer (with cryostream cooling), rotates it through an oscillation, and reads frames on the [Eiger or Pilatus area detector](detector.md). It is a high-throughput rotation-MX beamline, with an XRF detector for anomalous-edge identification.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the EMBLMiniDiff reading the Eiger / Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS / P11), a further consumer (`TECH-1`) |
-
-## A familiar beamline on an unfamiliar floor
-
-P13 is the fleet's seventh macromolecular-crystallography beamline and CORA's first at EMBL Hamburg. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy. What is new is not the technique but the floor it runs on: where P11 drives MX through the DESY Tango / Sardana stack, P13 drives it through EMBL's MXCuBE over Exporter + TINE (`SEAM-1`). It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet); it forces no new device Family. The automated sample changer is a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the oscillation sequences and their exposures, the anomalous-edge scans, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P13. Whether the MX Method enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p14/governance.md b/docs/deployments/p14/governance.md
deleted file mode 100644
index 255fa769c67..00000000000
--- a/docs/deployments/p14/governance.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Governance
-
-*Who will act at P14, and the trust shape that will gate it. First cut.*
-
-Governance at P14 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P14 is CORA's second EMBL Hamburg beamline, the sibling of [P13](../p13/governance.md) and, like it, a **sub-operator** on the PETRA III Site: the beamline shares the ring and Facility with the DESY beamlines but is operated by EMBL Hamburg, with its own staff and its own MXCuBE control domain. The EMBL Hamburg operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), distinct from the DESY pool and shared with P13, until EMBL staff confirm them (`GOV-1`). P14 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P14, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The two-hutch layout adds a governance nuance: EH1 and EH2 are separate experiment hutches under one beamline, so the trust shape would scope per hutch (each hutch its own Zone of resources and its own access state) while sharing the source / optics chain. That per-hutch scoping is carried as part of the enclosure question (`EH-1`).
-
-The safety tier is the other piece that is not yet settled. The MXCuBE configs carry beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The interlock is operated by DESY (the ring host) even where EMBL operates the beamline, so the boundary between the DESY-issued site clearance and the EMBL-operated experiment is itself a question (`GOV-1`). What is already settled is the shape: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-P14 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutches. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
-
-The concrete Zone, Conduit, and Policy instances, and the EMBL operator pool, land when the deployment approaches the point where CORA drives P14, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p14/model.md b/docs/deployments/p14/model.md
deleted file mode 100644
index 2aafdf2e107..00000000000
--- a/docs/deployments/p14/model.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P14 content lives, the multi-endstation topology it exercises, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P14 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P14 new
-
-P14 is CORA's second EMBL Hamburg beamline (the sibling of P13) and the **first two-endstation MX beamline** CORA models: one source / optics chain feeding two experiment hutches, EH1 (the EMBLMiniDiff + Eiger detectors) and EH2 (the EMBLBSD + Pilatus 2M). At the vocabulary level it is a reuse-and-reinforce deployment; the new thing it exercises is the **multi-endstation topology under one beamline**, plus the high-energy CdTe detector variants and the X-ray imaging camera.
-
-## Two endstations, one source (the new modelling exercise)
-
-P13 established the EMBL sub-operator control-domain; P14 reuses it and adds the multi-hutch shape. The optics chain (KB mirrors, CRL transfocator, beam-defining slits, shared photon energy) feeds two experiment hutches, each with its own diffractometer host. CORA models this as three enclosures (`p14-oh`, `p14-eh1`, `p14-eh2`) under one root Asset, with the energy and CRL services shared and each hutch carrying its own goniometer, detector, and sample optics (`EH-1`). The trust shape would scope per hutch while sharing the source, a governance nuance carried with the enclosure question.
-
-## No new families (the MX spine reuses the i03 precedent)
-
-P14 coins no new Family. Both diffractometers bind the graduated `Goniometer`; the area detectors bind `Camera`; the XRF detector binds `EnergyDispersiveSpectrometer`; the CRL binds `Transfocator`; the slits bind `Slit`; the focusing optic binds `Mirror`; the sample illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the optics motions bind `LinearStage`, the energy and detector distance `PseudoAxis`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as P13 and the wider MX fleet do).
-
-## The honest limitation: published mockups
-
-The EH2 config (`embl_hh_pe2`) publishes some axes as `MotorMockup`, a simulation placeholder rather than a live device handle. Rather than present these as real, the EH2 diffractometer and table are carried with a caution marker (`MOCK-1`): the instrument is named and bound, but whether each axis is live on the floor or a config stub is a confirm. This is the same "model what the source supports, flag the rest" posture P11 and P13 take, applied to a source that mixes live and simulated entries.
-
-## The control plane
-
-P14 sits on EMBL Hamburg's MXCuBE + Exporter + TINE domain, distinct from the DESY Tango / Sardana floor, with the diffractometer motions Exporter-hosted (`p14md301` / `p14md302` for EH1, `pe2bsd01` for EH2) and the detector / energy / beam services on TINE (`/P14/...`, `/PE2/...`). The handles are read from EMBL's public MXCuBE configs and carried confirm (`CTRL-1`). The rotation-MX acquisition runs as an MXCuBE data-collection routine; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A and its sibling P13.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The MXCuBE config exposes the energy service, not the undulator device; the source is carried pending.
-- **The optics breakdown (`OPT-1`, `ENERGY-1`).** The monochromator and KB mirror Assets are not individually labelled; the motions are grouped, the energy carried as a pseudo-axis, the CRL and slits bound but uncharacterized.
-- **The goniometer geometries (`MX-1`).** Both diffractometers are named and bound to `Goniometer`, but their kappa ranges and axis offsets are not in the configs.
-- **The EH2 mockups (`MOCK-1`).** Some EH2 axes are `MotorMockup`; whether each is live or simulated is a confirm.
-- **The EH2 table handle (`TABLE-1`).** The EH2 positioning table carries no control handle in the config object.
-- **The cryostream (`CRYO-1`).** Not a labelled device in the configs; carried as a question, with the liquid nitrogen a Supply.
-- **The sample changer (`ROBOT-1`).** MXCuBE bookkeeping, not a device; a deferred sample-exchange Procedure.
-- **The detector model detail (`DET-1`).** The Eiger variants and Pilatus 2M are named; the ROI modes and geometry are pending.
-- **The imaging / on-axis camera handles (`OAV-1`, `IMG-1`).** The viewing and X-ray imaging cameras carry no control handle in the config objects.
-- **The handle freshness (`CTRL-1`).** The configs are the upstream `develop` branch; some handles may lag the live beamline.
-- **The operator / safety boundary (`GOV-1`).** The EMBL-operated beamline on the DESY-hosted ring splits operator from interlock host; the boundary is pending.
-- **The MX Method (`TECH-1`).** Whether MX enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the existing slug.
-- **The PSS permit signals (`PSS-1`).** Not in the configs; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p14_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p14/notes.md b/docs/deployments/p14/notes.md
new file mode 100644
index 00000000000..a9faade6810
--- /dev/null
+++ b/docs/deployments/p14/notes.md
@@ -0,0 +1,148 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P14 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P14 runs macromolecular crystallography across two endstations, reusing a Method the fleet already carries pending, so the Method below renders unlinked until a technique enters scope (`TECH-1`).
+
+### Macromolecular crystallography
+
+P14 mounts a crystal on a diffractometer (with cryostream cooling), rotates it through an oscillation, and reads frames on an area detector, across two experiment hutches: EH1 on the [EMBLMiniDiff + Eiger detectors](detector.md), EH2 on the [EMBLBSD + Pilatus 2M](detector.md). The EH1 CdTe Eiger variants extend the technique to high-energy data collection, and the X-ray imaging camera supports in-situ centring.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the EMBLMiniDiff (EH1) / EMBLBSD (EH2) reading the Eiger / Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS / P11 / P13), a further consumer (`TECH-1`) |
+
+### A familiar technique across two hutches
+
+P14 is the fleet's eighth macromolecular-crystallography beamline and CORA's second at EMBL Hamburg. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, here run through EMBL's MXCuBE over Exporter + TINE (`SEAM-1`). What is distinctive is the two-endstation layout, one source feeding two hutches each running rotation MX, and the high-energy CdTe detector variants in EH1. It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet); it forces no new device Family. The automated sample changer is a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the oscillation sequences and their exposures, the high-energy CdTe collection, the anomalous-edge scans, the X-ray imaging centring, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P14. Whether the MX Method enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P14, and the trust shape that will gate it. First cut.*
+
+Governance at P14 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P14 is CORA's second EMBL Hamburg beamline, the sibling of [P13](../p13/notes.md#governance) and, like it, a **sub-operator** on the PETRA III Site: the beamline shares the ring and Facility with the DESY beamlines but is operated by EMBL Hamburg, with its own staff and its own MXCuBE control domain. The EMBL Hamburg operator pool and safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), distinct from the DESY pool and shared with P13, until EMBL staff confirm them (`GOV-1`). P14 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P14, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The two-hutch layout adds a governance nuance: EH1 and EH2 are separate experiment hutches under one beamline, so the trust shape would scope per hutch (each hutch its own Zone of resources and its own access state) while sharing the source / optics chain. That per-hutch scoping is carried as part of the enclosure question (`EH-1`).
+
+The safety tier is the other piece that is not yet settled. The MXCuBE configs carry beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The interlock is operated by DESY (the ring host) even where EMBL operates the beamline, so the boundary between the DESY-issued site clearance and the EMBL-operated experiment is itself a question (`GOV-1`). What is already settled is the shape: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+P14 also carries the hazard classes that come with an MX endstation: a cryostream and its liquid-nitrogen supply, and an automated sample changer moving in the experiment hutches. Those land with the instruments that bring them; the sample-changer custody loop, if modelled, would be a Procedure with a Subject thread (`ROBOT-1`), not an Asset CORA drives for safety.
+
+The concrete Zone, Conduit, and Policy instances, and the EMBL operator pool, land when the deployment approaches the point where CORA drives P14, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P14 content lives, the multi-endstation topology it exercises, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P14 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P14 new
+
+P14 is CORA's second EMBL Hamburg beamline (the sibling of P13) and the **first two-endstation MX beamline** CORA models: one source / optics chain feeding two experiment hutches, EH1 (the EMBLMiniDiff + Eiger detectors) and EH2 (the EMBLBSD + Pilatus 2M). At the vocabulary level it is a reuse-and-reinforce deployment; the new thing it exercises is the **multi-endstation topology under one beamline**, plus the high-energy CdTe detector variants and the X-ray imaging camera.
+
+### Two endstations, one source (the new modelling exercise)
+
+P13 established the EMBL sub-operator control-domain; P14 reuses it and adds the multi-hutch shape. The optics chain (KB mirrors, CRL transfocator, beam-defining slits, shared photon energy) feeds two experiment hutches, each with its own diffractometer host. CORA models this as three enclosures (`p14-oh`, `p14-eh1`, `p14-eh2`) under one root Asset, with the energy and CRL services shared and each hutch carrying its own goniometer, detector, and sample optics (`EH-1`). The trust shape would scope per hutch while sharing the source, a governance nuance carried with the enclosure question.
+
+### No new families (the MX spine reuses the i03 precedent)
+
+P14 coins no new Family. Both diffractometers bind the graduated `Goniometer`; the area detectors bind `Camera`; the XRF detector binds `EnergyDispersiveSpectrometer`; the CRL binds `Transfocator`; the slits bind `Slit`; the focusing optic binds `Mirror`; the sample illumination binds the catalog `Backlight` (graduated across the MX / imaging fleet); the optics motions bind `LinearStage`, the energy and detector distance `PseudoAxis`. Nothing in the catalog changes. The MX technique reuses the pending i03 `mx_data_collection` Method (as P13 and the wider MX fleet do).
+
+### The honest limitation: published mockups
+
+The EH2 config (`embl_hh_pe2`) publishes some axes as `MotorMockup`, a simulation placeholder rather than a live device handle. Rather than present these as real, the EH2 diffractometer and table are carried with a caution marker (`MOCK-1`): the instrument is named and bound, but whether each axis is live on the floor or a config stub is a confirm. This is the same "model what the source supports, flag the rest" posture P11 and P13 take, applied to a source that mixes live and simulated entries.
+
+### The control plane
+
+P14 sits on EMBL Hamburg's MXCuBE + Exporter + TINE domain, distinct from the DESY Tango / Sardana floor, with the diffractometer motions Exporter-hosted (`p14md301` / `p14md302` for EH1, `pe2bsd01` for EH2) and the detector / energy / beam services on TINE (`/P14/...`, `/PE2/...`). The handles are read from EMBL's public MXCuBE configs and carried confirm (`CTRL-1`). The rotation-MX acquisition runs as an MXCuBE data-collection routine; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the MX cluster seams at i03 / MANACA / TPS 07A and its sibling P13.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The MXCuBE config exposes the energy service, not the undulator device; the source is carried pending.
+- **The optics breakdown (`OPT-1`, `ENERGY-1`).** The monochromator and KB mirror Assets are not individually labelled; the motions are grouped, the energy carried as a pseudo-axis, the CRL and slits bound but uncharacterized.
+- **The goniometer geometries (`MX-1`).** Both diffractometers are named and bound to `Goniometer`, but their kappa ranges and axis offsets are not in the configs.
+- **The EH2 mockups (`MOCK-1`).** Some EH2 axes are `MotorMockup`; whether each is live or simulated is a confirm.
+- **The EH2 table handle (`TABLE-1`).** The EH2 positioning table carries no control handle in the config object.
+- **The cryostream (`CRYO-1`).** Not a labelled device in the configs; carried as a question, with the liquid nitrogen a Supply.
+- **The sample changer (`ROBOT-1`).** MXCuBE bookkeeping, not a device; a deferred sample-exchange Procedure.
+- **The detector model detail (`DET-1`).** The Eiger variants and Pilatus 2M are named; the ROI modes and geometry are pending.
+- **The imaging / on-axis camera handles (`OAV-1`, `IMG-1`).** The viewing and X-ray imaging cameras carry no control handle in the config objects.
+- **The handle freshness (`CTRL-1`).** The configs are the upstream `develop` branch; some handles may lag the live beamline.
+- **The operator / safety boundary (`GOV-1`).** The EMBL-operated beamline on the DESY-hosted ring splits operator from interlock host; the boundary is pending.
+- **The MX Method (`TECH-1`).** Whether MX enters CORA's catalog is an owner decision; the Practice renders unlinked, pending, reusing the existing slug.
+- **The PSS permit signals (`PSS-1`).** Not in the configs; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p14_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P14 team to confirm before the model can be trusted.*
+
+P14 was reverse-engineered from EMBL Hamburg's own public MXCuBE HardwareObjects configuration ([github.com/mxcube/mxcubecore](https://github.com/mxcube/mxcubecore/tree/develop/mxcubecore/configuration/embl_hh_p14), `configuration/embl_hh_p14` for EH1 and `configuration/embl_hh_pe2` for EH2), not from a live connection. EMBL publishes both endstation configs, so the two diffractometers and their axes are named (each experiment hutch resolves into a real `Goniometer`), but the exact geometry, the optics breakdown, the live-vs-mockup status of the EH2 axes, and the safety / operator boundary are not in them. P14 is CORA's second EMBL Hamburg beamline (the sibling of P13) and the first two-endstation MX beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and two experiment hutches? The split is inferred from the device prefixes and the MX layout. | A `p14-oh` optics hutch feeding `p14-eh1` and `p14-eh2` experiment hutches. | The Enclosure grouping. |
+| EH-1 | Blocks-go-live | The two-endstation layout: do EH1 and EH2 share one source / optics chain (energy + CRL), each with its own diffractometer host? | One shared optics chain feeding two hutches; per-hutch diffractometer and detector. | The multi-endstation topology and per-hutch trust scoping. |
+| SRC-1 | Nice-to-have | The undulator source (the MXCuBE config exposes the energy service, not the undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the KB mirror and slit motions (the P14KB / P14Atto motor groups). | Grouped as the optics-hutch focusing and slit stages; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and KB mirrors, the CRL lens count / material, and the aperture / slit-size tables. | Grouped `LinearStage` motions, a `Mirror` focusing optic, a `Transfocator` CRL, and `Slit` beam-defining boxes; the breakdown pending. | The optics modelling. |
+| ENERGY-1 | Nice-to-have | The energy / monochromator coupling behind the `TINEEnergy` service (`/P14/Energy/P14Energy`), shared by both hutches. | A `PseudoAxis` energy service; the mono motions it drives pending. | The energy modelling. |
+
+### Sample endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MX-1 | Blocks-build | The goniometer geometries of both endstations (the EH1 EMBLMiniDiff and the EH2 EMBLBSD): kappa range, axis offsets, the omega / kappa / centring axis assignment. | Both bound to the graduated `Goniometer` with named axes; the geometries carried as questions. | The MX instrument modelling. |
+| MOCK-1 | Blocks-build | The EH2 axes published as `MotorMockup`: which are live on the floor and which are simulation placeholders in the config? | The EH2 diffractometer and table named and bound, but carried with a caution marker. | Whether the EH2 instrument is modelled live. |
+| TABLE-1 | Nice-to-have | The EH2 experiment-table control handles (the EMBLTableMotor table_hor / table_ver carry no handle in the config object). | A `LinearStage` EH2 table; the handle pending. | The EH2 table modelling. |
+| OAV-1 | Nice-to-have | The on-axis viewing objectives (MicrodiffZoom / ExporterZoom) magnification and the on-axis / sample-changer camera handles, both hutches. | `Objective` zooms plus `Camera` viewing; the camera handles pending. | The OAV modelling. |
+| IMG-1 | Nice-to-have | The EH1 X-ray imaging camera (EMBLXrayImaging) control handle and role. | A `Camera` X-ray imaging device for centring; the handle pending. | The imaging modelling. |
+| CRYO-1 | Nice-to-have | The cryostream (cooler model, sensor / setpoint handles); it is not a labelled device in the MXCuBE configs. | Carried as a question; the liquid nitrogen a Supply observation, not a device. | The temperature-control modelling. |
+| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop), per hutch. | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; MXCuBE bookkeeping, not a device. | The sample-exchange modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The detector models (Eiger 16M silicon, Eiger 16M / 4M CdTe in EH1, Pilatus 2M in EH2, read from the configs), their ROI modes, and the sample-to-detector geometries. | `Camera` area detectors plus derived `PseudoAxis` distances; the geometries pending. | The detector modelling. |
+| DIAG-1 | Nice-to-have | The beam-diagnostic service split (the beam intensity / centring services and the pin-diode flux). | Grouped `FluxMonitor` diagnostics; the per-service split pending. | The diagnostic modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Exporter / TINE control handles per P14 device across the three diffractometer hosts, and whether the upstream MXCuBE `develop` configs match the live beamline. | The handles read from the public MXCuBE configs, carried pending; the floor is MXCuBE over Exporter + TINE. | Binding each Asset's control handle. |
+| SEAM-1 | Blocks-go-live | The EMBL Hamburg control domain: MXCuBE over Exporter (microdiff) + TINE, distinct from the DESY Tango / Sardana floor (shared with P13). | A sub-operator control-domain within the PETRA III Site; EMBL's house style recorded on the Site. | The seam and Site modelling. |
+| GOV-1 | Blocks-go-live | The EMBL Hamburg operator pool, the safety-review structure, and the boundary between the DESY-hosted ring interlock and the EMBL-operated beamline. | Carried pending on the PETRA III Site, shared with P13; the operator / interlock boundary a question. | The governance principals. |
+| PSS-1 | Blocks-go-live | The personnel-safety permit signals and the photon / front-end shutters (absent from the MXCuBE configs), per hutch. | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does rotation MX enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the i03 `mx_data_collection` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p14/questions.md b/docs/deployments/p14/questions.md
deleted file mode 100644
index 6b59241c974..00000000000
--- a/docs/deployments/p14/questions.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# Open questions
-
-*What CORA needs the P14 team to confirm before the model can be trusted.*
-
-P14 was reverse-engineered from EMBL Hamburg's own public MXCuBE HardwareObjects configuration ([github.com/mxcube/mxcubecore](https://github.com/mxcube/mxcubecore/tree/develop/mxcubecore/configuration/embl_hh_p14), `configuration/embl_hh_p14` for EH1 and `configuration/embl_hh_pe2` for EH2), not from a live connection. EMBL publishes both endstation configs, so the two diffractometers and their axes are named (each experiment hutch resolves into a real `Goniometer`), but the exact geometry, the optics breakdown, the live-vs-mockup status of the EH2 axes, and the safety / operator boundary are not in them. P14 is CORA's second EMBL Hamburg beamline (the sibling of P13) and the first two-endstation MX beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: one optics hutch and two experiment hutches? The split is inferred from the device prefixes and the MX layout. | A `p14-oh` optics hutch feeding `p14-eh1` and `p14-eh2` experiment hutches. | The Enclosure grouping. |
-| EH-1 | Blocks-go-live | The two-endstation layout: do EH1 and EH2 share one source / optics chain (energy + CRL), each with its own diffractometer host? | One shared optics chain feeding two hutches; per-hutch diffractometer and detector. | The multi-endstation topology and per-hutch trust scoping. |
-| SRC-1 | Nice-to-have | The undulator source (the MXCuBE config exposes the energy service, not the undulator device). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the KB mirror and slit motions (the P14KB / P14Atto motor groups). | Grouped as the optics-hutch focusing and slit stages; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and KB mirrors, the CRL lens count / material, and the aperture / slit-size tables. | Grouped `LinearStage` motions, a `Mirror` focusing optic, a `Transfocator` CRL, and `Slit` beam-defining boxes; the breakdown pending. | The optics modelling. |
-| ENERGY-1 | Nice-to-have | The energy / monochromator coupling behind the `TINEEnergy` service (`/P14/Energy/P14Energy`), shared by both hutches. | A `PseudoAxis` energy service; the mono motions it drives pending. | The energy modelling. |
-
-## Sample endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MX-1 | Blocks-build | The goniometer geometries of both endstations (the EH1 EMBLMiniDiff and the EH2 EMBLBSD): kappa range, axis offsets, the omega / kappa / centring axis assignment. | Both bound to the graduated `Goniometer` with named axes; the geometries carried as questions. | The MX instrument modelling. |
-| MOCK-1 | Blocks-build | The EH2 axes published as `MotorMockup`: which are live on the floor and which are simulation placeholders in the config? | The EH2 diffractometer and table named and bound, but carried with a caution marker. | Whether the EH2 instrument is modelled live. |
-| TABLE-1 | Nice-to-have | The EH2 experiment-table control handles (the EMBLTableMotor table_hor / table_ver carry no handle in the config object). | A `LinearStage` EH2 table; the handle pending. | The EH2 table modelling. |
-| OAV-1 | Nice-to-have | The on-axis viewing objectives (MicrodiffZoom / ExporterZoom) magnification and the on-axis / sample-changer camera handles, both hutches. | `Objective` zooms plus `Camera` viewing; the camera handles pending. | The OAV modelling. |
-| IMG-1 | Nice-to-have | The EH1 X-ray imaging camera (EMBLXrayImaging) control handle and role. | A `Camera` X-ray imaging device for centring; the handle pending. | The imaging modelling. |
-| CRYO-1 | Nice-to-have | The cryostream (cooler model, sensor / setpoint handles); it is not a labelled device in the MXCuBE configs. | Carried as a question; the liquid nitrogen a Supply observation, not a device. | The temperature-control modelling. |
-| ROBOT-1 | Blocks-go-live | The automated sample changer (load / centre / collect / unmount loop), per hutch. | A deferred sample-exchange Procedure over the spine + a Subject custody thread, not a device family; MXCuBE bookkeeping, not a device. | The sample-exchange modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The detector models (Eiger 16M silicon, Eiger 16M / 4M CdTe in EH1, Pilatus 2M in EH2, read from the configs), their ROI modes, and the sample-to-detector geometries. | `Camera` area detectors plus derived `PseudoAxis` distances; the geometries pending. | The detector modelling. |
-| DIAG-1 | Nice-to-have | The beam-diagnostic service split (the beam intensity / centring services and the pin-diode flux). | Grouped `FluxMonitor` diagnostics; the per-service split pending. | The diagnostic modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Exporter / TINE control handles per P14 device across the three diffractometer hosts, and whether the upstream MXCuBE `develop` configs match the live beamline. | The handles read from the public MXCuBE configs, carried pending; the floor is MXCuBE over Exporter + TINE. | Binding each Asset's control handle. |
-| SEAM-1 | Blocks-go-live | The EMBL Hamburg control domain: MXCuBE over Exporter (microdiff) + TINE, distinct from the DESY Tango / Sardana floor (shared with P13). | A sub-operator control-domain within the PETRA III Site; EMBL's house style recorded on the Site. | The seam and Site modelling. |
-| GOV-1 | Blocks-go-live | The EMBL Hamburg operator pool, the safety-review structure, and the boundary between the DESY-hosted ring interlock and the EMBL-operated beamline. | Carried pending on the PETRA III Site, shared with P13; the operator / interlock boundary a question. | The governance principals. |
-| PSS-1 | Blocks-go-live | The personnel-safety permit signals and the photon / front-end shutters (absent from the MXCuBE configs), per hutch. | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cryostream liquid-nitrogen / beam supplies. | Photon beam, cooling water, vacuum, and liquid nitrogen. | The Supply observations. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does rotation MX enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the i03 `mx_data_collection` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p14/techniques.md b/docs/deployments/p14/techniques.md
deleted file mode 100644
index b60ad9a14db..00000000000
--- a/docs/deployments/p14/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P14 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P14 runs macromolecular crystallography across two endstations, reusing a Method the fleet already carries pending, so the Method below renders unlinked until a technique enters scope (`TECH-1`).
-
-## Macromolecular crystallography
-
-P14 mounts a crystal on a diffractometer (with cryostream cooling), rotates it through an oscillation, and reads frames on an area detector, across two experiment hutches: EH1 on the [EMBLMiniDiff + Eiger detectors](detector.md), EH2 on the [EMBLBSD + Pilatus 2M](detector.md). The EH1 CdTe Eiger variants extend the technique to high-energy data collection, and the X-ray imaging camera supports in-situ centring.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the EMBLMiniDiff (EH1) / EMBLBSD (EH2) reading the Eiger / Pilatus, with cryostream cooling; reuses the i03 Method (also at FMX / AMX / MX3 / MANACA / TPS / P11 / P13), a further consumer (`TECH-1`) |
-
-## A familiar technique across two hutches
-
-P14 is the fleet's eighth macromolecular-crystallography beamline and CORA's second at EMBL Hamburg. It ties into the MX lineage CORA already models: the same goniometer / detector / cryostream anatomy, here run through EMBL's MXCuBE over Exporter + TINE (`SEAM-1`). What is distinctive is the two-endstation layout, one source feeding two hutches each running rotation MX, and the high-energy CdTe detector variants in EH1. It reuses the `mx_data_collection` Method directly (carried pending across the MX fleet); it forces no new device Family. The automated sample changer is a Procedure, not a new device (the i03 / MX3 / MANACA `ROBOT-1` precedent).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the oscillation sequences and their exposures, the high-energy CdTe collection, the anomalous-edge scans, the X-ray imaging centring, the sample-changer custody loop) are not written yet; they join as the deployment approaches the point where CORA drives P14. Whether the MX Method enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p21/governance.md b/docs/deployments/p21/governance.md
deleted file mode 100644
index a9d22c30fa5..00000000000
--- a/docs/deployments/p21/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P21, and the trust shape that will gate it. First cut.*
-
-Governance at P21 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P21 is CORA's thirteenth PETRA III beamline, a Swedish-collaboration beamline; the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). How the Swedish collaboration maps to operator / access governance is part of that question. P21 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P21, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the experiment stations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P21, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p21/model.md b/docs/deployments/p21/model.md
deleted file mode 100644
index d5cfe8c4c99..00000000000
--- a/docs/deployments/p21/model.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P21 content lives, a deliberately thin Swedish-collaboration materials model, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P21 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P21 new
-
-P21 is a thirteenth beamline at an existing Site, a Swedish-collaboration high-energy materials beamline (P21.1 powder / total scattering, P21.2 diffraction / imaging). At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice.
-
-## No new families (a thin, honest model)
-
-P21 coins no new Family. The motor banks bind `LinearStage`; the slits bind `Slit`; the detectors are a pending `Camera` placeholder. Nothing in the catalog changes. The P21 registry slice exposes little beyond grouped motor banks, so the detectors are carried pending rather than invented (`DET-1`), the same model-what-the-source-supports posture as P11 / P65.
-
-## The control plane
-
-P21 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, split across three Tango hosts (`hasep212oh`, `hasep21eh3`, `haspp21lab`). The handles are read from P21's public OnlineXML registry and carried confirm (`CTRL-1`). The high-energy diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
-- **The optics breakdown (`OPT-1`).** The monochromator, mirrors, and slits within the optics bank are not labelled; grouped.
-- **The motor-bank axis roles (`GROUP-1`).** The `oh_u*`, `eh3_u*`, `lab*` banks carry no per-axis role; grouped as stage Assets.
-- **The detectors (`DET-1`).** Not in the registry slice; carried as a pending `Camera` placeholder.
-- **The P21.1 station (`HOST-1`).** The `hasep211eh` host exposed only bookkeeping devices; noted, not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The diffraction Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p21_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p21/notes.md b/docs/deployments/p21/notes.md
new file mode 100644
index 00000000000..7395ca74b08
--- /dev/null
+++ b/docs/deployments/p21/notes.md
@@ -0,0 +1,124 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P21 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P21's diffraction techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
+
+### High-energy diffraction
+
+P21's P21.2 / EH3 branches use a high-energy monochromatic beam for bulk / engineering diffraction, residual stress, and texture studies on the [sample stages](sample.md), reading area detectors.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| High-energy diffraction | `diffraction` | bulk / engineering diffraction on the high-energy branches; reuses the `diffraction` slug P07 / P08 share, a further consumer (`TECH-1`) |
+
+### Total scattering / PDF
+
+P21's P21.1 branch collects total scattering to high momentum transfer for pair-distribution-function analysis.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Total scattering / pair-distribution-function | `total_scattering` | high-Q total scattering on the P21.1 branch; reuses the `total_scattering` slug i15-1 / XPD / P02 share, a further consumer (`TECH-1`) |
+
+### A thin high-energy materials beamline
+
+P21 is a Swedish-collaboration high-energy materials beamline. Its techniques reuse the `diffraction` and `total_scattering` slugs already carried across the fleet, so none forces a new Method. The instrument anatomy reuses existing Families (`LinearStage`, `Slit`); the sparse registry slice means the model is deliberately thin, with the detectors carried pending.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the diffraction / stress-mapping scans, the high-Q PDF collection) are not written yet; they join as the deployment approaches the point where CORA drives P21. Whether the diffraction Methods enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P21, and the trust shape that will gate it. First cut.*
+
+Governance at P21 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P21 is CORA's thirteenth PETRA III beamline, a Swedish-collaboration beamline; the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). How the Swedish collaboration maps to operator / access governance is part of that question. P21 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P21, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the experiment stations) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P21, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P21 content lives, a deliberately thin Swedish-collaboration materials model, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P21 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P21 new
+
+P21 is a thirteenth beamline at an existing Site, a Swedish-collaboration high-energy materials beamline (P21.1 powder / total scattering, P21.2 diffraction / imaging). At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice.
+
+### No new families (a thin, honest model)
+
+P21 coins no new Family. The motor banks bind `LinearStage`; the slits bind `Slit`; the detectors are a pending `Camera` placeholder. Nothing in the catalog changes. The P21 registry slice exposes little beyond grouped motor banks, so the detectors are carried pending rather than invented (`DET-1`), the same model-what-the-source-supports posture as P11 / P65.
+
+### The control plane
+
+P21 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, split across three Tango hosts (`hasep212oh`, `hasep21eh3`, `haspp21lab`). The handles are read from P21's public OnlineXML registry and carried confirm (`CTRL-1`). The high-energy diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
+- **The optics breakdown (`OPT-1`).** The monochromator, mirrors, and slits within the optics bank are not labelled; grouped.
+- **The motor-bank axis roles (`GROUP-1`).** The `oh_u*`, `eh3_u*`, `lab*` banks carry no per-axis role; grouped as stage Assets.
+- **The detectors (`DET-1`).** Not in the registry slice; carried as a pending `Camera` placeholder.
+- **The P21.1 station (`HOST-1`).** The `hasep211eh` host exposed only bookkeeping devices; noted, not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The diffraction Methods (`TECH-1`).** Whether they enter CORA's catalog is an owner decision; the Practices render unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p21_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P21 team to confirm before the model can be trusted.*
+
+P21 was reverse-engineered from P21's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p21](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p21), branch `debian/jessie`) and a verified research brief, not from a live connection. The P21 registry is thin: area-grouped generic motor banks, no detectors exposed. P21 is CORA's thirteenth PETRA III beamline, the Swedish Materials Science beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a P21.2 optics hutch, an EH3 endstation, and a LAB station (plus the P21.1 branch)? | A `p21-oh` / `p21-eh3` / `p21-lab` grouping, from the OnlineXML host names. | The Enclosure grouping. |
+| HOST-1 | Blocks-go-live | The P21.1 station (`hasep211eh`) exposed only bookkeeping devices in this slice. Where is its device tree, and how do P21.1 / P21.2 relate? | Only P21.2 optics / EH3 / LAB modelled; P21.1 noted, not modelled. | The full beamline roster. |
+| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_u*`, `eh3_u*`, `lab*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator, mirrors, and slits within the P21.2 optics bank. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The high-energy diffraction detectors (area detectors, the PerkinElmer / Varex flat-panels typical of high-energy beamlines), absent from this registry slice. | A pending `Camera` placeholder; the detectors not invented. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P21 device, the three-host split, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool, the Swedish collaboration's role, and the safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Do high-energy diffraction and total scattering enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `diffraction` / `total_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p21/questions.md b/docs/deployments/p21/questions.md
deleted file mode 100644
index bc9e1fbc6a8..00000000000
--- a/docs/deployments/p21/questions.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Open questions
-
-*What CORA needs the P21 team to confirm before the model can be trusted.*
-
-P21 was reverse-engineered from P21's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p21](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p21), branch `debian/jessie`) and a verified research brief, not from a live connection. The P21 registry is thin: area-grouped generic motor banks, no detectors exposed. P21 is CORA's thirteenth PETRA III beamline, the Swedish Materials Science beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a P21.2 optics hutch, an EH3 endstation, and a LAB station (plus the P21.1 branch)? | A `p21-oh` / `p21-eh3` / `p21-lab` grouping, from the OnlineXML host names. | The Enclosure grouping. |
-| HOST-1 | Blocks-go-live | The P21.1 station (`hasep211eh`) exposed only bookkeeping devices in this slice. Where is its device tree, and how do P21.1 / P21.2 relate? | Only P21.2 optics / EH3 / LAB modelled; P21.1 noted, not modelled. | The full beamline roster. |
-| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_u*`, `eh3_u*`, `lab*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator, mirrors, and slits within the P21.2 optics bank. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The high-energy diffraction detectors (area detectors, the PerkinElmer / Varex flat-panels typical of high-energy beamlines), absent from this registry slice. | A pending `Camera` placeholder; the detectors not invented. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P21 device, the three-host split, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool, the Swedish collaboration's role, and the safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Do high-energy diffraction and total scattering enter CORA's catalog as Capabilities / Methods? | Deferred: carried as pending Practices reusing the `diffraction` / `total_scattering` slugs; none coined. | The technique Capabilities. |
diff --git a/docs/deployments/p21/techniques.md b/docs/deployments/p21/techniques.md
deleted file mode 100644
index 55653aceecd..00000000000
--- a/docs/deployments/p21/techniques.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Techniques
-
-*What the modelled part of P21 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P21's diffraction techniques earn no catalog Method today, so the Methods below render unlinked and are carried pending until a technique enters scope (`TECH-1`).
-
-## High-energy diffraction
-
-P21's P21.2 / EH3 branches use a high-energy monochromatic beam for bulk / engineering diffraction, residual stress, and texture studies on the [sample stages](sample.md), reading area detectors.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| High-energy diffraction | `diffraction` | bulk / engineering diffraction on the high-energy branches; reuses the `diffraction` slug P07 / P08 share, a further consumer (`TECH-1`) |
-
-## Total scattering / PDF
-
-P21's P21.1 branch collects total scattering to high momentum transfer for pair-distribution-function analysis.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Total scattering / pair-distribution-function | `total_scattering` | high-Q total scattering on the P21.1 branch; reuses the `total_scattering` slug i15-1 / XPD / P02 share, a further consumer (`TECH-1`) |
-
-## A thin high-energy materials beamline
-
-P21 is a Swedish-collaboration high-energy materials beamline. Its techniques reuse the `diffraction` and `total_scattering` slugs already carried across the fleet, so none forces a new Method. The instrument anatomy reuses existing Families (`LinearStage`, `Slit`); the sparse registry slice means the model is deliberately thin, with the detectors carried pending.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the diffraction / stress-mapping scans, the high-Q PDF collection) are not written yet; they join as the deployment approaches the point where CORA drives P21. Whether the diffraction Methods enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p22/governance.md b/docs/deployments/p22/governance.md
deleted file mode 100644
index 05bc1088022..00000000000
--- a/docs/deployments/p22/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at P22, and the trust shape that will gate it. First cut.*
-
-Governance at P22 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P22 is CORA's fourteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P22 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P22, following the [2-BM governance](../2-bm/governance.md) shape.
-
-A P22-specific governance wrinkle: P22 **shares its optics chain with P09** (`SHARED-1`). The undulator, monochromator, mirrors, and phase retarder are P09 devices, so the optics-enclosure access state and the source-conditioning commands couple the two beamlines. How CORA's Federation / Trust model carries that coupling (a shared Zone, or a coordination Conduit between the two beamlines) is part of the open question; for this first cut the shared optics are homed in the P22 optics enclosure with the relationship flagged.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The shared optics mean the optics-enclosure permit is coupled with P09.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P22, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p22/model.md b/docs/deployments/p22/model.md
deleted file mode 100644
index acd3e11f5a2..00000000000
--- a/docs/deployments/p22/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P22 content lives, the shared-optics relationship with P09, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P22 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P22 new
-
-P22 is a fourteenth beamline at an existing Site, the facility's hard X-ray photoemission (HAXPES) beamline. Its distinguishing structural fact is that it **shares its optics chain with P09**: the undulator, DCM, mirrors, phase retarder, and absorber are P09 devices, and P22 is the HAXPES branch off that chain. At the modelling level it is a reuse-and-reinforce deployment, plus a shared-optics relationship the Federation / Trust model would carry.
-
-## No new families
-
-P22 coins no new Family. The shared optics bind `Monochromator` / `Mirror` / `Filter` and the catalog `PhaseRetarder` (P22 is the third consumer, the one that completed the 4-ID/P09/P22 rule-of-three); the HAXPS sample stage binds `Manipulator` (the NSLS-II ESM Family); the electron analyzer binds the catalog `ElectronAnalyzer` (also ESM, carried pending here). Nothing in the catalog changes.
-
-## The control plane
-
-P22 sits on the PETRA III Tango device floor with Sardana as the scan layer. Its defining control fact is the shared P09 optics (the `p09/` addresses), so P22's source-conditioning state is coupled to P09 (`SHARED-1`). The handles are read from P22's public OnlineXML registry and carried confirm (`CTRL-1`); the electron analyzer is a self-contained instrument not in the registry slice (`DET-1`). The HAXPES acquisition runs as a Sardana macro coordinated with the analyzer; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The shared-optics relationship (`SHARED-1`).** P22 and P09 share the undulator / DCM / mirrors / phase retarder; how that maps to CORA's Federation / Trust coordination (two beamlines, one optics chain) is pending.
-- **The undulator parameters (`SRC-1`).** The gap is read; the period is not exposed.
-- **The optics detail (`OPT-1`).** The DCM crystal cut, the mirror coatings, and the phase-retarder geometry are carried confirm-pending.
-- **The manipulator axis roles (`GROUP-1`).** The `p22/motor` bank carries no per-axis role; grouped as one `Manipulator`.
-- **The electron analyzer (`DET-1`).** The defining HAXPES detector is named (bound to `ElectronAnalyzer`) but its model / control interface is not in the registry; carried pending.
-- **The dummy stubs (`STUB-1`).** The `haxps_dmy*` placeholder devices are noted, not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The HAXPES Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p22_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p22/notes.md b/docs/deployments/p22/notes.md
new file mode 100644
index 00000000000..4438da9812f
--- /dev/null
+++ b/docs/deployments/p22/notes.md
@@ -0,0 +1,119 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P22 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P22's HAXPES technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Hard X-ray photoelectron spectroscopy
+
+P22 illuminates the sample with a monochromatic hard X-ray beam (the shared P09 optics, with the phase retarder setting polarization) and measures the kinetic-energy spectrum of the emitted photoelectrons on the [electron analyzer](detector.md), probing bulk / buried electronic structure (the hard X-ray depth advantage over soft X-ray photoemission).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Hard X-ray photoelectron spectroscopy (HAXPES) | `angle_resolved_photoemission` | photoemission on the HAXPS electron analyzer over the shared P09 optics; reuses the `angle_resolved_photoemission` slug P04 shares, a further consumer (`TECH-1`) |
+
+### A photoemission beamline on familiar vocabulary
+
+P22 is the fleet's hard X-ray photoemission beamline. Its technique reuses the `angle_resolved_photoemission` slug already carried pending (P04, NSLS-II ESM), so it forces no new Method. The instrument anatomy reuses existing Families: the shared optics bind `Monochromator` / `Mirror` / the catalog `PhaseRetarder`, the sample stage `Manipulator`, and the electron analyzer the catalog `ElectronAnalyzer` (graduated at NSLS-II ESM, carried pending here since not exposed in the registry). The HAXPES depth sensitivity is a physics consequence of the hard X-ray energy, not a new device.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the analyzer energy sweeps, the depth-profiling / standing-wave HAXPES, the polarization-dependent measurements) are not written yet; they join as the deployment approaches the point where CORA drives P22. Whether `angle_resolved_photoemission` enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P22, and the trust shape that will gate it. First cut.*
+
+Governance at P22 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P22 is CORA's fourteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P22 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P22, following the [2-BM governance](../2-bm/governance.md) shape.
+
+A P22-specific governance wrinkle: P22 **shares its optics chain with P09** (`SHARED-1`). The undulator, monochromator, mirrors, and phase retarder are P09 devices, so the optics-enclosure access state and the source-conditioning commands couple the two beamlines. How CORA's Federation / Trust model carries that coupling (a shared Zone, or a coordination Conduit between the two beamlines) is part of the open question; for this first cut the shared optics are homed in the P22 optics enclosure with the relationship flagged.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). The shared optics mean the optics-enclosure permit is coupled with P09.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P22, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P22 content lives, the shared-optics relationship with P09, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P22 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P22 new
+
+P22 is a fourteenth beamline at an existing Site, the facility's hard X-ray photoemission (HAXPES) beamline. Its distinguishing structural fact is that it **shares its optics chain with P09**: the undulator, DCM, mirrors, phase retarder, and absorber are P09 devices, and P22 is the HAXPES branch off that chain. At the modelling level it is a reuse-and-reinforce deployment, plus a shared-optics relationship the Federation / Trust model would carry.
+
+### No new families
+
+P22 coins no new Family. The shared optics bind `Monochromator` / `Mirror` / `Filter` and the catalog `PhaseRetarder` (P22 is the third consumer, the one that completed the 4-ID/P09/P22 rule-of-three); the HAXPS sample stage binds `Manipulator` (the NSLS-II ESM Family); the electron analyzer binds the catalog `ElectronAnalyzer` (also ESM, carried pending here). Nothing in the catalog changes.
+
+### The control plane
+
+P22 sits on the PETRA III Tango device floor with Sardana as the scan layer. Its defining control fact is the shared P09 optics (the `p09/` addresses), so P22's source-conditioning state is coupled to P09 (`SHARED-1`). The handles are read from P22's public OnlineXML registry and carried confirm (`CTRL-1`); the electron analyzer is a self-contained instrument not in the registry slice (`DET-1`). The HAXPES acquisition runs as a Sardana macro coordinated with the analyzer; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The shared-optics relationship (`SHARED-1`).** P22 and P09 share the undulator / DCM / mirrors / phase retarder; how that maps to CORA's Federation / Trust coordination (two beamlines, one optics chain) is pending.
+- **The undulator parameters (`SRC-1`).** The gap is read; the period is not exposed.
+- **The optics detail (`OPT-1`).** The DCM crystal cut, the mirror coatings, and the phase-retarder geometry are carried confirm-pending.
+- **The manipulator axis roles (`GROUP-1`).** The `p22/motor` bank carries no per-axis role; grouped as one `Manipulator`.
+- **The electron analyzer (`DET-1`).** The defining HAXPES detector is named (bound to `ElectronAnalyzer`) but its model / control interface is not in the registry; carried pending.
+- **The dummy stubs (`STUB-1`).** The `haxps_dmy*` placeholder devices are noted, not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The HAXPES Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p22_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P22 team to confirm before the model can be trusted.*
+
+P22 was reverse-engineered from P22's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p22](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p22), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry shows P22 sharing the P09 optics chain, with the HAXPS endstation as a grouped bank and the electron analyzer not exposed. P22 is CORA's fourteenth PETRA III beamline, the HAXPES beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: shared P09 optics feeding the HAXPS experiment endstation? | A `p22-optics` (shared with P09) and a `p22-haxps` endstation. | The Enclosure grouping. |
+| SHARED-1 | Blocks-go-live | The P22 / P09 shared optics: the undulator, DCM, mirrors, and phase retarder are P09 devices. How are the two beamlines coordinated (shared straight, switched source, simultaneous operation)? | The optics are shared, homed in `p22-optics` with the relationship flagged. | The shared-optics coordination model. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | A shared P09 undulator; gap read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the HAXPS manipulator bank (the polar / azimuthal / translation axes). | Grouped as one `Manipulator` Asset; per-axis roles pending. | The manipulator Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The shared DCM crystal cut, the mirror coatings, and the phase-retarder geometry. | A DCM `Monochromator`, two `Mirror`s, and a catalog `PhaseRetarder`; physical detail pending. | The optics modelling. |
+
+### The detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The HAXPES electron analyzer model (a hemispherical analyzer, e.g. SPECS / Scienta), its lens modes, and its control interface (absent from this registry slice). | An `ElectronAnalyzer` Asset (the NSLS-II ESM Family); model and control pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P22 device, the shared P09 optics handles, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P09. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics permit coupling with P09, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (HAXPES needs UHV at the analyzer) and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does hard X-ray photoelectron spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `angle_resolved_photoemission` slug P04 shares; none coined. | The technique Capability. |
diff --git a/docs/deployments/p22/questions.md b/docs/deployments/p22/questions.md
deleted file mode 100644
index 6c7f9747aee..00000000000
--- a/docs/deployments/p22/questions.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Open questions
-
-*What CORA needs the P22 team to confirm before the model can be trusted.*
-
-P22 was reverse-engineered from P22's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p22](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p22), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry shows P22 sharing the P09 optics chain, with the HAXPS endstation as a grouped bank and the electron analyzer not exposed. P22 is CORA's fourteenth PETRA III beamline, the HAXPES beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: shared P09 optics feeding the HAXPS experiment endstation? | A `p22-optics` (shared with P09) and a `p22-haxps` endstation. | The Enclosure grouping. |
-| SHARED-1 | Blocks-go-live | The P22 / P09 shared optics: the undulator, DCM, mirrors, and phase retarder are P09 devices. How are the two beamlines coordinated (shared straight, switched source, simultaneous operation)? | The optics are shared, homed in `p22-optics` with the relationship flagged. | The shared-optics coordination model. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | A shared P09 undulator; gap read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the HAXPS manipulator bank (the polar / azimuthal / translation axes). | Grouped as one `Manipulator` Asset; per-axis roles pending. | The manipulator Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The shared DCM crystal cut, the mirror coatings, and the phase-retarder geometry. | A DCM `Monochromator`, two `Mirror`s, and a catalog `PhaseRetarder`; physical detail pending. | The optics modelling. |
-
-## The detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The HAXPES electron analyzer model (a hemispherical analyzer, e.g. SPECS / Scienta), its lens modes, and its control interface (absent from this registry slice). | An `ElectronAnalyzer` Asset (the NSLS-II ESM Family); model and control pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P22 device, the shared P09 optics handles, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P09. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics permit coupling with P09, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (HAXPES needs UHV at the analyzer) and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does hard X-ray photoelectron spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `angle_resolved_photoemission` slug P04 shares; none coined. | The technique Capability. |
diff --git a/docs/deployments/p22/techniques.md b/docs/deployments/p22/techniques.md
deleted file mode 100644
index 1ac565ffcc4..00000000000
--- a/docs/deployments/p22/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P22 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P22's HAXPES technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Hard X-ray photoelectron spectroscopy
-
-P22 illuminates the sample with a monochromatic hard X-ray beam (the shared P09 optics, with the phase retarder setting polarization) and measures the kinetic-energy spectrum of the emitted photoelectrons on the [electron analyzer](detector.md), probing bulk / buried electronic structure (the hard X-ray depth advantage over soft X-ray photoemission).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Hard X-ray photoelectron spectroscopy (HAXPES) | `angle_resolved_photoemission` | photoemission on the HAXPS electron analyzer over the shared P09 optics; reuses the `angle_resolved_photoemission` slug P04 shares, a further consumer (`TECH-1`) |
-
-## A photoemission beamline on familiar vocabulary
-
-P22 is the fleet's hard X-ray photoemission beamline. Its technique reuses the `angle_resolved_photoemission` slug already carried pending (P04, NSLS-II ESM), so it forces no new Method. The instrument anatomy reuses existing Families: the shared optics bind `Monochromator` / `Mirror` / the catalog `PhaseRetarder`, the sample stage `Manipulator`, and the electron analyzer the catalog `ElectronAnalyzer` (graduated at NSLS-II ESM, carried pending here since not exposed in the registry). The HAXPES depth sensitivity is a physics consequence of the hard X-ray energy, not a new device.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the analyzer energy sweeps, the depth-profiling / standing-wave HAXPES, the polarization-dependent measurements) are not written yet; they join as the deployment approaches the point where CORA drives P22. Whether `angle_resolved_photoemission` enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p23/governance.md b/docs/deployments/p23/governance.md
deleted file mode 100644
index 098ac0b3000..00000000000
--- a/docs/deployments/p23/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P23, and the trust shape that will gate it. First cut.*
-
-Governance at P23 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P23 is CORA's fifteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P23 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P23, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P23's in-situ / operando sample environments (electrochemical cells, growth chambers) may carry their own hazards; those land with the instruments that bring them when the deployment firms up.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P23, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p23/model.md b/docs/deployments/p23/model.md
deleted file mode 100644
index acc613fbeea..00000000000
--- a/docs/deployments/p23/model.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P23 content lives, a deliberately thin in-situ / operando diffraction model, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P23 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P23 new
-
-P23 is a fifteenth beamline at an existing Site, the facility's in-situ / operando diffraction beamline. At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice (one generic motor bank).
-
-## No new families (a thin, honest model)
-
-P23 coins no new Family. The motor bank binds `LinearStage`; the detectors are a pending `Camera` placeholder. Nothing in the catalog changes. The P23 registry slice exposes little beyond the grouped motor bank, so the optics / diffractometer breakdown and the detectors are carried grouped / pending rather than invented (`OPT-1`, `DIFF-1`, `DET-1`), the same model-what-the-source-supports posture as P11 / P21 / P65.
-
-## The control plane
-
-P23 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. The handles are read from P23's public OnlineXML registry and carried confirm (`CTRL-1`). The in-situ diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
-- **The optics / diffractometer breakdown (`OPT-1`, `DIFF-1`).** The mono, mirrors, and diffractometer within the bank are not labelled; grouped.
-- **The motor-bank axis roles (`GROUP-1`).** The `eh_mot*` bank carries no per-axis role; grouped as one stage.
-- **The dev stub (`STUB-1`).** The single `hasep23dev` axis is a dev / commissioning device, noted.
-- **The detectors (`DET-1`).** Not in the registry slice; carried as a pending `Camera` placeholder.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p23_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p23/notes.md b/docs/deployments/p23/notes.md
new file mode 100644
index 00000000000..8a88487d3da
--- /dev/null
+++ b/docs/deployments/p23/notes.md
@@ -0,0 +1,117 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P23 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P23's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### In-situ X-ray diffraction
+
+P23 measures diffraction (and imaging) of samples under in-situ / operando conditions, electrochemistry, thin-film growth, and controlled sample environments, on the [experiment diffractometer](sample.md).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| In-situ / operando X-ray diffraction | `diffraction` | diffraction of samples under in-situ conditions; reuses the `diffraction` slug P07 / P08 / P21 share, a further consumer (`TECH-1`) |
+
+### A thin in-situ diffraction beamline
+
+P23 is a thin in-situ diffraction beamline. Its technique reuses the `diffraction` slug already carried across the fleet, so it forces no new Method. The instrument anatomy reuses existing Families (`LinearStage`); the sparse registry slice means the model is deliberately thin, with the optics / diffractometer grouped and the detectors carried pending. The in-situ sample environments (the operando cells), if present, would be sample-environment Assets bound when the registry exposes them.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the diffraction scans, the in-situ / operando time series, the environment-coupled measurements) are not written yet; they join as the deployment approaches the point where CORA drives P23. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P23, and the trust shape that will gate it. First cut.*
+
+Governance at P23 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P23 is CORA's fifteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P23 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P23, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P23's in-situ / operando sample environments (electrochemical cells, growth chambers) may carry their own hazards; those land with the instruments that bring them when the deployment firms up.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P23, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P23 content lives, a deliberately thin in-situ / operando diffraction model, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P23 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P23 new
+
+P23 is a fifteenth beamline at an existing Site, the facility's in-situ / operando diffraction beamline. At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice (one generic motor bank).
+
+### No new families (a thin, honest model)
+
+P23 coins no new Family. The motor bank binds `LinearStage`; the detectors are a pending `Camera` placeholder. Nothing in the catalog changes. The P23 registry slice exposes little beyond the grouped motor bank, so the optics / diffractometer breakdown and the detectors are carried grouped / pending rather than invented (`OPT-1`, `DIFF-1`, `DET-1`), the same model-what-the-source-supports posture as P11 / P21 / P65.
+
+### The control plane
+
+P23 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. The handles are read from P23's public OnlineXML registry and carried confirm (`CTRL-1`). The in-situ diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
+- **The optics / diffractometer breakdown (`OPT-1`, `DIFF-1`).** The mono, mirrors, and diffractometer within the bank are not labelled; grouped.
+- **The motor-bank axis roles (`GROUP-1`).** The `eh_mot*` bank carries no per-axis role; grouped as one stage.
+- **The dev stub (`STUB-1`).** The single `hasep23dev` axis is a dev / commissioning device, noted.
+- **The detectors (`DET-1`).** Not in the registry slice; carried as a pending `Camera` placeholder.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p23_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P23 team to confirm before the model can be trusted.*
+
+P23 was reverse-engineered from P23's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p23](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p23), branch `debian/jessie`) and a verified research brief, not from a live connection. The P23 registry is thin: one area-grouped generic motor bank, no detectors exposed. P23 is CORA's fifteenth PETRA III beamline, the in-situ diffraction beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch (the registry exposes one host)? Is there a separate optics hutch? | A `p23-eh` experiment hutch, from the OnlineXML `hasep23oh` host. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the `eh_mot*` motor bank. | Grouped as one `LinearStage` stage carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+| STUB-1 | Nice-to-have | The single `hasep23dev` axis: a dev / commissioning device, or a real channel? | Noted as a dev / commissioning stage. | The dev-stub status. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and mirrors within the bank. | Grouped into the experiment stage; the breakdown pending. | The optics modelling. |
+| DIFF-1 | Blocks-build | The diffractometer geometry within the bank. | Grouped into the experiment stage; the diffractometer pending. | The diffractometer modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The in-situ diffraction detectors (area detectors, any fluorescence detectors), absent from this registry slice. | A pending `Camera` placeholder; the detectors not invented. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P23 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the in-situ sample-environment supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does in-situ X-ray diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p23/questions.md b/docs/deployments/p23/questions.md
deleted file mode 100644
index 0d48d90e966..00000000000
--- a/docs/deployments/p23/questions.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Open questions
-
-*What CORA needs the P23 team to confirm before the model can be trusted.*
-
-P23 was reverse-engineered from P23's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p23](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p23), branch `debian/jessie`) and a verified research brief, not from a live connection. The P23 registry is thin: one area-grouped generic motor bank, no detectors exposed. P23 is CORA's fifteenth PETRA III beamline, the in-situ diffraction beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch (the registry exposes one host)? Is there a separate optics hutch? | A `p23-eh` experiment hutch, from the OnlineXML `hasep23oh` host. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the `eh_mot*` motor bank. | Grouped as one `LinearStage` stage carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-| STUB-1 | Nice-to-have | The single `hasep23dev` axis: a dev / commissioning device, or a real channel? | Noted as a dev / commissioning stage. | The dev-stub status. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and mirrors within the bank. | Grouped into the experiment stage; the breakdown pending. | The optics modelling. |
-| DIFF-1 | Blocks-build | The diffractometer geometry within the bank. | Grouped into the experiment stage; the diffractometer pending. | The diffractometer modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The in-situ diffraction detectors (area detectors, any fluorescence detectors), absent from this registry slice. | A pending `Camera` placeholder; the detectors not invented. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P23 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent, the cooling / beam supplies, and the in-situ sample-environment supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does in-situ X-ray diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p23/techniques.md b/docs/deployments/p23/techniques.md
deleted file mode 100644
index 1e44c7b3e78..00000000000
--- a/docs/deployments/p23/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P23 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P23's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## In-situ X-ray diffraction
-
-P23 measures diffraction (and imaging) of samples under in-situ / operando conditions, electrochemistry, thin-film growth, and controlled sample environments, on the [experiment diffractometer](sample.md).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| In-situ / operando X-ray diffraction | `diffraction` | diffraction of samples under in-situ conditions; reuses the `diffraction` slug P07 / P08 / P21 share, a further consumer (`TECH-1`) |
-
-## A thin in-situ diffraction beamline
-
-P23 is a thin in-situ diffraction beamline. Its technique reuses the `diffraction` slug already carried across the fleet, so it forces no new Method. The instrument anatomy reuses existing Families (`LinearStage`); the sparse registry slice means the model is deliberately thin, with the optics / diffractometer grouped and the detectors carried pending. The in-situ sample environments (the operando cells), if present, would be sample-environment Assets bound when the registry exposes them.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the diffraction scans, the in-situ / operando time series, the environment-coupled measurements) are not written yet; they join as the deployment approaches the point where CORA drives P23. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p24/governance.md b/docs/deployments/p24/governance.md
deleted file mode 100644
index e72c72e9132..00000000000
--- a/docs/deployments/p24/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P24, and the trust shape that will gate it. First cut.*
-
-Governance at P24 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P24 is CORA's sixteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P24 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P24, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the two experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P24, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p24/model.md b/docs/deployments/p24/model.md
deleted file mode 100644
index 5d3b12c6e32..00000000000
--- a/docs/deployments/p24/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P24 content lives, its single-crystal chemical crystallography distinct from the MX beamlines, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P24 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P24 new
-
-P24 is a sixteenth beamline at an existing Site, the facility's single-crystal / small-molecule chemical crystallography beamline. It is distinct from the macromolecular-crystallography beamlines (P11, i03, FMX / AMX, MANACA, TPS), which bind `Goniometer` and `mx_data_collection`: P24 does small-molecule chemical crystallography, modelled as `diffraction` for now. At the modelling level it is a reuse-and-reinforce deployment.
-
-## No new families
-
-P24 coins no new Family. The optics / sample banks bind `LinearStage`; the slits `Slit`; the coupled axes `PseudoAxis`; the MCA `EnergyDispersiveSpectrometer`; the area detector `Camera` (carried pending). Nothing in the catalog changes. Whether the diffractometer, once labelled, warrants a `Goniometer` / `Diffractometer` binding is carried `DIFF-1`.
-
-## The control plane
-
-P24 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. The handles are read from P24's public OnlineXML registry and carried confirm (`CTRL-1`); the area detector is not exposed in this slice (`DET-1`). The chemical-crystallography acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
-- **The optics breakdown (`OPT-1`).** The monochromator and mirrors within the optics bank are not labelled; grouped.
-- **The diffractometer geometry (`DIFF-1`).** Not labelled in the registry; grouped into the sample stage, the goniometer-vs-diffractometer binding pending.
-- **The motor-bank axis roles (`GROUP-1`).** The `oh_mot*` / `mot*` banks carry no per-axis role; grouped as stage Assets.
-- **The area detector (`DET-1`).** The single-crystal area detector is not in the registry slice; carried as a pending `Camera` placeholder.
-- **The dummy stubs (`STUB-1`).** The `eh2_dmy*` placeholder devices are noted, not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **The chemical-crystallography Method (`TECH-1`).** Whether a dedicated Method (vs reusing `diffraction`) enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p24_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p24/notes.md b/docs/deployments/p24/notes.md
new file mode 100644
index 00000000000..e5dda38d187
--- /dev/null
+++ b/docs/deployments/p24/notes.md
@@ -0,0 +1,123 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P24 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P24's chemical crystallography earns no dedicated catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Chemical crystallography
+
+P24 mounts a single crystal on the [diffractometer](sample.md) and collects single-crystal diffraction on the area detector to solve small-molecule / chemical structures (including at non-ambient conditions).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Single-crystal / chemical crystallography | `diffraction` | single-crystal diffraction on the EH2 diffractometer + area detector; reuses the `diffraction` slug (no dedicated chemical-crystallography Method exists), a further consumer (`TECH-1`) |
+
+### A chemical crystallography beamline on familiar vocabulary
+
+P24 is PETRA III's chemical (small-molecule) crystallography beamline, the fleet's second after Diamond [I19](../i19/index.md). It is distinct from the macromolecular-crystallography beamlines (P11, i03, FMX / AMX, MANACA, TPS): those bind the `Goniometer` Family and the `mx_data_collection` Method, while P24 does small-molecule chemical crystallography, which CORA models as `diffraction` for now (no dedicated chemical-crystallography Method exists, and the registry does not expose a labelled goniometer). The instrument anatomy reuses existing Families (`LinearStage`, `Slit`, `EnergyDispersiveSpectrometer`); the area detector is carried pending.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the single-crystal data-collection strategies, the multi-temperature / variable-condition collection) are not written yet; they join as the deployment approaches the point where CORA drives P24. Whether a dedicated chemical-crystallography Method (vs reusing `diffraction`) enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P24, and the trust shape that will gate it. First cut.*
+
+Governance at P24 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P24 is CORA's sixteenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P24 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P24, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals (across the optics and the two experiment hutches) and the interlock structure are carried pending and are not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P24, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P24 content lives, its single-crystal chemical crystallography distinct from the MX beamlines, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P24 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P24 new
+
+P24 is a sixteenth beamline at an existing Site, the facility's single-crystal / small-molecule chemical crystallography beamline. It is distinct from the macromolecular-crystallography beamlines (P11, i03, FMX / AMX, MANACA, TPS), which bind `Goniometer` and `mx_data_collection`: P24 does small-molecule chemical crystallography, modelled as `diffraction` for now. At the modelling level it is a reuse-and-reinforce deployment.
+
+### No new families
+
+P24 coins no new Family. The optics / sample banks bind `LinearStage`; the slits `Slit`; the coupled axes `PseudoAxis`; the MCA `EnergyDispersiveSpectrometer`; the area detector `Camera` (carried pending). Nothing in the catalog changes. Whether the diffractometer, once labelled, warrants a `Goniometer` / `Diffractometer` binding is carried `DIFF-1`.
+
+### The control plane
+
+P24 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. The handles are read from P24's public OnlineXML registry and carried confirm (`CTRL-1`); the area detector is not exposed in this slice (`DET-1`). The chemical-crystallography acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** The OnlineXML slice exposes no undulator device; the source is carried pending.
+- **The optics breakdown (`OPT-1`).** The monochromator and mirrors within the optics bank are not labelled; grouped.
+- **The diffractometer geometry (`DIFF-1`).** Not labelled in the registry; grouped into the sample stage, the goniometer-vs-diffractometer binding pending.
+- **The motor-bank axis roles (`GROUP-1`).** The `oh_mot*` / `mot*` banks carry no per-axis role; grouped as stage Assets.
+- **The area detector (`DET-1`).** The single-crystal area detector is not in the registry slice; carried as a pending `Camera` placeholder.
+- **The dummy stubs (`STUB-1`).** The `eh2_dmy*` placeholder devices are noted, not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **The chemical-crystallography Method (`TECH-1`).** Whether a dedicated Method (vs reusing `diffraction`) enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p24_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P24 team to confirm before the model can be trusted.*
+
+P24 was reverse-engineered from P24's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p24](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p24), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry exposes generic motor banks and the MCAs, but not the diffractometer geometry or the area detector. P24 is CORA's sixteenth PETRA III beamline, the chemical crystallography beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding an EH2 main and an EH1 experiment hutch? | A `p24-oh` optics hutch and `p24-eh2` / `p24-eh1` endstations. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_mot*`, `mot*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+| STUB-1 | Nice-to-have | The `eh2_dmy*` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The stub status. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and mirrors within the optics bank. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DIFF-1 | Blocks-build | The chemical-crystallography diffractometer geometry (and whether it warrants a `Goniometer` / `Diffractometer` binding once labelled). | A grouped `LinearStage` sample stage; the diffractometer binding pending. | The diffractometer modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The single-crystal area detector (a Pilatus / Eiger-class photon-counting detector), absent from this registry slice. | A pending `Camera` placeholder plus the `EnergyDispersiveSpectrometer` MCAs. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P24 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does chemical crystallography enter CORA's catalog as a dedicated Capability / Method (vs reusing `diffraction`)? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p24/questions.md b/docs/deployments/p24/questions.md
deleted file mode 100644
index 46e30d953bc..00000000000
--- a/docs/deployments/p24/questions.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Open questions
-
-*What CORA needs the P24 team to confirm before the model can be trusted.*
-
-P24 was reverse-engineered from P24's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p24](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p24), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry exposes generic motor banks and the MCAs, but not the diffractometer geometry or the area detector. P24 is CORA's sixteenth PETRA III beamline, the chemical crystallography beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding an EH2 main and an EH1 experiment hutch? | A `p24-oh` optics hutch and `p24-eh2` / `p24-eh1` endstations. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator source (absent from this slice). | An undulator beamline; the source carried pending. | The source Asset. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the motor banks (`oh_mot*`, `mot*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-| STUB-1 | Nice-to-have | The `eh2_dmy*` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The stub status. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The optics breakdown: the monochromator and mirrors within the optics bank. | Grouped `LinearStage` optics stages; the breakdown pending. | The optics modelling. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DIFF-1 | Blocks-build | The chemical-crystallography diffractometer geometry (and whether it warrants a `Goniometer` / `Diffractometer` binding once labelled). | A grouped `LinearStage` sample stage; the diffractometer binding pending. | The diffractometer modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The single-crystal area detector (a Pilatus / Eiger-class photon-counting detector), absent from this registry slice. | A pending `Camera` placeholder plus the `EnergyDispersiveSpectrometer` MCAs. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P24 device, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does chemical crystallography enter CORA's catalog as a dedicated Capability / Method (vs reusing `diffraction`)? | Deferred: carried as a pending Practice reusing the `diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p24/techniques.md b/docs/deployments/p24/techniques.md
deleted file mode 100644
index 8b35f7af27c..00000000000
--- a/docs/deployments/p24/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P24 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P24's chemical crystallography earns no dedicated catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Chemical crystallography
-
-P24 mounts a single crystal on the [diffractometer](sample.md) and collects single-crystal diffraction on the area detector to solve small-molecule / chemical structures (including at non-ambient conditions).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Single-crystal / chemical crystallography | `diffraction` | single-crystal diffraction on the EH2 diffractometer + area detector; reuses the `diffraction` slug (no dedicated chemical-crystallography Method exists), a further consumer (`TECH-1`) |
-
-## A chemical crystallography beamline on familiar vocabulary
-
-P24 is PETRA III's chemical (small-molecule) crystallography beamline, the fleet's second after Diamond [I19](../i19/index.md). It is distinct from the macromolecular-crystallography beamlines (P11, i03, FMX / AMX, MANACA, TPS): those bind the `Goniometer` Family and the `mx_data_collection` Method, while P24 does small-molecule chemical crystallography, which CORA models as `diffraction` for now (no dedicated chemical-crystallography Method exists, and the registry does not expose a labelled goniometer). The instrument anatomy reuses existing Families (`LinearStage`, `Slit`, `EnergyDispersiveSpectrometer`); the area detector is carried pending.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the single-crystal data-collection strategies, the multi-temperature / variable-condition collection) are not written yet; they join as the deployment approaches the point where CORA drives P24. Whether a dedicated chemical-crystallography Method (vs reusing `diffraction`) enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p61/governance.md b/docs/deployments/p61/governance.md
deleted file mode 100644
index d079725731e..00000000000
--- a/docs/deployments/p61/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P61, and the trust shape that will gate it. First cut.*
-
-Governance at P61 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P61 is CORA's seventeenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P61 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P61, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P61 carries hazard classes specific to a high-energy white-beam / Large Volume Press beamline: the unmonochromated white beam (a stringent shielding / interlock case) and the LVP's high-pressure / high-temperature environment. Those land with the instruments that bring them when the deployment firms up; the press is modelled as a sample-environment `PressureCell` Asset when exposed, not a beam-steering device CORA drives.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P61, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p61/model.md b/docs/deployments/p61/model.md
deleted file mode 100644
index f408d6ee192..00000000000
--- a/docs/deployments/p61/model.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P61 content lives, its place as the last OnlineXML-modelled PETRA III beamline, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P61 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P61 new
-
-P61 is a seventeenth beamline at an existing Site, the facility's high-energy white-beam wiggler beamline (P61A Large Volume Press + P61B energy-dispersive diffraction). It is the **last PETRA III beamline with a public OnlineXML registry**, completing CORA's OnlineXML-driven coverage of the facility. At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice (one generic motor bank).
-
-## No new families (a thin, honest model)
-
-P61 coins no new Family. The motor bank binds `LinearStage`; the energy-dispersive detector is a pending `EnergyDispersiveSpectrometer` placeholder. Nothing in the catalog changes. The Large Volume Press (P61A), when exposed, would reuse the catalog `PressureCell` Family (graduated across 13-id and P02); it is carried pending (`PRESS-1`). The P61 registry slice exposes little beyond the grouped motor bank, so the source, the press, and the detectors are carried pending rather than invented, the model-what-the-source-supports posture as P11 / P21 / P23.
-
-## The control plane
-
-P61 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with one quirk: P61 is the only PETRA III extras package on the `debian/stretch` branch (the others are `debian/jessie`), so its snapshot vintage may differ. The handles are read from P61's public OnlineXML registry and carried confirm (`CTRL-1`). The energy-dispersive diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
-
-## Deliberately not here yet
-
-- **The source (`SRC-1`).** P61 is a damping-wiggler beamline (`source: superconducting-wiggler`); the wiggler parameters are not exposed in this registry slice.
-- **The Large Volume Press (`PRESS-1`).** P61A's press is not in the registry slice; would reuse the catalog `PressureCell` Family when exposed.
-- **The motor-bank axis roles (`GROUP-1`).** The `eh_mot*` bank carries no per-axis role; grouped as one stage.
-- **The detectors (`DET-1`).** The Ge energy-dispersive detector and any area detector are not in the registry slice; carried as a pending placeholder.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/stretch` (unusual for the set); some handles may lag the live Tango database.
-- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p61_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p61/notes.md b/docs/deployments/p61/notes.md
new file mode 100644
index 00000000000..1876348d008
--- /dev/null
+++ b/docs/deployments/p61/notes.md
@@ -0,0 +1,119 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P61 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P61's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### High-energy white-beam / energy-dispersive diffraction
+
+P61 uses the high-energy white beam from the damping wiggler for energy-dispersive diffraction (P61B engineering / materials studies) and Large Volume Press high-pressure / high-temperature in-situ studies (P61A), reading the [energy-dispersive detector](detector.md).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Energy-dispersive diffraction (white beam) | `energy_dispersive_diffraction` | high-energy white-beam energy-dispersive diffraction (P61B) and Large Volume Press in-situ studies (P61A); reuses the `energy_dispersive_diffraction` slug, a further consumer (`TECH-1`, `PRESS-1`) |
+
+### A thin high-energy white-beam beamline
+
+P61 is the fleet's high-energy white-beam wiggler beamline. Its technique reuses the `energy_dispersive_diffraction` slug already carried across the fleet, so it forces no new Method. The instrument anatomy reuses existing Families (`LinearStage`); the sparse registry slice means the model is deliberately thin, with the source, the Large Volume Press, and the detectors carried pending. The Large Volume Press (P61A), when exposed, would reuse the catalog `PressureCell` Family (graduated across 13-id and P02).
+
+### Not modelled yet
+
+The concrete acquisition recipes (the energy-dispersive diffraction scans, the LVP pressure / temperature ramps, the white-beam engineering measurements) are not written yet; they join as the deployment approaches the point where CORA drives P61. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P61, and the trust shape that will gate it. First cut.*
+
+Governance at P61 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P61 is CORA's seventeenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P61 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P61, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P61 carries hazard classes specific to a high-energy white-beam / Large Volume Press beamline: the unmonochromated white beam (a stringent shielding / interlock case) and the LVP's high-pressure / high-temperature environment. Those land with the instruments that bring them when the deployment firms up; the press is modelled as a sample-environment `PressureCell` Asset when exposed, not a beam-steering device CORA drives.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P61, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P61 content lives, its place as the last OnlineXML-modelled PETRA III beamline, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P61 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P61 new
+
+P61 is a seventeenth beamline at an existing Site, the facility's high-energy white-beam wiggler beamline (P61A Large Volume Press + P61B energy-dispersive diffraction). It is the **last PETRA III beamline with a public OnlineXML registry**, completing CORA's OnlineXML-driven coverage of the facility. At the modelling level it is a reuse-and-reinforce deployment, and a deliberately thin one given its sparse registry slice (one generic motor bank).
+
+### No new families (a thin, honest model)
+
+P61 coins no new Family. The motor bank binds `LinearStage`; the energy-dispersive detector is a pending `EnergyDispersiveSpectrometer` placeholder. Nothing in the catalog changes. The Large Volume Press (P61A), when exposed, would reuse the catalog `PressureCell` Family (graduated across 13-id and P02); it is carried pending (`PRESS-1`). The P61 registry slice exposes little beyond the grouped motor bank, so the source, the press, and the detectors are carried pending rather than invented, the model-what-the-source-supports posture as P11 / P21 / P23.
+
+### The control plane
+
+P61 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, with one quirk: P61 is the only PETRA III extras package on the `debian/stretch` branch (the others are `debian/jessie`), so its snapshot vintage may differ. The handles are read from P61's public OnlineXML registry and carried confirm (`CTRL-1`). The energy-dispersive diffraction acquisition runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`.
+
+### Deliberately not here yet
+
+- **The source (`SRC-1`).** P61 is a damping-wiggler beamline (`source: superconducting-wiggler`); the wiggler parameters are not exposed in this registry slice.
+- **The Large Volume Press (`PRESS-1`).** P61A's press is not in the registry slice; would reuse the catalog `PressureCell` Family when exposed.
+- **The motor-bank axis roles (`GROUP-1`).** The `eh_mot*` bank carries no per-axis role; grouped as one stage.
+- **The detectors (`DET-1`).** The Ge energy-dispersive detector and any area detector are not in the registry slice; carried as a pending placeholder.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/stretch` (unusual for the set); some handles may lag the live Tango database.
+- **The diffraction Method (`TECH-1`).** Whether it enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p61_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P61 team to confirm before the model can be trusted.*
+
+P61 was reverse-engineered from P61's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p61](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p61), branch `debian/stretch`) and a verified research brief, not from a live connection. The P61 registry is thin: one generic motor bank, no source / press / detectors exposed. P61 is CORA's seventeenth PETRA III beamline, the high-energy white-beam wiggler beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch (the registry exposes one host), and the P61A / P61B branch split? | A `p61-eh2` experiment hutch, from the OnlineXML `hasnp61eh2` host. | The Enclosure grouping. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the `eh_mot*` motor bank. | Grouped as one `LinearStage` stage carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The damping-wiggler source parameters (period, field), and whether the beam is white or monochromated per branch. | A damping wiggler delivering high-energy white beam; parameters pending. | The source Asset detail. |
+
+### Sample endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| PRESS-1 | Blocks-build | The Large Volume Press (P61A): its press / anvil control, and whether it should bind the catalog `PressureCell` Family. | A pending press; would reuse the catalog `PressureCell` (graduated across 13-id and P02) when exposed. | The press modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The energy-dispersive (Ge solid-state) detector, and any area detectors, absent from this registry slice. | A pending `EnergyDispersiveSpectrometer` placeholder; the chain not invented. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P61 device, and whether the OnlineXML `debian/stretch` branch (unusual for the set) matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the white-beam shielding / interlock, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does energy-dispersive diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `energy_dispersive_diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p61/questions.md b/docs/deployments/p61/questions.md
deleted file mode 100644
index 61f8578483f..00000000000
--- a/docs/deployments/p61/questions.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Open questions
-
-*What CORA needs the P61 team to confirm before the model can be trusted.*
-
-P61 was reverse-engineered from P61's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p61](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p61), branch `debian/stretch`) and a verified research brief, not from a live connection. The P61 registry is thin: one generic motor bank, no source / press / detectors exposed. P61 is CORA's seventeenth PETRA III beamline, the high-energy white-beam wiggler beamline. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a single experiment hutch (the registry exposes one host), and the P61A / P61B branch split? | A `p61-eh2` experiment hutch, from the OnlineXML `hasnp61eh2` host. | The Enclosure grouping. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the `eh_mot*` motor bank. | Grouped as one `LinearStage` stage carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The damping-wiggler source parameters (period, field), and whether the beam is white or monochromated per branch. | A damping wiggler delivering high-energy white beam; parameters pending. | The source Asset detail. |
-
-## Sample endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| PRESS-1 | Blocks-build | The Large Volume Press (P61A): its press / anvil control, and whether it should bind the catalog `PressureCell` Family. | A pending press; would reuse the catalog `PressureCell` (graduated across 13-id and P02) when exposed. | The press modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The energy-dispersive (Ge solid-state) detector, and any area detectors, absent from this registry slice. | A pending `EnergyDispersiveSpectrometer` placeholder; the chain not invented. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P61 device, and whether the OnlineXML `debian/stretch` branch (unusual for the set) matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the white-beam shielding / interlock, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does energy-dispersive diffraction enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `energy_dispersive_diffraction` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p61/techniques.md b/docs/deployments/p61/techniques.md
deleted file mode 100644
index 922eed88888..00000000000
--- a/docs/deployments/p61/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P61 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P61's diffraction technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## High-energy white-beam / energy-dispersive diffraction
-
-P61 uses the high-energy white beam from the damping wiggler for energy-dispersive diffraction (P61B engineering / materials studies) and Large Volume Press high-pressure / high-temperature in-situ studies (P61A), reading the [energy-dispersive detector](detector.md).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Energy-dispersive diffraction (white beam) | `energy_dispersive_diffraction` | high-energy white-beam energy-dispersive diffraction (P61B) and Large Volume Press in-situ studies (P61A); reuses the `energy_dispersive_diffraction` slug, a further consumer (`TECH-1`, `PRESS-1`) |
-
-## A thin high-energy white-beam beamline
-
-P61 is the fleet's high-energy white-beam wiggler beamline. Its technique reuses the `energy_dispersive_diffraction` slug already carried across the fleet, so it forces no new Method. The instrument anatomy reuses existing Families (`LinearStage`); the sparse registry slice means the model is deliberately thin, with the source, the Large Volume Press, and the detectors carried pending. The Large Volume Press (P61A), when exposed, would reuse the catalog `PressureCell` Family (graduated across 13-id and P02).
-
-## Not modelled yet
-
-The concrete acquisition recipes (the energy-dispersive diffraction scans, the LVP pressure / temperature ramps, the white-beam engineering measurements) are not written yet; they join as the deployment approaches the point where CORA drives P61. Whether the diffraction Method enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p64/governance.md b/docs/deployments/p64/governance.md
deleted file mode 100644
index 8332d43f7af..00000000000
--- a/docs/deployments/p64/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P64, and the trust shape that will gate it. First cut.*
-
-Governance at P64 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P64 is CORA's ninth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P64 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P64, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P64 shares its optics hutch with the applied-XAS sibling [P65](../p65/index.md), so the optics-enclosure access state couples to the neighbouring beamline, part of the `PSS-1` question.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P64, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p64/model.md b/docs/deployments/p64/model.md
deleted file mode 100644
index 2fa6e27439b..00000000000
--- a/docs/deployments/p64/model.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P64 content lives, its dilute high-rate fluorescence EXAFS via a large multi-element detector, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P64 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P64 new
-
-P64 is a ninth beamline at an existing Site, and the advanced half of the PETRA III XAS pair (with the applied [P65](../p65/index.md), sharing the optics host). Its distinguishing capability is dilute, high-rate fluorescence EXAFS via a large multi-element detector. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level.
-
-## No new families
-
-P64 coins no new Family. The undulator binds `InsertionDevice`; the Tsai mono `Monochromator`; the mirrors `Mirror`; the slits `Slit`; the sample / picomotor stages `LinearStage`; the Lambda detectors `Camera`; the multi-element fluorescence detector `EnergyDispersiveSpectrometer`. Nothing in the catalog changes. The 104-channel SIS3302 is grouped into one `EnergyDispersiveSpectrometer` Asset, not 104 Assets.
-
-## The control plane
-
-P64 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the Tsai-geometry DCM with its coupled undulator energy axis, the NewFocus picomotors, and the multi-element SIS3302 fluorescence detector. The handles are read from P64's public OnlineXML registry and carried confirm (`CTRL-1`); the optics host is shared with P65. The XAS acquisition (the continuous energy fly-scan read against the multi-element fluorescence) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the BMM / ISS XAS seams.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The energy axis is read; the period is not exposed.
-- **The optics detail (`OPT-1`).** The Tsai DCM crystal cut and the mirror coatings are carried confirm-pending.
-- **The sample-bank axis roles (`GROUP-1`).** The `exp_mot` / `dac_*` bank carries no per-axis role; grouped, with the DAC sub-stage noted.
-- **The detector detail (`DET-1`).** The multi-element element count, the deadtime / ROI handling, and the transmission ion chambers are named, not fully bound.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **`xas_spectroscopy` Method (`TECH-1`).** Whether XAS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p64_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p64/notes.md b/docs/deployments/p64/notes.md
new file mode 100644
index 00000000000..9c9393f635c
--- /dev/null
+++ b/docs/deployments/p64/notes.md
@@ -0,0 +1,114 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P64 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P64's XAS technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Advanced X-ray absorption spectroscopy
+
+P64 scans the incident energy across an absorption edge (the Tsai DCM coupled to the undulator) and reads the absorption in transmission (the Lambda detectors) and, for dilute samples, in fluorescence on the large [multi-element detector](detector.md), measuring EXAFS / XANES.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray absorption spectroscopy (EXAFS / XANES) | `xas_spectroscopy` | the coupled mono + undulator energy scan read against transmission / multi-element fluorescence; reuses the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 share, a further consumer (`TECH-1`) |
+
+### A high-rate fluorescence EXAFS beamline on familiar vocabulary
+
+P64 is the advanced half of the PETRA III XAS pair (with the applied [P65](../p65/index.md)). Its distinguishing capability is dilute, high-rate fluorescence detection via the large multi-element SIS3302 detector, but it coins no new vocabulary: it reuses the `xas_spectroscopy` slug already carried pending across the fleet, and its instrument anatomy reuses existing Families (the `Monochromator`, the `Mirror` pair, the `Camera` Lambda detectors, the `EnergyDispersiveSpectrometer` fluorescence detector). The continuous energy fly-scan is a control-plane detail, not a new Method.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the QEXAFS / step-scan energy sequences, the multi-element detector deadtime handling, the DAC high-pressure XAS) are not written yet; they join as the deployment approaches the point where CORA drives P64. Whether `xas_spectroscopy` enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P64, and the trust shape that will gate it. First cut.*
+
+Governance at P64 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P64 is CORA's ninth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P64 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P64, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P64 shares its optics hutch with the applied-XAS sibling [P65](../p65/index.md), so the optics-enclosure access state couples to the neighbouring beamline, part of the `PSS-1` question.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P64, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P64 content lives, its dilute high-rate fluorescence EXAFS via a large multi-element detector, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P64 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P64 new
+
+P64 is a ninth beamline at an existing Site, and the advanced half of the PETRA III XAS pair (with the applied [P65](../p65/index.md), sharing the optics host). Its distinguishing capability is dilute, high-rate fluorescence EXAFS via a large multi-element detector. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level.
+
+### No new families
+
+P64 coins no new Family. The undulator binds `InsertionDevice`; the Tsai mono `Monochromator`; the mirrors `Mirror`; the slits `Slit`; the sample / picomotor stages `LinearStage`; the Lambda detectors `Camera`; the multi-element fluorescence detector `EnergyDispersiveSpectrometer`. Nothing in the catalog changes. The 104-channel SIS3302 is grouped into one `EnergyDispersiveSpectrometer` Asset, not 104 Assets.
+
+### The control plane
+
+P64 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines. Its distinctive devices are the Tsai-geometry DCM with its coupled undulator energy axis, the NewFocus picomotors, and the multi-element SIS3302 fluorescence detector. The handles are read from P64's public OnlineXML registry and carried confirm (`CTRL-1`); the optics host is shared with P65. The XAS acquisition (the continuous energy fly-scan read against the multi-element fluorescence) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the BMM / ISS XAS seams.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The energy axis is read; the period is not exposed.
+- **The optics detail (`OPT-1`).** The Tsai DCM crystal cut and the mirror coatings are carried confirm-pending.
+- **The sample-bank axis roles (`GROUP-1`).** The `exp_mot` / `dac_*` bank carries no per-axis role; grouped, with the DAC sub-stage noted.
+- **The detector detail (`DET-1`).** The multi-element element count, the deadtime / ROI handling, and the transmission ion chambers are named, not fully bound.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **`xas_spectroscopy` Method (`TECH-1`).** Whether XAS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p64_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P64 team to confirm before the model can be trusted.*
+
+P64 was reverse-engineered from P64's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p64](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p64), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, detector element count, or energy calibration. P64 is CORA's ninth PETRA III beamline and the advanced half of the PETRA III XAS pair. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding the experiment endstation, sharing the optics with P65? | A `p64-oh` optics hutch and a `p64-eh` endstation. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; energy axis read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the sample bank (`exp_mot*`, `dac_*`) and the picomotor assignments. | Grouped as `LinearStage` Assets carrying the bank prefix; per-axis roles pending. | The sample-stage Asset boundaries. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The Tsai DCM crystal cut and energy range, and the two mirror coatings / roles. | A Tsai `Monochromator` and two `Mirror`s; physical detail pending. | The optics modelling. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The multi-element fluorescence detector element count (the 104-channel SIS3302), the deadtime / ROI handling, the two Lambda 750k roles, and the transmission ion chambers. | A grouped `EnergyDispersiveSpectrometer` + two `Camera` Lambdas; element count and ion chambers pending. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P64 device, the shared P64 / P65 optics host, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P65. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics coupling with P65, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does X-ray absorption spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 share; none coined. | The technique Capability. |
diff --git a/docs/deployments/p64/questions.md b/docs/deployments/p64/questions.md
deleted file mode 100644
index 6309e767d02..00000000000
--- a/docs/deployments/p64/questions.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Open questions
-
-*What CORA needs the P64 team to confirm before the model can be trusted.*
-
-P64 was reverse-engineered from P64's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p64](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p64), branch `debian/jessie`) and a verified research brief, not from a live connection. The registry carries real Tango device names and control handles, but no crystal cuts, detector element count, or energy calibration. P64 is CORA's ninth PETRA III beamline and the advanced half of the PETRA III XAS pair. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch feeding the experiment endstation, sharing the optics with P65? | A `p64-oh` optics hutch and a `p64-eh` endstation. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; energy axis read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the sample bank (`exp_mot*`, `dac_*`) and the picomotor assignments. | Grouped as `LinearStage` Assets carrying the bank prefix; per-axis roles pending. | The sample-stage Asset boundaries. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The Tsai DCM crystal cut and energy range, and the two mirror coatings / roles. | A Tsai `Monochromator` and two `Mirror`s; physical detail pending. | The optics modelling. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The multi-element fluorescence detector element count (the 104-channel SIS3302), the deadtime / ROI handling, the two Lambda 750k roles, and the transmission ion chambers. | A grouped `EnergyDispersiveSpectrometer` + two `Camera` Lambdas; element count and ion chambers pending. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P64 device, the shared P64 / P65 optics host, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P65. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics coupling with P65, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does X-ray absorption spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 share; none coined. | The technique Capability. |
diff --git a/docs/deployments/p64/techniques.md b/docs/deployments/p64/techniques.md
deleted file mode 100644
index ca5787e051b..00000000000
--- a/docs/deployments/p64/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P64 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P64's XAS technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Advanced X-ray absorption spectroscopy
-
-P64 scans the incident energy across an absorption edge (the Tsai DCM coupled to the undulator) and reads the absorption in transmission (the Lambda detectors) and, for dilute samples, in fluorescence on the large [multi-element detector](detector.md), measuring EXAFS / XANES.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray absorption spectroscopy (EXAFS / XANES) | `xas_spectroscopy` | the coupled mono + undulator energy scan read against transmission / multi-element fluorescence; reuses the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 share, a further consumer (`TECH-1`) |
-
-## A high-rate fluorescence EXAFS beamline on familiar vocabulary
-
-P64 is the advanced half of the PETRA III XAS pair (with the applied [P65](../p65/index.md)). Its distinguishing capability is dilute, high-rate fluorescence detection via the large multi-element SIS3302 detector, but it coins no new vocabulary: it reuses the `xas_spectroscopy` slug already carried pending across the fleet, and its instrument anatomy reuses existing Families (the `Monochromator`, the `Mirror` pair, the `Camera` Lambda detectors, the `EnergyDispersiveSpectrometer` fluorescence detector). The continuous energy fly-scan is a control-plane detail, not a new Method.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the QEXAFS / step-scan energy sequences, the multi-element detector deadtime handling, the DAC high-pressure XAS) are not written yet; they join as the deployment approaches the point where CORA drives P64. Whether `xas_spectroscopy` enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/p65/governance.md b/docs/deployments/p65/governance.md
deleted file mode 100644
index 7681a5b65ce..00000000000
--- a/docs/deployments/p65/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at P65, and the trust shape that will gate it. First cut.*
-
-Governance at P65 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-P65 is CORA's tenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P65 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P65, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P65 shares its optics hutch with the advanced-XAS sibling [P64](../p64/index.md), so the optics-enclosure access state couples to the neighbouring beamline, part of the `PSS-1` question.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P65, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/p65/model.md b/docs/deployments/p65/model.md
deleted file mode 100644
index 93af4d0c8b6..00000000000
--- a/docs/deployments/p65/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's P65 content lives, a deliberately thin applied / high-throughput XAS model, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at P65 |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes P65 new
-
-P65 is a tenth beamline at an existing Site, and the applied / high-throughput half of the PETRA III XAS pair (with the advanced [P64](../p64/index.md), sharing the optics host). Its science is routine transmission + fluorescence EXAFS / XANES. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level, and a deliberately thin model matching its sparse registry slice.
-
-## No new families (a thin, honest model)
-
-P65 coins no new Family. The undulator binds `InsertionDevice`; the CDCM energy axis `Monochromator`; the stages `LinearStage`; the slit `Slit`; the table `Table`; the detection placeholder `FluxMonitor`. Nothing in the catalog changes. The P65 registry slice exposes little beyond the energy axis and the sample bank, so the detection chain is carried as a pending placeholder rather than invented (`DET-1`), the same model-what-the-source-supports posture as P11 and the thinner reverse-engineered scaffolds.
-
-## The control plane
-
-P65 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, sharing the optics host (`hasnp64`) with P64. The handles are read from P65's public OnlineXML registry and carried confirm (`CTRL-1`). The XAS acquisition (the CDCM energy scan read against transmission / fluorescence) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the BMM / ISS XAS seams.
-
-## Deliberately not here yet
-
-- **The undulator parameters (`SRC-1`).** The energy axis is read; the period is not exposed.
-- **The optics detail (`OPT-1`).** The CDCM crystal cut and the optics-bank breakdown are carried confirm-pending.
-- **The bank axis roles (`GROUP-1`).** The `oh_*`, `fe_*`, and `a2_*` banks carry no per-axis role; grouped as stage Assets.
-- **The detection chain (`DET-1`).** The ion chambers and fluorescence detector are not in the registry slice; carried as a pending `FluxMonitor` placeholder.
-- **The host mapping (`HOST-1`).** The energy / optics report on the shared P64 host; modelled in the P65 optics enclosure with the host flagged.
-- **The dummy stubs (`STUB-1`).** The `a2_dmy*` placeholder devices are noted, not modelled.
-- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
-- **`xas_spectroscopy` Method (`TECH-1`).** Whether XAS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
-- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
-- **The simulated devices and full asset-tree scenarios.** No `test_p65_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/p65/notes.md b/docs/deployments/p65/notes.md
new file mode 100644
index 00000000000..cee2f522c4f
--- /dev/null
+++ b/docs/deployments/p65/notes.md
@@ -0,0 +1,118 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of P65 is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P65's XAS technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Applied X-ray absorption spectroscopy
+
+P65 scans the incident energy across an absorption edge (the channel-cut DCM) and reads the absorption in transmission (ion chambers) and fluorescence, for routine applied EXAFS / XANES (catalysis, batteries, environmental science).
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray absorption spectroscopy (EXAFS / XANES) | `xas_spectroscopy` | the CDCM energy scan read against transmission / fluorescence; reuses the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 / P64 share, a further consumer (`TECH-1`) |
+
+### The applied half of the XAS pair
+
+P65 is the applied / high-throughput half of the PETRA III XAS pair, the sibling of the advanced [P64](../p64/index.md). Where P64 specialises in dilute high-rate fluorescence with a large multi-element detector, P65 serves routine transmission + fluorescence EXAFS. Both reuse the `xas_spectroscopy` slug; neither coins a new Family or Method. P65's instrument anatomy is deliberately thin (a `Monochromator` energy axis, `LinearStage` sample bank, `Slit`, `Table`), matching what the registry exposes.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the step / continuous energy scans, the ion-chamber / fluorescence detection chain, the sample-changer throughput loop) are not written yet; they join as the deployment approaches the point where CORA drives P65. Whether `xas_spectroscopy` enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at P65, and the trust shape that will gate it. First cut.*
+
+Governance at P65 follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [PETRA III Site](../petra-iii/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+P65 is CORA's tenth PETRA III beamline: the DESY operator pool and the safety-review structure are carried pending on the [PETRA III Site](../petra-iii/index.md#safety-and-governance), shared across the facility's beamlines, until DESY staff confirm them (`GOV-1`). P65 is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives P65, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The OnlineXML carries beamline devices, not the personnel-safety interlock leaves, so the Enclosure permit signals and the interlock structure are carried pending and are not invented here (`PSS-1`). P65 shares its optics hutch with the advanced-XAS sibling [P64](../p64/index.md), so the optics-enclosure access state couples to the neighbouring beamline, part of the `PSS-1` question.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives P65, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's P65 content lives, a deliberately thin applied / high-throughput XAS model, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at P65 |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes P65 new
+
+P65 is a tenth beamline at an existing Site, and the applied / high-throughput half of the PETRA III XAS pair (with the advanced [P64](../p64/index.md), sharing the optics host). Its science is routine transmission + fluorescence EXAFS / XANES. At the modelling level it is a reuse-and-reinforce deployment: nothing new at the vocabulary level, and a deliberately thin model matching its sparse registry slice.
+
+### No new families (a thin, honest model)
+
+P65 coins no new Family. The undulator binds `InsertionDevice`; the CDCM energy axis `Monochromator`; the stages `LinearStage`; the slit `Slit`; the table `Table`; the detection placeholder `FluxMonitor`. Nothing in the catalog changes. The P65 registry slice exposes little beyond the energy axis and the sample bank, so the detection chain is carried as a pending placeholder rather than invented (`DET-1`), the same model-what-the-source-supports posture as P11 and the thinner reverse-engineered scaffolds.
+
+### The control plane
+
+P65 sits on the PETRA III Tango device floor with Sardana as the scan layer, the same as the other PETRA III beamlines, sharing the optics host (`hasnp64`) with P64. The handles are read from P65's public OnlineXML registry and carried confirm (`CTRL-1`). The XAS acquisition (the CDCM energy scan read against transmission / fluorescence) runs as a Sardana macro; that orchestration is the seam CORA's edge replaces or drives through over its `ControlPort`, the same shape as the BMM / ISS XAS seams.
+
+### Deliberately not here yet
+
+- **The undulator parameters (`SRC-1`).** The energy axis is read; the period is not exposed.
+- **The optics detail (`OPT-1`).** The CDCM crystal cut and the optics-bank breakdown are carried confirm-pending.
+- **The bank axis roles (`GROUP-1`).** The `oh_*`, `fe_*`, and `a2_*` banks carry no per-axis role; grouped as stage Assets.
+- **The detection chain (`DET-1`).** The ion chambers and fluorescence detector are not in the registry slice; carried as a pending `FluxMonitor` placeholder.
+- **The host mapping (`HOST-1`).** The energy / optics report on the shared P64 host; modelled in the P65 optics enclosure with the host flagged.
+- **The dummy stubs (`STUB-1`).** The `a2_dmy*` placeholder devices are noted, not modelled.
+- **The handle freshness (`CTRL-1`).** The OnlineXML branch is `debian/jessie`; some handles may lag the live Tango database.
+- **`xas_spectroscopy` Method (`TECH-1`).** Whether XAS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending.
+- **The PSS permit signals (`PSS-1`).** Not in the OnlineXML; carried pending, not invented.
+- **The simulated devices and full asset-tree scenarios.** No `test_p65_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the P65 team to confirm before the model can be trusted.*
+
+P65 was reverse-engineered from P65's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p65](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p65), branch `debian/jessie`) and a verified research brief, not from a live connection. The P65 registry slice is thin: an energy axis, a sample bank, a slit / table, the undulator. The XAS detection is not exposed. P65 is CORA's tenth PETRA III beamline and the applied half of the PETRA III XAS pair. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch (shared with P64) feeding the experiment endstation? | A `p65-oh` optics hutch and a `p65-eh` endstation. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; energy axis read, period pending. | The source Asset detail. |
+| GROUP-1 | Nice-to-have | The per-axis roles of the banks (`oh_*`, `fe_*`, `a2_*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
+| STUB-1 | Nice-to-have | The `a2_dmy*` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The stub status. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Blocks-go-live | The CDCM crystal cut and energy range, and the optics-bank breakdown. | A channel-cut `Monochromator` energy axis and grouped optics stages; physical detail pending. | The optics modelling. |
+| HOST-1 | Nice-to-have | The CDCM energy / optics report on the shared P64 host (`hasnp64`). How is the shared optics split between P64 and P65? | The P65 optics are homed in `p65-oh`; the host is flagged. | The shared-optics mapping. |
+
+### The detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The XAS detection chain: the transmission ion chambers (I0 / I1 / I2), the fluorescence detector model, and the digitizer (absent from this registry slice). | A pending `FluxMonitor` placeholder; the chain not invented. | The detector modelling. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | The Tango device handles per P65 device, the shared P64 / P65 optics host, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P64. | Binding each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics coupling with P64, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
+| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | Does X-ray absorption spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `xas_spectroscopy` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p65/questions.md b/docs/deployments/p65/questions.md
deleted file mode 100644
index 8f292d8a245..00000000000
--- a/docs/deployments/p65/questions.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Open questions
-
-*What CORA needs the P65 team to confirm before the model can be trusted.*
-
-P65 was reverse-engineered from P65's own public OnlineXML device registry ([gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p65](https://gitlab.desy.de/petra-iii-debian-packages/python-nxstools-extras-p65), branch `debian/jessie`) and a verified research brief, not from a live connection. The P65 registry slice is thin: an energy axis, a sample bank, a slit / table, the undulator. The XAS detection is not exposed. P65 is CORA's tenth PETRA III beamline and the applied half of the PETRA III XAS pair. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: an optics hutch (shared with P64) feeding the experiment endstation? | A `p65-oh` optics hutch and a `p65-eh` endstation. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The undulator period and parameters. | An undulator; energy axis read, period pending. | The source Asset detail. |
-| GROUP-1 | Nice-to-have | The per-axis roles of the banks (`oh_*`, `fe_*`, `a2_*`). | Grouped as stage Assets carrying the bank prefix; per-axis roles pending. | The Asset boundaries. |
-| STUB-1 | Nice-to-have | The `a2_dmy*` dummy stubs: test / placeholder devices, or real channels? | Noted as dummy stubs, not modelled. | The stub status. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Blocks-go-live | The CDCM crystal cut and energy range, and the optics-bank breakdown. | A channel-cut `Monochromator` energy axis and grouped optics stages; physical detail pending. | The optics modelling. |
-| HOST-1 | Nice-to-have | The CDCM energy / optics report on the shared P64 host (`hasnp64`). How is the shared optics split between P64 and P65? | The P65 optics are homed in `p65-oh`; the host is flagged. | The shared-optics mapping. |
-
-## The detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The XAS detection chain: the transmission ion chambers (I0 / I1 / I2), the fluorescence detector model, and the digitizer (absent from this registry slice). | A pending `FluxMonitor` placeholder; the chain not invented. | The detector modelling. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | The Tango device handles per P65 device, the shared P64 / P65 optics host, and whether the OnlineXML `debian/jessie` branch matches the live Tango database. | The handles read from the public OnlineXML, carried pending; the floor is Tango + Sardana; optics shared with P64. | Binding each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The DESY personnel-safety permit signals, the shared-optics coupling with P64, and the photon / front-end shutters (absent from the OnlineXML). | Permit leaves and shutters to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent and the cooling / beam supplies. | Photon beam, cooling water, vacuum. | The Supply observations. |
-| GOV-1 | Nice-to-have | The DESY operator pool and safety-review structure (site-level). | Carried pending on the PETRA III Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | Does X-ray absorption spectroscopy enter CORA's catalog as a Capability / Method? | Deferred: carried as a pending Practice reusing the `xas_spectroscopy` slug; none coined. | The technique Capability. |
diff --git a/docs/deployments/p65/techniques.md b/docs/deployments/p65/techniques.md
deleted file mode 100644
index 17fbac51007..00000000000
--- a/docs/deployments/p65/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What the modelled part of P65 is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../petra-iii/index.md#the-techniques-adapted-here) is how a facility adapts it. P65's XAS technique earns no catalog Method today, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Applied X-ray absorption spectroscopy
-
-P65 scans the incident energy across an absorption edge (the channel-cut DCM) and reads the absorption in transmission (ion chambers) and fluorescence, for routine applied EXAFS / XANES (catalysis, batteries, environmental science).
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray absorption spectroscopy (EXAFS / XANES) | `xas_spectroscopy` | the CDCM energy scan read against transmission / fluorescence; reuses the `xas_spectroscopy` slug BMM / ISS / i20-1 / P04 / P64 share, a further consumer (`TECH-1`) |
-
-## The applied half of the XAS pair
-
-P65 is the applied / high-throughput half of the PETRA III XAS pair, the sibling of the advanced [P64](../p64/index.md). Where P64 specialises in dilute high-rate fluorescence with a large multi-element detector, P65 serves routine transmission + fluorescence EXAFS. Both reuse the `xas_spectroscopy` slug; neither coins a new Family or Method. P65's instrument anatomy is deliberately thin (a `Monochromator` energy axis, `LinearStage` sample bank, `Slit`, `Table`), matching what the registry exposes.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the step / continuous energy scans, the ion-chamber / fluorescence detection chain, the sample-changer throughput loop) are not written yet; they join as the deployment approaches the point where CORA drives P65. Whether `xas_spectroscopy` enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/pdf/governance.md b/docs/deployments/pdf/governance.md
deleted file mode 100644
index 4915f647748..00000000000
--- a/docs/deployments/pdf/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at PDF and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A PDF beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may change the incident energy, move a detector tower to a new distance, set a sample-environment temperature ramp, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## In-situ and high-throughput runs
-
-A variable-temperature total-scattering series or a high-throughput sample queue can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the temperature ramp and the acquisition while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next temperature point, decide when the pattern statistics are sufficient, trigger a PDF reduction to check the result), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/pdf/model.md b/docs/deployments/pdf/model.md
deleted file mode 100644
index d368ea8eb36..00000000000
--- a/docs/deployments/pdf/model.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's PDF content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at PDF |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [the stage pages](source.md) (`EnergyAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (28-ID-1-A optics, 28-ID-1-B endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring its twin [XPD](../xpd/model.md) and the other reverse-engineered deployments. Left out on purpose:
-
-- **No new Family.** PDF is a reuse-and-reinforce deployment: the flat-panel and pixel detectors bind `Camera`, the photodiode `FluxMonitor`, the thermal cluster `TemperatureController`, the side-bounce mono `Monochromator`, the focusing mirror `Mirror`, the spinner `Goniometer`, the slits `Slit`, the fast shutter `Shutter`, the beamstops `BeamStop`, the detector and sample-environment stages `LinearStage`, the master energy a `PseudoAxis`. Nothing graduates and the catalog is unchanged.
-- **The held loose family.** The `StorageRing` current readback is a loose supply observation (machine state), never an Asset Family.
-- **No new Capability or Method.** Total scattering / PDF and powder diffraction sit on the deferred `total_scattering` / `powder_diffraction` Methods Diamond i11 and i15-1 left pending (`TECH-1`); PDF reinforces them at a second NSLS-II endstation without coining either, and records no Practice until they land. The PDF reduction (azimuthal integration and the Fourier transform to G(r)) is `ComputePort` work, not a Method.
-- **The gas-handling and humidity rig.** Present in the profile collection but carried deferred (`ENV-1`): a design-phase scaffold models the thermal environment that is settled (`TemperatureController`) and defers the in-situ gas / humidity actuators until they earn modelling, the same discipline the other deployments follow.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/pdf/notes.md b/docs/deployments/pdf/notes.md
new file mode 100644
index 00000000000..54fb4a341b2
--- /dev/null
+++ b/docs/deployments/pdf/notes.md
@@ -0,0 +1,110 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at PDF: high-energy total-scattering and powder-diffraction techniques, each a [Catalog](../../catalog/methods.md) Method. PDF is the twin of [XPD](../xpd/notes.md#techniques) and follows its deferral exactly, after Diamond [i11](../i11/notes.md#techniques) and [i15-1](../i15-1/notes.md#techniques).*
+
+PDF's techniques are high-energy total scattering and powder diffraction: a high-energy beam through a powder or capillary sample onto a large area detector, with the sample-to-detector distance setting the accessible Q. These Methods are new to CORA's imaging- and spectroscopy-heritage catalog. As at XPD, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Total scattering / PDF | `total_scattering` | rapid-acquisition pair distribution function: a near and a far detector distance merged to high Q (DIST-1); Method not yet in catalog, shared with i15-1 and XPD |
+| Powder diffraction | `powder_diffraction` | the same high-energy beam and detector for Rietveld-quality powder patterns; Method not yet in catalog, shared with i11 and XPD |
+| Alignment | [`alignment`](../../catalog/methods.md) | beam, monochromator, mirror, and slit tuning; reuses the existing Method |
+
+Both techniques need the [sample spinner and environment](sample.md) and the [area detectors](detector.md); the exposure is gated by the fast shutter, with the two-distance merge sequenced in software (DIST-1).
+
+### Why the Methods stay deferred
+
+Diamond i11 (powder diffraction) and i15-1 (total scattering / PDF) opened the question of whether these Methods enter CORA's catalog (TECH-1), and `main` deliberately left them pending: the concrete acquisition recipes (energies, distances, exposures, the near / far merge) join as the deployment approaches the point where CORA drives the beamline. PDF reinforces both Methods at a second NSLS-II endstation without coining either, the same earn-the-abstraction discipline XPD follows. Because the defining Methods are not in the catalog, PDF records **no Practice** in the [NSLS-II Site](../nsls2/index.md), exactly as XPD records none; the binding lands when the Method does.
+
+The PDF reduction itself (the azimuthal integration of the detector frames and the Fourier transform of the structure function into the pair distribution function G(r)) is `ComputePort` work, not a beamline Method: the beamline takes the frames, CORA's compute leg turns them into the result.
+
+## Governance
+
+*Who may act at PDF and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. A PDF beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may change the incident energy, move a detector tower to a new distance, set a sample-environment temperature ramp, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### In-situ and high-throughput runs
+
+A variable-temperature total-scattering series or a high-throughput sample queue can run long and unattended, which is where CORA's trust shape earns its keep: the engine holds the temperature ramp and the acquisition while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer acquisition (choose the next temperature point, decide when the pattern statistics are sufficient, trigger a PDF reduction to check the result), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's PDF content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at PDF |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [the stage pages](source.md) (`EnergyAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (28-ID-1-A optics, 28-ID-1-B endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring its twin [XPD](../xpd/notes.md#model) and the other reverse-engineered deployments. Left out on purpose:
+
+- **No new Family.** PDF is a reuse-and-reinforce deployment: the flat-panel and pixel detectors bind `Camera`, the photodiode `FluxMonitor`, the thermal cluster `TemperatureController`, the side-bounce mono `Monochromator`, the focusing mirror `Mirror`, the spinner `Goniometer`, the slits `Slit`, the fast shutter `Shutter`, the beamstops `BeamStop`, the detector and sample-environment stages `LinearStage`, the master energy a `PseudoAxis`. Nothing graduates and the catalog is unchanged.
+- **The held loose family.** The `StorageRing` current readback is a loose supply observation (machine state), never an Asset Family.
+- **No new Capability or Method.** Total scattering / PDF and powder diffraction sit on the deferred `total_scattering` / `powder_diffraction` Methods Diamond i11 and i15-1 left pending (`TECH-1`); PDF reinforces them at a second NSLS-II endstation without coining either, and records no Practice until they land. The PDF reduction (azimuthal integration and the Fourier transform to G(r)) is `ComputePort` work, not a Method.
+- **The gas-handling and humidity rig.** Present in the profile collection but carried deferred (`ENV-1`): a design-phase scaffold models the thermal environment that is settled (`TemperatureController`) and defers the in-situ gas / humidity actuators until they earn modelling, the same discipline the other deployments follow.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the PDF team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/pdf-profile-collection`](https://github.com/NSLS2/pdf-profile-collection) profile collection and the [`NSLS2/pdftools`](https://github.com/NSLS2/pdftools) device library): the EPICS PVs are read from them, but vendor identities, physical positions, and the detector geometry are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The 28-ID source identity and parameters. No source PV is in the profile collection; CORA infers the shared 28-ID damping wiggler from facility knowledge. | An insertion device, the shared damping wiggler, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the fast and photon shutters are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| MACHINE-1 | Nice-to-have | The storage-ring state PDF reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs beyond `ring_current` pending. | The machine-state observation. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MONO-1 | Nice-to-have | The side-bounce monochromator crystal cut, reflection, and energy range. The device (`Mono:SBM`) is confirmed. | A single high-energy Laue `Monochromator` Asset; cut and range blank. | The Monochromator settings. |
+| ENERGY-1 | Nice-to-have | Is PDF always fixed-energy per experiment, or does any routine scan energy as the measurement? | Fixed-energy; energy scan deferred. | The energy Capability decision. |
+
+### Sample and environment
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The full spinner and analyzer goniohead axis set, and whether the sample orientation warrants a `Goniometer` plus an Assembly (the i11 precedent). | A `Goniometer` spinner; the analyzer noted, the Assembly deferred. | The sample-stage modelling. |
+| TEMP-1 | Nice-to-have | Which thermal units are live (the cs800 cryostream make, the Lakeshore cryostat, the Linkam furnace) and their ranges. | One thermal-environment `TemperatureController` Asset; units blank. | The sample-environment roster. |
+| ENV-1 | Nice-to-have | The gas-handling and humidity rig (flow valves, residual-gas analyzer, humidity) is present in source but not modelled. Does it warrant a settable actuator Asset (the loose `FlowController` family)? | Deferred; the thermal cluster is modelled, the gas / humidity rig noted. | The in-situ environment modelling. |
+
+### Detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Which detectors are live (the two PerkinElmer panels, the Pilatus) and which serves which role. | Both Cameras; PerkinElmer primary; Pilatus alongside. | The detector roster. |
+| DIST-1 | Blocks-go-live | The two-detector / two-distance geometry: the near and far distances, which tower is static vs moving, and how the panels merge for the PDF Q-range (the `TwoDetectors` plan). | Two `LinearStage` towers; the merge deferred. | The detector geometry and Q-range. |
+| DIAG-1 | Nice-to-have | The background-photodiode / flux channel detail. | A read-only `FluxMonitor` probe; channel map blank. | The FluxMonitor binding. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs behind the EPICS motor records. | One `MotionController` family bound (`EndstationMotionController`), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the total-scattering and powder-diffraction Methods enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i11 / i15-1 and XPD opened. | Methods deferred (rendered unlinked), no Practice recorded. | The powder / PDF Method scope. |
diff --git a/docs/deployments/pdf/questions.md b/docs/deployments/pdf/questions.md
deleted file mode 100644
index fb48b2d3171..00000000000
--- a/docs/deployments/pdf/questions.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Open questions
-
-*What CORA needs the PDF team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/pdf-profile-collection`](https://github.com/NSLS2/pdf-profile-collection) profile collection and the [`NSLS2/pdftools`](https://github.com/NSLS2/pdftools) device library): the EPICS PVs are read from them, but vendor identities, physical positions, and the detector geometry are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The 28-ID source identity and parameters. No source PV is in the profile collection; CORA infers the shared 28-ID damping wiggler from facility knowledge. | An insertion device, the shared damping wiggler, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the fast and photon shutters are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| MACHINE-1 | Nice-to-have | The storage-ring state PDF reads (current, fill, status). | Observe-only machine state, a loose `StorageRing`; the exact PVs beyond `ring_current` pending. | The machine-state observation. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure (site-level, shared across the beamlines). | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MONO-1 | Nice-to-have | The side-bounce monochromator crystal cut, reflection, and energy range. The device (`Mono:SBM`) is confirmed. | A single high-energy Laue `Monochromator` Asset; cut and range blank. | The Monochromator settings. |
-| ENERGY-1 | Nice-to-have | Is PDF always fixed-energy per experiment, or does any routine scan energy as the measurement? | Fixed-energy; energy scan deferred. | The energy Capability decision. |
-
-## Sample and environment
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The full spinner and analyzer goniohead axis set, and whether the sample orientation warrants a `Goniometer` plus an Assembly (the i11 precedent). | A `Goniometer` spinner; the analyzer noted, the Assembly deferred. | The sample-stage modelling. |
-| TEMP-1 | Nice-to-have | Which thermal units are live (the cs800 cryostream make, the Lakeshore cryostat, the Linkam furnace) and their ranges. | One thermal-environment `TemperatureController` Asset; units blank. | The sample-environment roster. |
-| ENV-1 | Nice-to-have | The gas-handling and humidity rig (flow valves, residual-gas analyzer, humidity) is present in source but not modelled. Does it warrant a settable actuator Asset (the loose `FlowController` family)? | Deferred; the thermal cluster is modelled, the gas / humidity rig noted. | The in-situ environment modelling. |
-
-## Detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Which detectors are live (the two PerkinElmer panels, the Pilatus) and which serves which role. | Both Cameras; PerkinElmer primary; Pilatus alongside. | The detector roster. |
-| DIST-1 | Blocks-go-live | The two-detector / two-distance geometry: the near and far distances, which tower is static vs moving, and how the panels merge for the PDF Q-range (the `TwoDetectors` plan). | Two `LinearStage` towers; the merge deferred. | The detector geometry and Q-range. |
-| DIAG-1 | Nice-to-have | The background-photodiode / flux channel detail. | A read-only `FluxMonitor` probe; channel map blank. | The FluxMonitor binding. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs behind the EPICS motor records. | One `MotionController` family bound (`EndstationMotionController`), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the total-scattering and powder-diffraction Methods enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i11 / i15-1 and XPD opened. | Methods deferred (rendered unlinked), no Practice recorded. | The powder / PDF Method scope. |
diff --git a/docs/deployments/pdf/techniques.md b/docs/deployments/pdf/techniques.md
deleted file mode 100644
index 46e878e2a58..00000000000
--- a/docs/deployments/pdf/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What CORA would run at PDF: high-energy total-scattering and powder-diffraction techniques, each a [Catalog](../../catalog/methods.md) Method. PDF is the twin of [XPD](../xpd/techniques.md) and follows its deferral exactly, after Diamond [i11](../i11/techniques.md) and [i15-1](../i15-1/techniques.md).*
-
-PDF's techniques are high-energy total scattering and powder diffraction: a high-energy beam through a powder or capillary sample onto a large area detector, with the sample-to-detector distance setting the accessible Q. These Methods are new to CORA's imaging- and spectroscopy-heritage catalog. As at XPD, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Total scattering / PDF | `total_scattering` | rapid-acquisition pair distribution function: a near and a far detector distance merged to high Q (DIST-1); Method not yet in catalog, shared with i15-1 and XPD |
-| Powder diffraction | `powder_diffraction` | the same high-energy beam and detector for Rietveld-quality powder patterns; Method not yet in catalog, shared with i11 and XPD |
-| Alignment | [`alignment`](../../catalog/methods.md) | beam, monochromator, mirror, and slit tuning; reuses the existing Method |
-
-Both techniques need the [sample spinner and environment](sample.md) and the [area detectors](detector.md); the exposure is gated by the fast shutter, with the two-distance merge sequenced in software (DIST-1).
-
-## Why the Methods stay deferred
-
-Diamond i11 (powder diffraction) and i15-1 (total scattering / PDF) opened the question of whether these Methods enter CORA's catalog (TECH-1), and `main` deliberately left them pending: the concrete acquisition recipes (energies, distances, exposures, the near / far merge) join as the deployment approaches the point where CORA drives the beamline. PDF reinforces both Methods at a second NSLS-II endstation without coining either, the same earn-the-abstraction discipline XPD follows. Because the defining Methods are not in the catalog, PDF records **no Practice** in the [NSLS-II Site](../nsls2/index.md), exactly as XPD records none; the binding lands when the Method does.
-
-The PDF reduction itself (the azimuthal integration of the detector frames and the Fourier transform of the structure function into the pair distribution function G(r)) is `ComputePort` work, not a beamline Method: the beamline takes the frames, CORA's compute leg turns them into the result.
diff --git a/docs/deployments/six/governance.md b/docs/deployments/six/governance.md
deleted file mode 100644
index 5f6802c6b43..00000000000
--- a/docs/deployments/six/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at SIX, and the trust shape that will gate it. First cut.*
-
-Governance at SIX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-SIX is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. SIX adds hazard classes the hard X-ray fleet does not carry: ultra-high vacuum and the cryostat's cryogens at the sample environment, which an experiment Clearance would carry; those land with the instruments that bring them.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives SIX, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/six/model.md b/docs/deployments/six/model.md
deleted file mode 100644
index 320a595ff63..00000000000
--- a/docs/deployments/six/model.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's SIX content lives, the loose families this first soft X-ray deployment introduced and has since graduated, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at SIX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## New loose families
-
-SIX is CORA's first soft X-ray beamline, a new optics, detector, and sample-environment regime. It introduced three device classes no hard X-ray catalog Family covered. All three have since **graduated**: `GratingMonochromator` became a catalog Family once CSX (NSLS-II 23-ID) earned the soft X-ray PGM, `Manipulator` once ESM (NSLS-II 21-ID) earned the UHV sample manipulator, and `SpectrometerArm` once ESRF ID32 (the RIXS and XES arms) and ID28 (the multi-analyzer arm) earned the dispersive spectrometer arm SIX coined (the Monochromator, SampleManipulator, and RIXSSpectrometer here bind them).
-
-| Family | Presents | What it is | Status |
-| --- | --- | --- | --- |
-| `GratingMonochromator` | Positioner | the soft X-ray plane-grating monochromator (PGM): premirror at a fixed-focus c-value plus an interchangeable grating, no Bragg crystal | graduated (SIX + CSX, `MONO-1`) |
-| `SpectrometerArm` | Positioner | the meters-long energy-dispersive RIXS arm (bridge truss + optics chamber + detector chamber) | graduated (SIX + ID32 RIXS/XES + ID28) |
-| `Manipulator` | Positioner | the UHV cryostat sample manipulator (x/y/z/theta) | graduated (SIX + ESM, `SAMPLE-1`) |
-
-The catalog `Monochromator` is deliberately not stretched to cover the PGM: its note describes a crystal / multilayer Bragg monochromator, and a plane-grating mono has no Bragg crystal, selects energy by grating pitch and translation, and takes its resolution from the exit slit, so `GratingMonochromator` is a distinct Family rather than a settings variant. Likewise `SpectrometerArm` is distinct from the catalog `EnergyDispersiveSpectrometer` (a point Sensor, not a multi-chamber dispersive arm); it presents the `Positioner` Role (an arm that positions a dispersing grating and carries a `Camera` at its focus).
-
-## Deliberately not here yet
-
-- **The RIXS-camera Family question.** The RIXS camera does on-detector single-photon centroiding and isolinear curvature correction, a photon-counting regime distinct from an integrating-frame area detector. It is modelled here as the catalog `Camera` with that behavior carried as a note; whether the photon-counting pipeline warrants its own Family is `RIXS-2`, deferred (a `Camera`-with-settings is the lower-risk first cut).
-
-- **The EPU polarization DOF.** The elliptically-polarizing undulator adds a phase (polarization) axis beyond gap. It binds the catalog `InsertionDevice` with the polarization carried as a setting; whether the EPU phase warrants a distinct family is deferred until a second EPU beamline (`SRC-1`).
-
-- **The legacy end-station PGM.** The profile collection carries a discarded second monochromator instance (`Mono:2` / `espgm`) and a dead `PGMjoe` class; only the live `Mono:1` PGM is modelled.
-
-- **The RIXS Method.** Whether RIXS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
-
-- **The simulated devices and full asset-tree scenarios.** No `test_six_*.py` registers the SIX asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
-
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/six/notes.md b/docs/deployments/six/notes.md
new file mode 100644
index 00000000000..af4d0710c84
--- /dev/null
+++ b/docs/deployments/six/notes.md
@@ -0,0 +1,118 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of SIX is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. SIX's technique is resonant inelastic X-ray scattering, a soft X-ray scattering method new to CORA's imaging-heritage catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
+
+### Resonant inelastic X-ray scattering
+
+RIXS tunes the incident soft X-ray energy to an absorption edge and measures the energy and momentum the sample exchanges with the scattered photon, so the measurement is a spectrum of the emitted light dispersed by the spectrometer arm onto the photon-counting camera.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | the incident energy is set on the [grating monochromator](source.md); the emitted spectrum is dispersed by the [spectrometer arm](detector.md) and recorded on the photon-counting camera; Method not yet in catalog |
+
+It needs the [grating monochromator](source.md) (the incident-energy and resolution chain, exit slit included), the [UHV cryostat sample](sample.md), and the [RIXS spectrometer arm and camera](detector.md). The arm scattering angle selects the momentum transfer.
+
+### Not modelled yet
+
+The concrete acquisition recipes (energy maps, emission-spectrum exposures, the arm-angle and resolution settings) are not written yet; they join as the deployment approaches the point where CORA drives SIX. Whether RIXS enters CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); soft X-ray is a new regime for the fleet (see [Open questions](#open-questions) for the world-facts to confirm first).
+
+## Governance
+
+*Who will act at SIX, and the trust shape that will gate it. First cut.*
+
+Governance at SIX follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+SIX is not yet driven by CORA, so this shape is not yet instantiated. The profile collection exposes only coarse queue-server groups, not the human roster, so the NSLS-II operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md) (`GOV-1`).
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md), not on the beamline, and the beamline links up to them. SIX adds hazard classes the hard X-ray fleet does not carry: ultra-high vacuum and the cryostat's cryogens at the sample environment, which an experiment Clearance would carry; those land with the instruments that bring them.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives SIX, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's SIX content lives, the loose families this first soft X-ray deployment introduced and has since graduated, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at SIX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### New loose families
+
+SIX is CORA's first soft X-ray beamline, a new optics, detector, and sample-environment regime. It introduced three device classes no hard X-ray catalog Family covered. All three have since **graduated**: `GratingMonochromator` became a catalog Family once CSX (NSLS-II 23-ID) earned the soft X-ray PGM, `Manipulator` once ESM (NSLS-II 21-ID) earned the UHV sample manipulator, and `SpectrometerArm` once ESRF ID32 (the RIXS and XES arms) and ID28 (the multi-analyzer arm) earned the dispersive spectrometer arm SIX coined (the Monochromator, SampleManipulator, and RIXSSpectrometer here bind them).
+
+| Family | Presents | What it is | Status |
+| --- | --- | --- | --- |
+| `GratingMonochromator` | Positioner | the soft X-ray plane-grating monochromator (PGM): premirror at a fixed-focus c-value plus an interchangeable grating, no Bragg crystal | graduated (SIX + CSX, `MONO-1`) |
+| `SpectrometerArm` | Positioner | the meters-long energy-dispersive RIXS arm (bridge truss + optics chamber + detector chamber) | graduated (SIX + ID32 RIXS/XES + ID28) |
+| `Manipulator` | Positioner | the UHV cryostat sample manipulator (x/y/z/theta) | graduated (SIX + ESM, `SAMPLE-1`) |
+
+The catalog `Monochromator` is deliberately not stretched to cover the PGM: its note describes a crystal / multilayer Bragg monochromator, and a plane-grating mono has no Bragg crystal, selects energy by grating pitch and translation, and takes its resolution from the exit slit, so `GratingMonochromator` is a distinct Family rather than a settings variant. Likewise `SpectrometerArm` is distinct from the catalog `EnergyDispersiveSpectrometer` (a point Sensor, not a multi-chamber dispersive arm); it presents the `Positioner` Role (an arm that positions a dispersing grating and carries a `Camera` at its focus).
+
+### Deliberately not here yet
+
+- **The RIXS-camera Family question.** The RIXS camera does on-detector single-photon centroiding and isolinear curvature correction, a photon-counting regime distinct from an integrating-frame area detector. It is modelled here as the catalog `Camera` with that behavior carried as a note; whether the photon-counting pipeline warrants its own Family is `RIXS-2`, deferred (a `Camera`-with-settings is the lower-risk first cut).
+
+- **The EPU polarization DOF.** The elliptically-polarizing undulator adds a phase (polarization) axis beyond gap. It binds the catalog `InsertionDevice` with the polarization carried as a setting; whether the EPU phase warrants a distinct family is deferred until a second EPU beamline (`SRC-1`).
+
+- **The legacy end-station PGM.** The profile collection carries a discarded second monochromator instance (`Mono:2` / `espgm`) and a dead `PGMjoe` class; only the live `Mono:1` PGM is modelled.
+
+- **The RIXS Method.** Whether RIXS enters CORA's catalog is an owner decision; the Practice renders unlinked, pending (`TECH-1`).
+
+- **The simulated devices and full asset-tree scenarios.** No `test_six_*.py` registers the SIX asset tree, and no vendor Models are bound. Those land when the design firms and the team approves.
+
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the SIX team to confirm before the model can be trusted.*
+
+SIX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/six-profile-collection](https://github.com/NSLS2/six-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet), including the new loose families). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TOPO-1 | Blocks-build | Does SIX share a canted straight with a sibling beamline, or run off its own undulator in series? | One root Unit Asset `SIX` on its own EPU straight. | The source topology in the [descriptor](index.md). |
+| ENC-1 | Blocks-go-live | Are the PV zones `XF:02IDA/B/C/D` four separate shielded hutches or beam zones within fewer hutches? | Four enclosures, one per zone. | The Enclosure grouping. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the six-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the photon shutters are `XF:02ID-PPS{Sh:FE}` / `XF:02IDA-PPS{PSh}` / `XF:02IDB-PPS{PSh}`. | The Enclosure permit signals. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The EPU (`SR:C02-ID:G1A{EPU:1}`): type, period, and the polarization (phase) model. | One `InsertionDevice` Asset; the phase axis carried as a setting. | The insertion-device spec. |
+| MONO-1 | Blocks-build | The plane-grating monochromator: energy range, the three grating line densities (500 / 1200 / 1800 l/mm), and the c-value (cff) model. | A `GratingMonochromator` Asset (catalog Family) with energy / cff / grating-pitch / premirror-pitch / grating-translation axes. | The monochromator energy and grating model. |
+| OPT-1 | Nice-to-have | The mirrors (M1, M3, M4, M5, M6): coatings, stripes, and the hexapod / bender axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
+| OPT-2 | Nice-to-have | The baffle slits, the exit slit, and the M5 mask: the internal axis maps. | `Slit` / `Aperture` Assets with base PVs; per-blade axes partial. | The slit and aperture axis maps. |
+
+### RIXS endstation
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| RIXS-1 | Blocks-build | The spectrometer-arm geometry: the bridge truss (`BT:1`), the in-arm optics chamber (`3AA:1`), and the detector chamber (`DC:1`): which axis is the arm scattering angle, the dispersion, and the detector distance, and how the arm pivots about the sample chamber. | One `SpectrometerArm` Asset (catalog Family, graduated) with the three chambers' axes; the sample chamber as the pivot. | The spectrometer geometry and whether it composes into an Assembly. |
+| RIXS-2 | Nice-to-have | The RIXS camera (`XF:02ID1-ES{RIXSCam}`): the sensor, the photon-counting / centroiding pipeline, and the curvature correction. | One `Camera` Asset; the centroiding behavior carried as a note. | The detector model and Family decision. |
+| DET-1 | Nice-to-have | The counting scaler, the Femto electrometer, and the camera readout: which channels are I0 versus signal. | `FluxMonitor` Assets plus the `Camera`. | The detector channel map. |
+| DIAG-1 | Nice-to-have | The DIAGON diagnostic (`XF:02IDA-OP{Diag:1`): is it a polarization diagnostic, and what does it report? | One `GenericProbe` Asset (placeholder classification). | The diagnostic classification and Family. |
+
+### Sample environment and supplies
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The UHV cryostat manipulator (`SC:1-Cryo:S1_B`) and the Lakeshore controller: the cryo temperature range, the base pressure, and any load-lock / sample-transfer mechanism. | A `Manipulator` Asset (catalog Family, x/y/z/theta) plus a `TemperatureController`. | The sample-environment model. |
+| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the spectrometer arm, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/six/questions.md b/docs/deployments/six/questions.md
deleted file mode 100644
index 0f6eeba5dfe..00000000000
--- a/docs/deployments/six/questions.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Open questions
-
-*What CORA needs the SIX team to confirm before the model can be trusted.*
-
-SIX was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/six-profile-collection](https://github.com/NSLS2/six-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/*.py` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet), including the new loose families). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TOPO-1 | Blocks-build | Does SIX share a canted straight with a sibling beamline, or run off its own undulator in series? | One root Unit Asset `SIX` on its own EPU straight. | The source topology in the [descriptor](index.md). |
-| ENC-1 | Blocks-go-live | Are the PV zones `XF:02IDA/B/C/D` four separate shielded hutches or beam zones within fewer hutches? | Four enclosures, one per zone. | The Enclosure grouping. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the six-profile-collection current and correct? | The handles in the descriptor are taken from the profile collection and carried confirm. | Verifying each Asset's control handle. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals for the hutches. | Permit leaves to be named; the photon shutters are `XF:02ID-PPS{Sh:FE}` / `XF:02IDA-PPS{PSh}` / `XF:02IDB-PPS{PSh}`. | The Enclosure permit signals. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The EPU (`SR:C02-ID:G1A{EPU:1}`): type, period, and the polarization (phase) model. | One `InsertionDevice` Asset; the phase axis carried as a setting. | The insertion-device spec. |
-| MONO-1 | Blocks-build | The plane-grating monochromator: energy range, the three grating line densities (500 / 1200 / 1800 l/mm), and the c-value (cff) model. | A `GratingMonochromator` Asset (catalog Family) with energy / cff / grating-pitch / premirror-pitch / grating-translation axes. | The monochromator energy and grating model. |
-| OPT-1 | Nice-to-have | The mirrors (M1, M3, M4, M5, M6): coatings, stripes, and the hexapod / bender axis roles. | `Mirror` Assets with the config's PV roots; coatings unconfirmed. | The mirror specs. |
-| OPT-2 | Nice-to-have | The baffle slits, the exit slit, and the M5 mask: the internal axis maps. | `Slit` / `Aperture` Assets with base PVs; per-blade axes partial. | The slit and aperture axis maps. |
-
-## RIXS endstation
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| RIXS-1 | Blocks-build | The spectrometer-arm geometry: the bridge truss (`BT:1`), the in-arm optics chamber (`3AA:1`), and the detector chamber (`DC:1`): which axis is the arm scattering angle, the dispersion, and the detector distance, and how the arm pivots about the sample chamber. | One `SpectrometerArm` Asset (catalog Family, graduated) with the three chambers' axes; the sample chamber as the pivot. | The spectrometer geometry and whether it composes into an Assembly. |
-| RIXS-2 | Nice-to-have | The RIXS camera (`XF:02ID1-ES{RIXSCam}`): the sensor, the photon-counting / centroiding pipeline, and the curvature correction. | One `Camera` Asset; the centroiding behavior carried as a note. | The detector model and Family decision. |
-| DET-1 | Nice-to-have | The counting scaler, the Femto electrometer, and the camera readout: which channels are I0 versus signal. | `FluxMonitor` Assets plus the `Camera`. | The detector channel map. |
-| DIAG-1 | Nice-to-have | The DIAGON diagnostic (`XF:02IDA-OP{Diag:1`): is it a polarization diagnostic, and what does it report? | One `GenericProbe` Asset (placeholder classification). | The diagnostic classification and Family. |
-
-## Sample environment and supplies
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The UHV cryostat manipulator (`SC:1-Cryo:S1_B`) and the Lakeshore controller: the cryo temperature range, the base pressure, and any load-lock / sample-transfer mechanism. | A `Manipulator` Asset (catalog Family, x/y/z/theta) plus a `TemperatureController`. | The sample-environment model. |
-| SUP-1 | Nice-to-have | The vacuum and cryogen supplies the UHV optics, the spectrometer arm, and the cryostat draw on. | Photon beam, cooling water, and vacuum carried in the descriptor. | The Supply records. |
diff --git a/docs/deployments/six/techniques.md b/docs/deployments/six/techniques.md
deleted file mode 100644
index 65604135ffd..00000000000
--- a/docs/deployments/six/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What the modelled part of SIX is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md) is how a facility adapts it. SIX's technique is resonant inelastic X-ray scattering, a soft X-ray scattering method new to CORA's imaging-heritage catalog, so the Method below renders unlinked and is carried pending until a technique enters scope (`TECH-1`).
-
-## Resonant inelastic X-ray scattering
-
-RIXS tunes the incident soft X-ray energy to an absorption edge and measures the energy and momentum the sample exchanges with the scattered photon, so the measurement is a spectrum of the emitted light dispersed by the spectrometer arm onto the photon-counting camera.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Resonant inelastic X-ray scattering | `resonant_inelastic_scattering` | the incident energy is set on the [grating monochromator](source.md); the emitted spectrum is dispersed by the [spectrometer arm](detector.md) and recorded on the photon-counting camera; Method not yet in catalog |
-
-It needs the [grating monochromator](source.md) (the incident-energy and resolution chain, exit slit included), the [UHV cryostat sample](sample.md), and the [RIXS spectrometer arm and camera](detector.md). The arm scattering angle selects the momentum transfer.
-
-## Not modelled yet
-
-The concrete acquisition recipes (energy maps, emission-spectrum exposures, the arm-angle and resolution settings) are not written yet; they join as the deployment approaches the point where CORA drives SIX. Whether RIXS enters CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); soft X-ray is a new regime for the fleet (see [Open questions](questions.md) for the world-facts to confirm first).
diff --git a/docs/deployments/smi/governance.md b/docs/deployments/smi/governance.md
deleted file mode 100644
index 27085c34e89..00000000000
--- a/docs/deployments/smi/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at SMI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SMI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start an acquisition, change the camera length or grazing angle, run an in-situ environment program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## In-situ studies and time series
-
-SMI's soft-matter science often follows a sample as it changes: a film drying under a blade coater, a polymer responding to humidity or a temperature ramp. Those are time series under an in-situ environment program, where CORA's custody and trust shapes earn their keep, holding the gated acquisition while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer such a study (adjust the environment, decide when enough frames are collected), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/smi/model.md b/docs/deployments/smi/model.md
deleted file mode 100644
index 9fee5d591e0..00000000000
--- a/docs/deployments/smi/model.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's SMI content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at SMI |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (12-ID-A optics, 12-ID-C experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
-
-- **No new Family.** SMI is a reuse-and-reinforce deployment, the NSLS-II twin of Diamond i22 (SAXS / WAXS): the Pilatus detectors bind `Camera`, the flux monitor `FluxMonitor`, the sample environment `TemperatureController`, the fluorescence MCA `EnergyDispersiveSpectrometer`, the beamstops `BeamStop`, the mirrors `Mirror`, the monochromator `Monochromator`, the slits `Slit`, the attenuators `Filter`, and the compound-refractive-lens `Transfocator`, which reuses the graduated `Transfocator` catalog Family (a CRL focusing optic, distinct from `Mirror` / `ZonePlate` / `Condenser`, bound at 4-ID, 8-ID, 9-ID, i22, and CHX too); the residual open item is the per-Asset lens material and count (`CRL-1`), which graduation does not resolve.
-- **The graduated `PositionMonitor`.** One device binds the graduated catalog `PositionMonitor` Family that other deployments also share (4-ID, 8-ID, 9-ID): it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset residual that stays open is the beam-position channel map (`DIAG-1`), recorded in the promotion-review register.
-- **No new Capability or Method.** SAXS, WAXS, and GISAXS sit on the deferred scattering Capabilities Diamond i22 left pending (`TECH-1`); SMI reinforces them without coining any, and records no Practice. Grazing incidence is a sample-orientation variant, not a new Capability; simultaneous SAXS+WAXS is coordinated Runs, not a combined technique. The integration and reduction are `ComputePort` work.
-- **The in-situ soft-matter cells.** The humidity cell (driven via Moxa analog IO, relative humidity computed in software) and the blade coater (a SmarAct stage plus a syringe pump) are SMI's specialty; they would each need their own family or Procedure decision, so they are deferred to a named question (`INSITU-1`) rather than modelled.
-- **The in-vacuum WAXS / SAXS chamber.** The active sample chamber (pressure gauges, gate valves, turbo pump, pump / vent automation) is carried as the facility `Vacuum` Supply, the i22 precedent; whether the active chamber enters CORA as its own device is the named question `VAC-1`.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/smi/notes.md b/docs/deployments/smi/notes.md
new file mode 100644
index 00000000000..38e7cd7a615
--- /dev/null
+++ b/docs/deployments/smi/notes.md
@@ -0,0 +1,109 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at SMI: scattering techniques, each a [Catalog](../../catalog/methods.md) Method. SMI is the NSLS-II twin of the Diamond [I22](../i22/notes.md#techniques) (SAXS / WAXS) beamline, and it follows i22's deferral exactly, adding the grazing-incidence variants.*
+
+SMI's techniques are small- and wide-angle scattering, the science domain Diamond i22 brought to CORA. As there, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Mode | Notes |
+| --- | --- | --- |
+| Small-angle scattering (SAXS) | monochromatic, long camera | low-Q on the SAXS Pilatus 2M; the i22 Capability, new Capability pending (TECH-1) |
+| Wide-angle scattering (WAXS) | monochromatic, swing arc | wide-Q on the WAXS Pilatus 900KW; the i22 Capability, new Capability pending (TECH-1) |
+| Simultaneous SAXS+WAXS | both detectors at once | coordinated Runs under one Campaign, the routine mode, not a third technique (TECH-1) |
+| Grazing-incidence (GISAXS / GIWAXS) | shallow incidence, reflected geometry | the same scattering Methods with the sample at a grazing angle and the WAXS arc swung; a sample-orientation variant (TECH-1) |
+
+All the scattering techniques need the [grazing-incidence sample stack](sample.md) and the [SAXS / WAXS detectors](detector.md); the fast shutter gates the exposure.
+
+### Why the Capabilities stay deferred
+
+Diamond i22 opened the question of whether the SAXS and WAXS Capabilities enter CORA's catalog (TECH-1), and `main` deliberately left them pending: SAXS and WAXS do not reduce to the imaging-heritage `tomography` / `acquisition` Capabilities, and a modelling exercise does not mint cross-facility vocabulary until a technique enters a real scope. The device Roles already exist (the Pilatus detectors present the Detector Role, the flux monitor presents Sensor), so what is new is the science Capability, not a device shape. SMI reinforces the case for both at a second facility without coining either, the same earn-the-abstraction discipline the deferred `scanning` (HXN), `energy_scan` (BMM), and powder / total-scattering (XPD) Capabilities follow.
+
+Grazing incidence (GISAXS / GIWAXS) is the genuinely new wrinkle SMI adds over i22, but it is a sample-orientation variant of the same scattering Capability (the sample sits at a shallow angle, the WAXS arc swings), not a new Capability of its own. Simultaneous SAXS+WAXS is coordinated Runs under one Campaign over a shared trigger, the same way 7-BM and i22 model parallel detector reads, not a combined technique. Because the defining Capabilities are not in the catalog, SMI records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); the binding lands when the Capability does.
+
+The azimuthal integration and reduction (turning the 2D scattering frames into I(Q) curves and GISAXS maps) are `ComputePort` work, not beamline Methods.
+
+## Governance
+
+*Who may act at SMI and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SMI beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start an acquisition, change the camera length or grazing angle, run an in-situ environment program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### In-situ studies and time series
+
+SMI's soft-matter science often follows a sample as it changes: a film drying under a blade coater, a polymer responding to humidity or a temperature ramp. Those are time series under an in-situ environment program, where CORA's custody and trust shapes earn their keep, holding the gated acquisition while the trust boundary bounds what may change mid-series and who may intervene. If an autonomous Agent were added to steer such a study (adjust the environment, decide when enough frames are collected), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's SMI content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at SMI |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (12-ID-A optics, 12-ID-C experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
+
+- **No new Family.** SMI is a reuse-and-reinforce deployment, the NSLS-II twin of Diamond i22 (SAXS / WAXS): the Pilatus detectors bind `Camera`, the flux monitor `FluxMonitor`, the sample environment `TemperatureController`, the fluorescence MCA `EnergyDispersiveSpectrometer`, the beamstops `BeamStop`, the mirrors `Mirror`, the monochromator `Monochromator`, the slits `Slit`, the attenuators `Filter`, and the compound-refractive-lens `Transfocator`, which reuses the graduated `Transfocator` catalog Family (a CRL focusing optic, distinct from `Mirror` / `ZonePlate` / `Condenser`, bound at 4-ID, 8-ID, 9-ID, i22, and CHX too); the residual open item is the per-Asset lens material and count (`CRL-1`), which graduation does not resolve.
+- **The graduated `PositionMonitor`.** One device binds the graduated catalog `PositionMonitor` Family that other deployments also share (4-ID, 8-ID, 9-ID): it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset residual that stays open is the beam-position channel map (`DIAG-1`), recorded in the promotion-review register.
+- **No new Capability or Method.** SAXS, WAXS, and GISAXS sit on the deferred scattering Capabilities Diamond i22 left pending (`TECH-1`); SMI reinforces them without coining any, and records no Practice. Grazing incidence is a sample-orientation variant, not a new Capability; simultaneous SAXS+WAXS is coordinated Runs, not a combined technique. The integration and reduction are `ComputePort` work.
+- **The in-situ soft-matter cells.** The humidity cell (driven via Moxa analog IO, relative humidity computed in software) and the blade coater (a SmarAct stage plus a syringe pump) are SMI's specialty; they would each need their own family or Procedure decision, so they are deferred to a named question (`INSITU-1`) rather than modelled.
+- **The in-vacuum WAXS / SAXS chamber.** The active sample chamber (pressure gauges, gate valves, turbo pump, pump / vent automation) is carried as the facility `Vacuum` Supply, the i22 precedent; whether the active chamber enters CORA as its own device is the named question `VAC-1`.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the SMI team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/smi-profile-collection`](https://github.com/NSLS2/smi-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector and in-situ-cell configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The in-vacuum undulator period, gap range, and harmonic usage. The device (`SR:C12-ID:G1{IVU:1}`) is confirmed; working gap range is about 6200-15100. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the front-end photon shutter (`XF:12IDA-PPS:2{PSh}`) is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The double-crystal monochromator energy range (the crystal is Si(111) per the source energy math, on bare motor records `XF:12ID:m65`-`m68`, driven by the coupled energy pseudopositioner). | One Monochromator Asset, Si(111) recorded, range blank. | The Monochromator settings. |
+| CRL-1 | Blocks-go-live | The transfocator (`XF:12IDC-OP:2{Lens:CRL}`) lens material and count (twelve elements). The cross-deployment abstraction is resolved: the compound refractive lens reuses the graduated `Transfocator` catalog Family (a CRL focusing optic), bound at 4-ID, 8-ID, 9-ID, i22, and CHX too; only the per-Asset lens spec is still open. | The graduated `Transfocator` Family is bound; lens material and count blank. | The transfocator lens specification. |
+| ENERGY-1 | Nice-to-have | Does SMI ever scan energy as the measurement, or is it always fixed-energy per experiment? | Fixed-energy; energy_scan not modelled. | The energy Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The full HUB sample-stack axis set (x / y / z / theta / phi / chi) and the SmarAct piezo, and whether the grazing-incidence orientation axes warrant a `Goniometer` plus an Assembly. | A `LinearStage` sample stack, orientation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
+| DET-1 | Blocks-go-live | Which Pilatus detectors are live (the SAXS 2M, the WAXS 900KW) versus the retired set (a 1M, a 300KW), and the SAXS camera-length range. | 2M (SAXS) and 900KW (WAXS) live; all Cameras; camera-length range blank. | The detector roster and Q-range. |
+| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live (the Linkam thermal / tensile stages, the LakeShore controller)? | One `TemperatureController` Asset (the Linkam); the others noted. | The sample-environment Assets. |
+| INSITU-1 | Nice-to-have | The in-situ soft-matter cells: the humidity cell (driven via Moxa analog IO, no dedicated PV) and the blade coater (a SmarAct stage plus a syringe pump). How does CORA model these in-situ environments? | Deferred; they would need their own family / Procedure decisions when they land. | The in-situ cell Assets and Procedures. |
+| VAC-1 | Nice-to-have | The WAXS / SAXS in-vacuum sample chamber (`Sample_Chamber`: pressure gauges, gate valves, a turbo pump, and pump / vent automation, used to set the in-vacuum vs in-air measurement mode). Does the active chamber enter CORA as a device, or stay a facility Supply? | Vacuum carried as a facility Supply (the i22 precedent); the active chamber deferred. | The vacuum-chamber Asset boundary. |
+| DIAG-1 | Nice-to-have | The flux-monitor and beam-position channel maps; the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only the per-Asset channel map stays open. | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor and PositionMonitor channel-map bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CAM-1 | Nice-to-have | Which beam-viewing cameras (the SAM / HEX sample cameras, the FOE FS / WBStop / VFM cameras) are live. | The on-axis SAM camera modelled; others noted. | The beam-viewing camera set. |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs (SmarAct MCS, MDrive, Thorlabs are named). | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the SAXS / WAXS / GISAXS Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i22 opened. Simultaneous SAXS+WAXS would be coordinated Runs, not a new technique. | Capabilities deferred (rendered unlinked), no Practice recorded. | The scattering Capability scope. |
diff --git a/docs/deployments/smi/questions.md b/docs/deployments/smi/questions.md
deleted file mode 100644
index b135e79413f..00000000000
--- a/docs/deployments/smi/questions.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Open questions
-
-*What CORA needs the SMI team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/smi-profile-collection`](https://github.com/NSLS2/smi-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector and in-situ-cell configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The in-vacuum undulator period, gap range, and harmonic usage. The device (`SR:C12-ID:G1{IVU:1}`) is confirmed; working gap range is about 6200-15100. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the front-end photon shutter (`XF:12IDA-PPS:2{PSh}`) is in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The double-crystal monochromator energy range (the crystal is Si(111) per the source energy math, on bare motor records `XF:12ID:m65`-`m68`, driven by the coupled energy pseudopositioner). | One Monochromator Asset, Si(111) recorded, range blank. | The Monochromator settings. |
-| CRL-1 | Blocks-go-live | The transfocator (`XF:12IDC-OP:2{Lens:CRL}`) lens material and count (twelve elements). The cross-deployment abstraction is resolved: the compound refractive lens reuses the graduated `Transfocator` catalog Family (a CRL focusing optic), bound at 4-ID, 8-ID, 9-ID, i22, and CHX too; only the per-Asset lens spec is still open. | The graduated `Transfocator` Family is bound; lens material and count blank. | The transfocator lens specification. |
-| ENERGY-1 | Nice-to-have | Does SMI ever scan energy as the measurement, or is it always fixed-energy per experiment? | Fixed-energy; energy_scan not modelled. | The energy Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The full HUB sample-stack axis set (x / y / z / theta / phi / chi) and the SmarAct piezo, and whether the grazing-incidence orientation axes warrant a `Goniometer` plus an Assembly. | A `LinearStage` sample stack, orientation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
-| DET-1 | Blocks-go-live | Which Pilatus detectors are live (the SAXS 2M, the WAXS 900KW) versus the retired set (a 1M, a 300KW), and the SAXS camera-length range. | 2M (SAXS) and 900KW (WAXS) live; all Cameras; camera-length range blank. | The detector roster and Q-range. |
-| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live (the Linkam thermal / tensile stages, the LakeShore controller)? | One `TemperatureController` Asset (the Linkam); the others noted. | The sample-environment Assets. |
-| INSITU-1 | Nice-to-have | The in-situ soft-matter cells: the humidity cell (driven via Moxa analog IO, no dedicated PV) and the blade coater (a SmarAct stage plus a syringe pump). How does CORA model these in-situ environments? | Deferred; they would need their own family / Procedure decisions when they land. | The in-situ cell Assets and Procedures. |
-| VAC-1 | Nice-to-have | The WAXS / SAXS in-vacuum sample chamber (`Sample_Chamber`: pressure gauges, gate valves, a turbo pump, and pump / vent automation, used to set the in-vacuum vs in-air measurement mode). Does the active chamber enter CORA as a device, or stay a facility Supply? | Vacuum carried as a facility Supply (the i22 precedent); the active chamber deferred. | The vacuum-chamber Asset boundary. |
-| DIAG-1 | Nice-to-have | The flux-monitor and beam-position channel maps; the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only the per-Asset channel map stays open. | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor and PositionMonitor channel-map bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CAM-1 | Nice-to-have | Which beam-viewing cameras (the SAM / HEX sample cameras, the FOE FS / WBStop / VFM cameras) are live. | The on-axis SAM camera modelled; others noted. | The beam-viewing camera set. |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs (SmarAct MCS, MDrive, Thorlabs are named). | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the SAXS / WAXS / GISAXS Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i22 opened. Simultaneous SAXS+WAXS would be coordinated Runs, not a new technique. | Capabilities deferred (rendered unlinked), no Practice recorded. | The scattering Capability scope. |
diff --git a/docs/deployments/smi/techniques.md b/docs/deployments/smi/techniques.md
deleted file mode 100644
index 4ee72c4f755..00000000000
--- a/docs/deployments/smi/techniques.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Techniques
-
-*What CORA would run at SMI: scattering techniques, each a [Catalog](../../catalog/methods.md) Method. SMI is the NSLS-II twin of the Diamond [I22](../i22/techniques.md) (SAXS / WAXS) beamline, and it follows i22's deferral exactly, adding the grazing-incidence variants.*
-
-SMI's techniques are small- and wide-angle scattering, the science domain Diamond i22 brought to CORA. As there, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Mode | Notes |
-| --- | --- | --- |
-| Small-angle scattering (SAXS) | monochromatic, long camera | low-Q on the SAXS Pilatus 2M; the i22 Capability, new Capability pending (TECH-1) |
-| Wide-angle scattering (WAXS) | monochromatic, swing arc | wide-Q on the WAXS Pilatus 900KW; the i22 Capability, new Capability pending (TECH-1) |
-| Simultaneous SAXS+WAXS | both detectors at once | coordinated Runs under one Campaign, the routine mode, not a third technique (TECH-1) |
-| Grazing-incidence (GISAXS / GIWAXS) | shallow incidence, reflected geometry | the same scattering Methods with the sample at a grazing angle and the WAXS arc swung; a sample-orientation variant (TECH-1) |
-
-All the scattering techniques need the [grazing-incidence sample stack](sample.md) and the [SAXS / WAXS detectors](detector.md); the fast shutter gates the exposure.
-
-## Why the Capabilities stay deferred
-
-Diamond i22 opened the question of whether the SAXS and WAXS Capabilities enter CORA's catalog (TECH-1), and `main` deliberately left them pending: SAXS and WAXS do not reduce to the imaging-heritage `tomography` / `acquisition` Capabilities, and a modelling exercise does not mint cross-facility vocabulary until a technique enters a real scope. The device Roles already exist (the Pilatus detectors present the Detector Role, the flux monitor presents Sensor), so what is new is the science Capability, not a device shape. SMI reinforces the case for both at a second facility without coining either, the same earn-the-abstraction discipline the deferred `scanning` (HXN), `energy_scan` (BMM), and powder / total-scattering (XPD) Capabilities follow.
-
-Grazing incidence (GISAXS / GIWAXS) is the genuinely new wrinkle SMI adds over i22, but it is a sample-orientation variant of the same scattering Capability (the sample sits at a shallow angle, the WAXS arc swings), not a new Capability of its own. Simultaneous SAXS+WAXS is coordinated Runs under one Campaign over a shared trigger, the same way 7-BM and i22 model parallel detector reads, not a combined technique. Because the defining Capabilities are not in the catalog, SMI records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); the binding lands when the Capability does.
-
-The azimuthal integration and reduction (turning the 2D scattering frames into I(Q) curves and GISAXS maps) are `ComputePort` work, not beamline Methods.
diff --git a/docs/deployments/srx/governance.md b/docs/deployments/srx/governance.md
deleted file mode 100644
index af9dc6071c5..00000000000
--- a/docs/deployments/srx/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at SRX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SRX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a scan, switch technique, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Multi-technique and agents
-
-SRX's breadth (a user may map, then scan an edge, then take a tomogram in one beamtime) is a place where an autonomous Agent could choose the next technique or region. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each choice would be a [Decision](../../architecture/modules/decision/index.md). SRX also carries an auto-alignment routine in source; conducted by CORA, that is the engine's, with any agent-proposed corrections recorded as Decisions. None is declared yet.
diff --git a/docs/deployments/srx/model.md b/docs/deployments/srx/model.md
deleted file mode 100644
index f07eb3930ed..00000000000
--- a/docs/deployments/srx/model.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's SRX content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at SRX |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) (5-ID-A optics, 5-ID-D nano endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring HXN, BMM, and the Diamond beamlines. Left out on purpose:
-
-- **No new Family or Capability.** SRX is the reuse-and-reinforce deployment: every device binds an existing catalog Family (`EnergyDispersiveSpectrometer`, `FluxMonitor`, `TemperatureController` among the recently-graduated ones), and the techniques compose from existing Capabilities. The deferred `scanning` (HXN) and `energy_scan` (BMM) Capabilities are reinforced, not coined, here.
-- **The micro endstation.** SRX has a micro endstation (05IDB) alongside the nano (KB) endstation modelled here; it is noted and deferred (ENDSTATION-1), the way 32-ID modelled one of several instruments.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/srx/notes.md b/docs/deployments/srx/notes.md
new file mode 100644
index 00000000000..177235d089b
--- /dev/null
+++ b/docs/deployments/srx/notes.md
@@ -0,0 +1,96 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at SRX, several techniques on one beamline, each a [Catalog](../../catalog/methods.md) Method bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). SRX exercises the multi-Capability-per-beamline shape.*
+
+SRX is a microprobe that does much: it maps elements, scans absorption edges, reconstructs 3D element distributions, takes diffraction, and images. The point for CORA is that all of this reuses Capabilities and Families the fleet already has, the techniques compose from existing parts rather than forcing new vocabulary.
+
+| SRX technique | CORA expression | Reuse note |
+| --- | --- | --- |
+| Scanning XRF mapping | a raster reading the `EnergyDispersiveSpectrometer` | the HXN scanning shape; `scanning` Capability deferred (ENERGY-1 cohort) |
+| XANES | an energy sweep over the `EnergyAxis` | the BMM energy-scan question; `energy_scan` deferred |
+| XRF-tomography | [`tomography`](../../catalog/methods.md), raster x rotation | reuse; XRF maps at each angle |
+| Diffraction | a raster/exposure reading a `Camera` pixel detector | reuse; the technique is the detector choice |
+| Full-field imaging | the PCO `Camera` | reuse; the FXI/2-BM imaging shape |
+| Alignment | beam, KB, and slit tuning | reuse [`alignment`](../../catalog/methods.md) |
+
+### The multi-Capability-per-beamline shape
+
+SRX is the first deployment where one beamline carries several distinct techniques at once. In CORA terms, one Unit Asset presents the equipment for multiple Capabilities (imaging, scanning XRF, energy-scan spectroscopy, tomography, diffraction), and a measurement selects the Capability plus the detector(s) it needs from the shared set. Nothing here is new vocabulary: it reinforces that the Capability/Method layer composes, the same `tomography` Method that serves 2-BM serves SRX's XRF-tomography (with a different detector in the slot), and the `EnergyDispersiveSpectrometer` that BMM uses for transmission-reference fluorescence serves SRX's XRF mapping.
+
+Two Capabilities stay deferred, exactly as their originating beamlines left them: `scanning` (HXN) and `energy_scan` (BMM). SRX reinforces the case for both without coining either, per the design-phase discipline. The reconstruction/fitting legs (XRF fitting, tomographic reconstruction) are `ComputePort` work, not beamline Methods.
+
+## Governance
+
+*Who may act at SRX and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SRX beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a scan, switch technique, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Multi-technique and agents
+
+SRX's breadth (a user may map, then scan an edge, then take a tomogram in one beamtime) is a place where an autonomous Agent could choose the next technique or region. If such an agent were added, it would be a facility principal scoped at the Site, governed by the same trust boundary, and each choice would be a [Decision](../../architecture/modules/decision/index.md). SRX also carries an auto-alignment routine in source; conducted by CORA, that is the engine's, with any agent-proposed corrections recorded as Decisions. None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's SRX content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at SRX |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) (5-ID-A optics, 5-ID-D nano endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring HXN, BMM, and the Diamond beamlines. Left out on purpose:
+
+- **No new Family or Capability.** SRX is the reuse-and-reinforce deployment: every device binds an existing catalog Family (`EnergyDispersiveSpectrometer`, `FluxMonitor`, `TemperatureController` among the recently-graduated ones), and the techniques compose from existing Capabilities. The deferred `scanning` (HXN) and `energy_scan` (BMM) Capabilities are reinforced, not coined, here.
+- **The micro endstation.** SRX has a micro endstation (05IDB) alongside the nano (KB) endstation modelled here; it is noted and deferred (ENDSTATION-1), the way 32-ID modelled one of several instruments.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the SRX team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/srx-profile-collection`](https://github.com/NSLS2/srx-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector/endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | IVU21 undulator period, gap range, and harmonic usage. The device (`SR:C5-ID:G1{IVU21:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:05ID-PPS{Sh:WB}`, `05IDA-PPS:1{PSh:2}`, `05IDB-PPS:1{PSh:4}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The hutch layout: which PV zones (05IDA optics, 05IDB micro endstation, 05IDD nano endstation) are distinct enclosures? | Two enclosures, optics + experiment (nano). | The Enclosure set and roles. |
+
+### Optics and sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The HDCM crystal cut and energy range. | High-heat-load DCM, range blank. | The Monochromator settings. |
+| STAGE-1 | Blocks-go-live | The XRF-tomography sample rotation hardware, encoder resolution, and max speed. | A RotaryStage, specs blank. | The SampleRotary settings. |
+| ENDSTATION-1 | Nice-to-have | The micro endstation (05IDB): is it a distinct sample stack from the nano endstation modelled here, and how are the two selected? | The nano (KB) endstation is modelled; the micro endstation is noted, deferred. | The micro-endstation Assets. |
+
+### Detectors and controls
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The Xspress3 fluorescence detector element count and vendor. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; specs blank. | The detector Model and element count. |
+| CAM-1 | Blocks-go-live | Which pixel/area detectors are live vs legacy? Source has Merlin, Dexela, Eiger 1M, a PCO imaging camera, and legacy detectors. | Merlin/Dexela/Eiger/PCO modelled as Cameras; legacy excluded. | The detector roster and per-technique detector slot. |
+| DIAG-1 | Nice-to-have | The scaler / ion-chamber flux channel map (which channel is I0). | Read-only flux counters (`FluxMonitor`), channel map blank. | The FluxCounter bindings. |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| ENERGY-1 | Nice-to-have | Does SRX's XANES sweep warrant the `energy_scan` Capability the catalog anticipates (shared with BMM), or stay under `characterization`? | XANES mapped to existing Capabilities; energy_scan deferred (the BMM question). | The spectroscopy Capability decision. |
diff --git a/docs/deployments/srx/questions.md b/docs/deployments/srx/questions.md
deleted file mode 100644
index 6a7e5bb0fe7..00000000000
--- a/docs/deployments/srx/questions.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Open questions
-
-*What CORA needs the SRX team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/srx-profile-collection`](https://github.com/NSLS2/srx-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the detector/endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | IVU21 undulator period, gap range, and harmonic usage. The device (`SR:C5-ID:G1{IVU21:1}`) is confirmed. | An in-vacuum undulator, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:05ID-PPS{Sh:WB}`, `05IDA-PPS:1{PSh:2}`, `05IDB-PPS:1{PSh:4}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The hutch layout: which PV zones (05IDA optics, 05IDB micro endstation, 05IDD nano endstation) are distinct enclosures? | Two enclosures, optics + experiment (nano). | The Enclosure set and roles. |
-
-## Optics and sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The HDCM crystal cut and energy range. | High-heat-load DCM, range blank. | The Monochromator settings. |
-| STAGE-1 | Blocks-go-live | The XRF-tomography sample rotation hardware, encoder resolution, and max speed. | A RotaryStage, specs blank. | The SampleRotary settings. |
-| ENDSTATION-1 | Nice-to-have | The micro endstation (05IDB): is it a distinct sample stack from the nano endstation modelled here, and how are the two selected? | The nano (KB) endstation is modelled; the micro endstation is noted, deferred. | The micro-endstation Assets. |
-
-## Detectors and controls
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The Xspress3 fluorescence detector element count and vendor. | One `EnergyDispersiveSpectrometer` Asset presenting the Sensor Role; specs blank. | The detector Model and element count. |
-| CAM-1 | Blocks-go-live | Which pixel/area detectors are live vs legacy? Source has Merlin, Dexela, Eiger 1M, a PCO imaging camera, and legacy detectors. | Merlin/Dexela/Eiger/PCO modelled as Cameras; legacy excluded. | The detector roster and per-technique detector slot. |
-| DIAG-1 | Nice-to-have | The scaler / ion-chamber flux channel map (which channel is I0). | Read-only flux counters (`FluxMonitor`), channel map blank. | The FluxCounter bindings. |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| ENERGY-1 | Nice-to-have | Does SRX's XANES sweep warrant the `energy_scan` Capability the catalog anticipates (shared with BMM), or stay under `characterization`? | XANES mapped to existing Capabilities; energy_scan deferred (the BMM question). | The spectroscopy Capability decision. |
diff --git a/docs/deployments/srx/techniques.md b/docs/deployments/srx/techniques.md
deleted file mode 100644
index 3af67606c46..00000000000
--- a/docs/deployments/srx/techniques.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Techniques
-
-*What CORA would run at SRX, several techniques on one beamline, each a [Catalog](../../catalog/methods.md) Method bound through an NSLS-II [Practice](../nsls2/index.md#the-techniques-adapted-here). SRX exercises the multi-Capability-per-beamline shape.*
-
-SRX is a microprobe that does much: it maps elements, scans absorption edges, reconstructs 3D element distributions, takes diffraction, and images. The point for CORA is that all of this reuses Capabilities and Families the fleet already has, the techniques compose from existing parts rather than forcing new vocabulary.
-
-| SRX technique | CORA expression | Reuse note |
-| --- | --- | --- |
-| Scanning XRF mapping | a raster reading the `EnergyDispersiveSpectrometer` | the HXN scanning shape; `scanning` Capability deferred (ENERGY-1 cohort) |
-| XANES | an energy sweep over the `EnergyAxis` | the BMM energy-scan question; `energy_scan` deferred |
-| XRF-tomography | [`tomography`](../../catalog/methods.md), raster x rotation | reuse; XRF maps at each angle |
-| Diffraction | a raster/exposure reading a `Camera` pixel detector | reuse; the technique is the detector choice |
-| Full-field imaging | the PCO `Camera` | reuse; the FXI/2-BM imaging shape |
-| Alignment | beam, KB, and slit tuning | reuse [`alignment`](../../catalog/methods.md) |
-
-## The multi-Capability-per-beamline shape
-
-SRX is the first deployment where one beamline carries several distinct techniques at once. In CORA terms, one Unit Asset presents the equipment for multiple Capabilities (imaging, scanning XRF, energy-scan spectroscopy, tomography, diffraction), and a measurement selects the Capability plus the detector(s) it needs from the shared set. Nothing here is new vocabulary: it reinforces that the Capability/Method layer composes, the same `tomography` Method that serves 2-BM serves SRX's XRF-tomography (with a different detector in the slot), and the `EnergyDispersiveSpectrometer` that BMM uses for transmission-reference fluorescence serves SRX's XRF mapping.
-
-Two Capabilities stay deferred, exactly as their originating beamlines left them: `scanning` (HXN) and `energy_scan` (BMM). SRX reinforces the case for both without coining either, per the design-phase discipline. The reconstruction/fitting legs (XRF fitting, tomographic reconstruction) are `ComputePort` work, not beamline Methods.
diff --git a/docs/deployments/sst/governance.md b/docs/deployments/sst/governance.md
deleted file mode 100644
index be8fb2b857d..00000000000
--- a/docs/deployments/sst/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at SST and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SST beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may select the active branch and endstation, start an acquisition, sweep energy, run an in-situ program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Two branches under one custody
-
-SST's defining governance wrinkle is that two branches and several endstations share one sector and one beamtime allocation. CORA's Campaign and Trust shapes are where that resolves: the endstation in control is a beamline-state fact the trust boundary reads, so a command valid for the soft RSoXS endstation is not automatically valid when the tender HAXPES endstation is live. If an autonomous Agent were added to drive an endstation, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/sst/model.md b/docs/deployments/sst/model.md
deleted file mode 100644
index ad7fdb3268e..00000000000
--- a/docs/deployments/sst/model.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's SST content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at SST |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (7-ID-A optics, SST-1 soft, SST-2 tender) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
-
-- **No new Family.** SST is a reuse-and-reinforce deployment at Site scale: the soft PGM binds `GratingMonochromator` (graduated across SIX / CSX / ESM, a fourth sighting), the tender DCM `Monochromator`, the sample manipulators `Manipulator` (graduated by ESM, bound twice more here), the soft-scattering CCD and viewing cameras `Camera`, the microcalorimeter `EnergyDispersiveSpectrometer`, the flux channels `FluxMonitor`, the thermal stage `TemperatureController`, the mirrors `Mirror`, the slits `Slit`, the shutters `Shutter`, the beamstop `BeamStop`.
-- **The `ElectronAnalyzer` graduation.** The HAXPES Scienta SES hemispherical analyzer binds the `ElectronAnalyzer` family NSLS-II ESM introduced. SST-HAXPES is the **second** sighting (the same Scienta SES type), so it earned the rule-of-three, the way `GratingMonochromator` (CSX) and `Manipulator` (ESM) graduated at their second sighting. The abstraction is settled (a hemispherical electron analyzer is a distinct, recurring photon-in / electron-out device, not a photon detector), so it GRADUATED into the catalog (`ARPES-1`); ESM's references were swept loose to graduated alongside.
-- **The graduated `PositionMonitor`.** The beam-position diagnostics bind the graduated catalog `PositionMonitor` Family that several deployments share: it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset beam-position channel map stays open (`DIAG-1`).
-- **No new Capability or Method.** Soft-scattering, absorption, and photoemission sit on deferred / pending Capabilities (TECH-1, ENERGY-1, the ESM `angle_resolved_photoemission`); SST reinforces all three without coining any, and records no Practice. The per-technique reduction is `ComputePort` work.
-- **The deferred endstations and in-situ accessories.** The NEXAFS endstation detail (drain-current / partial-electron-yield channels), the UCAL microcalorimeter ADR cryostat, the VPPEM microscope, the HAXPES flood gun and source-measure unit, and the RSoXS syringe pump are named in a question (`INSITU-1`); none fits an existing family cleanly, so they are deferred rather than modelled. SST models the RSoXS, HAXPES, and NEXAFS-microcalorimeter legs as the representative endstations, the way SRX modelled one of its endstations and 32-ID one of several instruments.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/sst/notes.md b/docs/deployments/sst/notes.md
new file mode 100644
index 00000000000..257f04ee97c
--- /dev/null
+++ b/docs/deployments/sst/notes.md
@@ -0,0 +1,104 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at SST: soft-scattering, absorption, and photoemission techniques, each a [Catalog](../../catalog/methods.md) Method. SST spans three technique families on two branches, and follows the deferral discipline of the beamlines that brought each to CORA.*
+
+SST's techniques are new-domain science (soft-X-ray scattering, absorption, photoemission), the families Diamond and the earlier NSLS-II soft-X-ray beamlines brought to CORA. The Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Branch / mode | Notes |
+| --- | --- | --- |
+| Resonant soft X-ray scattering (RSoXS) | soft, monochromatic | scattering pattern on the Greateyes CCD; the i22 / CSX scattering family, new Capability pending (TECH-1) |
+| NEXAFS absorption | soft, energy sweep | drain current / partial electron yield / microcalorimeter fluorescence over an energy scan; the BMM energy-scan question (ENERGY-1, TECH-1) |
+| HAXPES photoemission | tender, fixed energy | photoelectron spectra on the hemispherical analyzer; the ESM photoemission family, new Capability pending (TECH-1) |
+
+All three need the per-endstation [sample manipulator](sample.md) and [detector](detector.md); the fast shutter gates the exposure, and the endstation in control selects the branch.
+
+### Why the Capabilities stay deferred
+
+Each of SST's three technique families sits on a Capability the catalog does not yet carry, and the discipline is the same one the originating beamlines applied: soft-X-ray scattering follows Diamond i22 and NSLS-II CSX (the scattering Capabilities are pending, TECH-1); NEXAFS absorption follows BMM (energy-scan-as-the-measurement, deferred at ENERGY-1); photoemission follows NSLS-II ESM (the `angle_resolved_photoemission` Method ESM coined is pending, and HAXPES is the hard / tender photoemission companion). The device Roles already exist (the CCD presents Detector, the manipulators present Positioner, the analyzer and microcalorimeter are the energy-resolving detectors); what is new is the science Capability, not a device shape. SST reinforces all three at one more, larger instrument without coining any, so it records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
+
+The per-technique reduction (scattering reduction, photoemission spectra, NEXAFS spectra) is `ComputePort` work, not beamline Methods.
+
+## Governance
+
+*Who may act at SST and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An SST beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may select the active branch and endstation, start an acquisition, sweep energy, run an in-situ program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Two branches under one custody
+
+SST's defining governance wrinkle is that two branches and several endstations share one sector and one beamtime allocation. CORA's Campaign and Trust shapes are where that resolves: the endstation in control is a beamline-state fact the trust boundary reads, so a command valid for the soft RSoXS endstation is not automatically valid when the tender HAXPES endstation is live. If an autonomous Agent were added to drive an endstation, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's SST content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at SST |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (7-ID-A optics, SST-1 soft, SST-2 tender) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
+
+- **No new Family.** SST is a reuse-and-reinforce deployment at Site scale: the soft PGM binds `GratingMonochromator` (graduated across SIX / CSX / ESM, a fourth sighting), the tender DCM `Monochromator`, the sample manipulators `Manipulator` (graduated by ESM, bound twice more here), the soft-scattering CCD and viewing cameras `Camera`, the microcalorimeter `EnergyDispersiveSpectrometer`, the flux channels `FluxMonitor`, the thermal stage `TemperatureController`, the mirrors `Mirror`, the slits `Slit`, the shutters `Shutter`, the beamstop `BeamStop`.
+- **The `ElectronAnalyzer` graduation.** The HAXPES Scienta SES hemispherical analyzer binds the `ElectronAnalyzer` family NSLS-II ESM introduced. SST-HAXPES is the **second** sighting (the same Scienta SES type), so it earned the rule-of-three, the way `GratingMonochromator` (CSX) and `Manipulator` (ESM) graduated at their second sighting. The abstraction is settled (a hemispherical electron analyzer is a distinct, recurring photon-in / electron-out device, not a photon detector), so it GRADUATED into the catalog (`ARPES-1`); ESM's references were swept loose to graduated alongside.
+- **The graduated `PositionMonitor`.** The beam-position diagnostics bind the graduated catalog `PositionMonitor` Family that several deployments share: it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset beam-position channel map stays open (`DIAG-1`).
+- **No new Capability or Method.** Soft-scattering, absorption, and photoemission sit on deferred / pending Capabilities (TECH-1, ENERGY-1, the ESM `angle_resolved_photoemission`); SST reinforces all three without coining any, and records no Practice. The per-technique reduction is `ComputePort` work.
+- **The deferred endstations and in-situ accessories.** The NEXAFS endstation detail (drain-current / partial-electron-yield channels), the UCAL microcalorimeter ADR cryostat, the VPPEM microscope, the HAXPES flood gun and source-measure unit, and the RSoXS syringe pump are named in a question (`INSITU-1`); none fits an existing family cleanly, so they are deferred rather than modelled. SST models the RSoXS, HAXPES, and NEXAFS-microcalorimeter legs as the representative endstations, the way SRX modelled one of its endstations and 32-ID one of several instruments.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the SST team to confirm. This model is reverse-engineered from public open source (the `NSLS2/sst-*-profile-collection` endstation repos and the shared `NSLS-II-SST/sst-base` package): the EPICS PVs are read from the TOML device manifests and the sst-base device classes, but vendor identities, physical positions, and the per-endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The two undulator periods and gap / phase ranges (soft EPU60, tender U42). The devices (`SR:C07-ID:G1A{SST1:1}`, `{SST2:1}`) are confirmed from the sst-base energy classes; soft range about 71-2250 eV. | Two insertion devices, identity-only. | The InsertionDevice settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:07ID-PPS{Sh:FE}`, `XF:07IDA-PPS{PSh:n}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The branch-to-hutch mapping and the physical hutch names / numbering (not in source): which endstations (RSoXS, NEXAFS on the soft SST-1 branch; HAXPES on the tender SST-2 branch; plus UCAL, VPPEM) sit in which enclosures? The PV zone numbers (07ID1 / 07ID2 / 07ID6) do not map one-to-one to a branch. | An optics hutch plus a soft (SST-1) and a tender (SST-2) experiment enclosure. | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The soft PGM grating set and the tender DCM crystal cut and ranges. Both monochromators (`Mono:PGM1`, `Mono:DCM1`) are in source. | One GratingMonochromator and one Monochromator Asset, settings blank. | The Monochromator settings. |
+| ENERGY-1 | Nice-to-have | Is energy scanned as the measurement (NEXAFS absorption sweeps the soft PGM across an edge), warranting the energy-scan Capability the catalog anticipates? | NEXAFS mapped to deferred Capabilities; energy-scan deferred (the BMM question). | The spectroscopy Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ARPES-1 | Blocks-go-live | The HAXPES Scienta SES hemispherical analyzer model, lens modes, and pass-energy / kinetic-energy controls. | An `ElectronAnalyzer` Asset (catalog Family, graduated at this 2nd sighting after ESM) presenting the Detector Role. | The analyzer model. |
+| DET-1 | Blocks-go-live | Which detectors are live per endstation: the RSoXS Greateyes WAXS CCD (a second SAXS-arm CCD is commented out), the HAXPES analyzer, the NEXAFS microcalorimeter and drain-current / partial-electron-yield channels. | The WAXS CCD, the analyzer, and the microcalorimeter modelled; the SAXS arm excluded. | The detector roster per endstation. |
+| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live per endstation (the Lakeshore controllers). | One `TemperatureController` Asset; the others noted. | The sample-environment Assets. |
+| DIAG-1 | Nice-to-have | The flux-channel map (the I0 mesh / diode, the drain-current and ion-chamber SR570 channels); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only the per-Asset channel map stays open. | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor and PositionMonitor channel-map bindings. |
+| INSITU-1 | Nice-to-have | The endstations and in-situ accessories deferred at this design phase: the NEXAFS endstation detail (drain-current / partial-electron-yield channels), the UCAL microcalorimeter ADR cryostat, the VPPEM microscope, the HAXPES flood gun and source-measure unit, and the RSoXS syringe pump. None fits an existing family cleanly. How does CORA model these? | Deferred; the main RSoXS / HAXPES / NEXAFS-TES legs are modelled; the rest are named here. | The deferred endstation and in-situ Assets. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs across the branches. | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the soft-scattering (RSoXS), absorption (NEXAFS), and photoemission (HAXPES) Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision the other scattering / spectroscopy / photoemission beamlines opened. | Capabilities deferred (rendered unlinked), no Practice recorded. | The technique Capability scope. |
diff --git a/docs/deployments/sst/questions.md b/docs/deployments/sst/questions.md
deleted file mode 100644
index b2fd62856a7..00000000000
--- a/docs/deployments/sst/questions.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Open questions
-
-*What CORA needs the SST team to confirm. This model is reverse-engineered from public open source (the `NSLS2/sst-*-profile-collection` endstation repos and the shared `NSLS-II-SST/sst-base` package): the EPICS PVs are read from the TOML device manifests and the sst-base device classes, but vendor identities, physical positions, and the per-endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The two undulator periods and gap / phase ranges (soft EPU60, tender U42). The devices (`SR:C07-ID:G1A{SST1:1}`, `{SST2:1}`) are confirmed from the sst-base energy classes; soft range about 71-2250 eV. | Two insertion devices, identity-only. | The InsertionDevice settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the shutters (`XF:07ID-PPS{Sh:FE}`, `XF:07IDA-PPS{PSh:n}`) are in source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The branch-to-hutch mapping and the physical hutch names / numbering (not in source): which endstations (RSoXS, NEXAFS on the soft SST-1 branch; HAXPES on the tender SST-2 branch; plus UCAL, VPPEM) sit in which enclosures? The PV zone numbers (07ID1 / 07ID2 / 07ID6) do not map one-to-one to a branch. | An optics hutch plus a soft (SST-1) and a tender (SST-2) experiment enclosure. | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The soft PGM grating set and the tender DCM crystal cut and ranges. Both monochromators (`Mono:PGM1`, `Mono:DCM1`) are in source. | One GratingMonochromator and one Monochromator Asset, settings blank. | The Monochromator settings. |
-| ENERGY-1 | Nice-to-have | Is energy scanned as the measurement (NEXAFS absorption sweeps the soft PGM across an edge), warranting the energy-scan Capability the catalog anticipates? | NEXAFS mapped to deferred Capabilities; energy-scan deferred (the BMM question). | The spectroscopy Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ARPES-1 | Blocks-go-live | The HAXPES Scienta SES hemispherical analyzer model, lens modes, and pass-energy / kinetic-energy controls. | An `ElectronAnalyzer` Asset (catalog Family, graduated at this 2nd sighting after ESM) presenting the Detector Role. | The analyzer model. |
-| DET-1 | Blocks-go-live | Which detectors are live per endstation: the RSoXS Greateyes WAXS CCD (a second SAXS-arm CCD is commented out), the HAXPES analyzer, the NEXAFS microcalorimeter and drain-current / partial-electron-yield channels. | The WAXS CCD, the analyzer, and the microcalorimeter modelled; the SAXS arm excluded. | The detector roster per endstation. |
-| TEMP-1 | Nice-to-have | Which sample-environment thermal units are live per endstation (the Lakeshore controllers). | One `TemperatureController` Asset; the others noted. | The sample-environment Assets. |
-| DIAG-1 | Nice-to-have | The flux-channel map (the I0 mesh / diode, the drain-current and ion-chamber SR570 channels); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only the per-Asset channel map stays open. | Read-only flux (`FluxMonitor`) and beam-position (graduated catalog `PositionMonitor`) probes; channel maps blank. | The FluxMonitor and PositionMonitor channel-map bindings. |
-| INSITU-1 | Nice-to-have | The endstations and in-situ accessories deferred at this design phase: the NEXAFS endstation detail (drain-current / partial-electron-yield channels), the UCAL microcalorimeter ADR cryostat, the VPPEM microscope, the HAXPES flood gun and source-measure unit, and the RSoXS syringe pump. None fits an existing family cleanly. How does CORA model these? | Deferred; the main RSoXS / HAXPES / NEXAFS-TES legs are modelled; the rest are named here. | The deferred endstation and in-situ Assets. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs across the branches. | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the soft-scattering (RSoXS), absorption (NEXAFS), and photoemission (HAXPES) Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision the other scattering / spectroscopy / photoemission beamlines opened. | Capabilities deferred (rendered unlinked), no Practice recorded. | The technique Capability scope. |
diff --git a/docs/deployments/sst/techniques.md b/docs/deployments/sst/techniques.md
deleted file mode 100644
index 04d69955d1b..00000000000
--- a/docs/deployments/sst/techniques.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Techniques
-
-*What CORA would run at SST: soft-scattering, absorption, and photoemission techniques, each a [Catalog](../../catalog/methods.md) Method. SST spans three technique families on two branches, and follows the deferral discipline of the beamlines that brought each to CORA.*
-
-SST's techniques are new-domain science (soft-X-ray scattering, absorption, photoemission), the families Diamond and the earlier NSLS-II soft-X-ray beamlines brought to CORA. The Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Branch / mode | Notes |
-| --- | --- | --- |
-| Resonant soft X-ray scattering (RSoXS) | soft, monochromatic | scattering pattern on the Greateyes CCD; the i22 / CSX scattering family, new Capability pending (TECH-1) |
-| NEXAFS absorption | soft, energy sweep | drain current / partial electron yield / microcalorimeter fluorescence over an energy scan; the BMM energy-scan question (ENERGY-1, TECH-1) |
-| HAXPES photoemission | tender, fixed energy | photoelectron spectra on the hemispherical analyzer; the ESM photoemission family, new Capability pending (TECH-1) |
-
-All three need the per-endstation [sample manipulator](sample.md) and [detector](detector.md); the fast shutter gates the exposure, and the endstation in control selects the branch.
-
-## Why the Capabilities stay deferred
-
-Each of SST's three technique families sits on a Capability the catalog does not yet carry, and the discipline is the same one the originating beamlines applied: soft-X-ray scattering follows Diamond i22 and NSLS-II CSX (the scattering Capabilities are pending, TECH-1); NEXAFS absorption follows BMM (energy-scan-as-the-measurement, deferred at ENERGY-1); photoemission follows NSLS-II ESM (the `angle_resolved_photoemission` Method ESM coined is pending, and HAXPES is the hard / tender photoemission companion). The device Roles already exist (the CCD presents Detector, the manipulators present Positioner, the analyzer and microcalorimeter are the energy-resolving detectors); what is new is the science Capability, not a device shape. SST reinforces all three at one more, larger instrument without coining any, so it records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
-
-The per-technique reduction (scattering reduction, photoemission spectra, NEXAFS spectra) is `ComputePort` work, not beamline Methods.
diff --git a/docs/deployments/syrmep/governance.md b/docs/deployments/syrmep/governance.md
deleted file mode 100644
index 3cc17ca07cd..00000000000
--- a/docs/deployments/syrmep/governance.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Governance
-
-*Who will act at SYRMEP, and the trust shape that will gate it. First cut.*
-
-Governance at SYRMEP follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Elettra Site](../elettra/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-SYRMEP is CORA's first Elettra deployment, so Elettra is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [Elettra Site](../elettra/index.md), shared across the facility's beamlines, until Elettra staff confirm them (`GOV-1`). SYRMEP is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives SYRMEP, following the [2-BM governance](../2-bm/governance.md) shape.
-
-The safety tier is the other piece that is not yet settled. The Elettra personnel-safety permit signals and the front-end / safety shutters are not in public source, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). The Elettra 2.0 GeCo PLC interlock stack (Siemens S7-1500 over PROFINET) is the safety floor CORA never drives; it sits below the seam. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Elettra Site](../elettra/index.md), not on the beamline, and the beamline links up to them.
-
-SYRMEP carries the hazard classes that come with hard X-ray imaging: an intense white / monochromatic beam, and, for the clinical breast-CT programme (SYRMA-3D), human-subject considerations that an experiment Clearance would carry. Those land with the work that brings them, modelled as hazards on the experiment rather than as Assets CORA drives for safety.
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives SYRMEP, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/syrmep/model.md b/docs/deployments/syrmep/model.md
deleted file mode 100644
index 10177262cbc..00000000000
--- a/docs/deployments/syrmep/model.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's SYRMEP content lives, the new Elettra Site and Tango / DonkiOrchestra control house-style it introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at SYRMEP |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes SYRMEP new
-
-SYRMEP is two things at the facility level and nothing new at the catalog level. It is CORA's **eleventh Site** (Elettra Sincrotrone Trieste, Trieste), another re-test of the Site and Federation kernel, and the **first Tango + DonkiOrchestra** control house-style. The Tango device floor is shared with the ESRF's ID32, but the orchestration seam is the in-house, trigger-driven DonkiOrchestra framework (Elettra 2.0: the abstract "Executer" Tango device server), not BLISS and not EPICS. Its science is hard X-ray microtomography (absorption, propagation-based phase contrast, diffraction-enhanced imaging) plus the SYRMA-3D clinical breast-CT programme.
-
-## No new families: the imaging spine ports wholesale
-
-SYRMEP coins no new Family and changes nothing in the catalog. It is the cleanest re-test the fleet has of the imaging spine on a new Site:
-
-- the bending-magnet source is a Supply (`PhotonBeam`), provenance only (the 2-BM precedent);
-- the double-crystal Si(111) DCM binds `Monochromator`, with the mono / white (pink) beam choice as a per-Asset setting (the 2-BM `dmm_insertion` insert/retract precedent);
-- the incident energy is a `PseudoAxis` over the DCM (the 2-BM energy-curve precedent);
-- the laminar-beam slits bind `Slit`, the filters bind `Filter`, the upstream mask binds `Mask`;
-- the heavy-payload rotation stage binds `RotaryStage` (the tomographic theta);
-- the five-axis sample positioner binds `LinearStage`;
-- the sample-to-detector propagation rail binds `LinearStage` (the 2-BM `CameraZ` precedent);
-- the scintillator binds `Scintillator` and the sCMOS / CCD / photon-counting cameras bind `Camera`;
-- the machine state binds the loose `StorageRing`.
-
-Unlike ID32 (which bound no catalog Method), SYRMEP's core Practices bind the real catalog `tomography`, `continuous_rotation_tomography`, `mosaic_tomography`, `dark_field`, `flat_field`, and `center_alignment` Methods. The three new technique slugs (`helical_tomography`, `white_beam_tomography`, `phase_retrieval`) are registered pending in `tests/unit/deployments/test_site_descriptor.py` until they enter pilot scope.
-
-## The Tango / DonkiOrchestra control plane
-
-SYRMEP is the first Tango + DonkiOrchestra controls house-style in the fleet. CORA models the control handles as opaque edge strings over the `ControlPort`, the way the MX3 / ID32 heterogeneous-control precedent does. The crucial difference from ID32: **SYRMEP's handles are not in public source**. The DonkiOrchestra scan engine's source location is unconfirmed and the acquisition code is in the private `gitlab.elettra.eu` `syrmep_acquisition` group, so the handles are confirm-pending placeholders rather than read addresses (`CTRL-1`). The DonkiOrchestra orchestration (Elettra 2.0: the "Executer" device server) is the seam CORA's edge replaces, conducting over Tango rather than over BLISS or EPICS.
-
-## Deliberately not here yet
-
-| Deferred | Why | Tracking |
-| --- | --- | --- |
-| Every concrete control handle | not in public source (private gitlab group, unconfirmed DonkiOrchestra source) | `CTRL-1` |
-| PSS permit signals and shutters | not in public source, not invented | `PSS-1` |
-| The default routine camera, pixel size, FOV | sources name multiple detectors without pinning the routine one | `DET-1` |
-| Helical CT, white-beam tomography, phase retrieval as catalog Methods | a CORA-scope decision pending pilot scope | `TECH-1` |
-| The reconstruction pipeline as Compute provenance | post-acquisition compute; modelled when the deployment firms up | `COMPUTE-1` |
-| Scenarios, operations runbook, live experiment view | SYRMEP is not yet driven by CORA | follows the [2-BM](../2-bm/index.md) shape |
diff --git a/docs/deployments/syrmep/notes.md b/docs/deployments/syrmep/notes.md
new file mode 100644
index 00000000000..9d5bee90a6c
--- /dev/null
+++ b/docs/deployments/syrmep/notes.md
@@ -0,0 +1,155 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of SYRMEP is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../elettra/index.md) is how a facility adapts it. SYRMEP is a hard X-ray microtomography beamline, so its core imaging techniques reuse the catalog Methods the fleet's imaging beamlines already share; the helical, white-beam, and phase-retrieval Methods are new to CORA's catalog and render unlinked, carried pending until a technique enters scope (`TECH-1`).
+
+### Microtomography: absorption and phase contrast
+
+SYRMEP sets the X-ray energy with the Si(111) monochromator (or passes white / pink beam), then rotates the specimen while the detector records projections. It does absorption tomography, propagation-based phase-contrast tomography (the long sample-to-detector rail), and diffraction-enhanced imaging.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Microtomography | [`tomography`](../../catalog/methods.md) | the canonical imaging routine on the [rotation stage](sample.md) and [camera](detector.md); reuses the 2-BM tomography Method directly |
+| Continuous (fly) tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | trigger-driven continuous rotation under DonkiOrchestra; reuses the catalog Method |
+| Wide / laminar-beam tomography | [`mosaic_tomography`](../../catalog/methods.md) | tiled tomography for samples beyond the field of view; reuses the catalog Method |
+| Dark / flat field | [`dark_field`](../../catalog/methods.md), [`flat_field`](../../catalog/methods.md) | the reconstruction baseline frames; reuse the catalog acquisition Methods |
+| Rotation-axis centring | [`center_alignment`](../../catalog/methods.md) | the alignment step; reuses the catalog Method |
+| Helical CT | `helical_tomography` | the large-specimen continuous-pitch mode (the XC Hydra photon-counting setup); Method not yet in the catalog, renders unlinked |
+| White / pink-beam tomography | `white_beam_tomography` | fast tomography with the DCM bypassed; Method not yet in the catalog |
+| Phase retrieval | `phase_retrieval` | single-distance TIE-HOM / Paganin retrieval (the SYRMEP Tomo Project pipeline); a compute Method not yet in the catalog (`COMPUTE-1`) |
+
+### A clean re-test of the imaging spine
+
+SYRMEP's significance for the catalog is that it forces nothing new at the Family level: every device binds an existing imaging Family (`RotaryStage`, `LinearStage`, `Camera`, `Scintillator`, `Slit`, `Filter`, `Monochromator`), and the core tomography Practices bind real catalog Methods. It is the cleanest re-test the fleet has of whether the imaging spine ports to a brand-new Site and control house-style. The clinical breast-CT programme (SYRMA-3D) and the large-specimen helical work are extensions that would earn new Methods if the deployment enters pilot scope.
+
+### Not modelled yet
+
+The concrete acquisition recipes (the exposure, projection counts, angle ranges, propagation distances, and the phase-retrieval and ring-removal parameters) are not written yet; they join as the deployment approaches the point where CORA drives SYRMEP. Whether helical CT, white-beam tomography, and phase retrieval enter CORA's catalog is an owner-scope decision on [Model](#deliberately-not-here-yet); see [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at SYRMEP, and the trust shape that will gate it. First cut.*
+
+Governance at SYRMEP follows the same model as the rest of the fleet: people and autonomous agents are facility principals at the [Elettra Site](../elettra/index.md), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+SYRMEP is CORA's first Elettra deployment, so Elettra is a brand-new Site: the operator pool and the safety-review structure are carried pending on the [Elettra Site](../elettra/index.md), shared across the facility's beamlines, until Elettra staff confirm them (`GOV-1`). SYRMEP is a reverse-engineered scaffold rather than a pilot, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized; they land when the deployment approaches the point where CORA drives SYRMEP, following the [2-BM governance](../2-bm/governance.md) shape.
+
+The safety tier is the other piece that is not yet settled. The Elettra personnel-safety permit signals and the front-end / safety shutters are not in public source, so the Enclosure permit leaves and the interlock structure are carried pending and are not invented here (`PSS-1`). The Elettra 2.0 GeCo PLC interlock stack (Siemens S7-1500 over PROFINET) is the safety floor CORA never drives; it sits below the seam. What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [Elettra Site](../elettra/index.md), not on the beamline, and the beamline links up to them.
+
+SYRMEP carries the hazard classes that come with hard X-ray imaging: an intense white / monochromatic beam, and, for the clinical breast-CT programme (SYRMA-3D), human-subject considerations that an experiment Clearance would carry. Those land with the work that brings them, modelled as hazards on the experiment rather than as Assets CORA drives for safety.
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives SYRMEP, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's SYRMEP content lives, the new Elettra Site and Tango / DonkiOrchestra control house-style it introduces, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at SYRMEP |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (the incident-energy `PseudoAxis`) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes SYRMEP new
+
+SYRMEP is two things at the facility level and nothing new at the catalog level. It is CORA's **eleventh Site** (Elettra Sincrotrone Trieste, Trieste), another re-test of the Site and Federation kernel, and the **first Tango + DonkiOrchestra** control house-style. The Tango device floor is shared with the ESRF's ID32, but the orchestration seam is the in-house, trigger-driven DonkiOrchestra framework (Elettra 2.0: the abstract "Executer" Tango device server), not BLISS and not EPICS. Its science is hard X-ray microtomography (absorption, propagation-based phase contrast, diffraction-enhanced imaging) plus the SYRMA-3D clinical breast-CT programme.
+
+### No new families: the imaging spine ports wholesale
+
+SYRMEP coins no new Family and changes nothing in the catalog. It is the cleanest re-test the fleet has of the imaging spine on a new Site:
+
+- the bending-magnet source is a Supply (`PhotonBeam`), provenance only (the 2-BM precedent);
+- the double-crystal Si(111) DCM binds `Monochromator`, with the mono / white (pink) beam choice as a per-Asset setting (the 2-BM `dmm_insertion` insert/retract precedent);
+- the incident energy is a `PseudoAxis` over the DCM (the 2-BM energy-curve precedent);
+- the laminar-beam slits bind `Slit`, the filters bind `Filter`, the upstream mask binds `Mask`;
+- the heavy-payload rotation stage binds `RotaryStage` (the tomographic theta);
+- the five-axis sample positioner binds `LinearStage`;
+- the sample-to-detector propagation rail binds `LinearStage` (the 2-BM `CameraZ` precedent);
+- the scintillator binds `Scintillator` and the sCMOS / CCD / photon-counting cameras bind `Camera`;
+- the machine state binds the loose `StorageRing`.
+
+Unlike ID32 (which bound no catalog Method), SYRMEP's core Practices bind the real catalog `tomography`, `continuous_rotation_tomography`, `mosaic_tomography`, `dark_field`, `flat_field`, and `center_alignment` Methods. The three new technique slugs (`helical_tomography`, `white_beam_tomography`, `phase_retrieval`) are registered pending in `tests/unit/deployments/test_site_descriptor.py` until they enter pilot scope.
+
+### The Tango / DonkiOrchestra control plane
+
+SYRMEP is the first Tango + DonkiOrchestra controls house-style in the fleet. CORA models the control handles as opaque edge strings over the `ControlPort`, the way the MX3 / ID32 heterogeneous-control precedent does. The crucial difference from ID32: **SYRMEP's handles are not in public source**. The DonkiOrchestra scan engine's source location is unconfirmed and the acquisition code is in the private `gitlab.elettra.eu` `syrmep_acquisition` group, so the handles are confirm-pending placeholders rather than read addresses (`CTRL-1`). The DonkiOrchestra orchestration (Elettra 2.0: the "Executer" device server) is the seam CORA's edge replaces, conducting over Tango rather than over BLISS or EPICS.
+
+### Deliberately not here yet
+
+| Deferred | Why | Tracking |
+| --- | --- | --- |
+| Every concrete control handle | not in public source (private gitlab group, unconfirmed DonkiOrchestra source) | `CTRL-1` |
+| PSS permit signals and shutters | not in public source, not invented | `PSS-1` |
+| The default routine camera, pixel size, FOV | sources name multiple detectors without pinning the routine one | `DET-1` |
+| Helical CT, white-beam tomography, phase retrieval as catalog Methods | a CORA-scope decision pending pilot scope | `TECH-1` |
+| The reconstruction pipeline as Compute provenance | post-acquisition compute; modelled when the deployment firms up | `COMPUTE-1` |
+| Scenarios, operations runbook, live experiment view | SYRMEP is not yet driven by CORA | follows the [2-BM](../2-bm/index.md) shape |
+
+## Open questions
+
+*What CORA needs the SYRMEP team to confirm before the model can be trusted.*
+
+SYRMEP was reverse-engineered from public material (the [elettra.eu SYRMEP pages](https://www.elettra.eu/elettra-beamlines/syrmep.html), the EPJ Plus 2024 SYRMEP review, and the J. Synchrotron Rad. 2023 large-FOV paper). The hardware facts are read from those sources, but **the control handles are not in public source**: the in-house DonkiOrchestra scan engine's source location is unconfirmed and the acquisition code lives in the private `gitlab.elettra.eu` `syrmep_acquisition` group. So unlike the ID32 BLISS scaffold, the device handles on the [device pages](index.md) are confirm-pending placeholders rather than read addresses. This is CORA's first Elettra Site and first Tango / DonkiOrchestra controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | The hutch grouping: a white-beam optics zone feeding one imaging / tomography endstation, or a different layout? | A shared `syrmep-optics` zone and the `syrmep-experiment` endstation. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The bending-magnet source detail (critical energy, field across the 2.0 / 2.4 GeV modes). | A bending-magnet source (section 6); 5.59 keV critical energy and 1.45 T field at 2.4 GeV. | The source Asset detail. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The Elettra storage-ring state SYRMEP reads (the 2.0 GeV / 300 mA and 2.4 GeV modes; current, fill). | Observe-only machine state, a loose `StorageRing`; exact Tango handles pending. | The machine-state observation. |
+| MONO-1 | Blocks-go-live | The Si(111) DCM energy range and the authoritative bound: the EPJ Plus 2024 review states mono 10-40 keV, the elettra.eu spec still lists 9-40 keV. The Bragg / offset handles. | A `Monochromator` (Si(111), fixed-exit, 20 mm offset); energy a `PseudoAxis`; range 10-40 keV mono. | The monochromator and incident-energy Assets. |
+| MODE-1 | Blocks-go-live | The mono / white (pink) beam switch: how the beam bypasses the DCM, and the white-beam energy (~16-30 keV average). | The beam mode is a per-Asset setting on the `Monochromator` (the 2-BM DMM insert/retract precedent). | The beam-mode modelling. |
+| OPT-1 | Nice-to-have | The white-beam-defining mask dimensions and drawing. | A fixed `Mask` upstream of the optics. | The mask Asset detail. |
+| OPT-2 | Blocks-go-live | The laminar-beam slit blade-axis map and handles, and the beam dimensions (sources cite ~120 x 4 mm at 20 m and ~160 x 5 mm at 23 m). | Slits bound to `Slit`; a ~120-160 mm wide, ~4-5 mm tall laminar beam at 7 mrad acceptance. | The slit Asset detail and beam geometry. |
+| FOIL-1 | Nice-to-have | The absorption / beam-hardening filter foils and the selector handle. | Filters bound to `Filter`; foils pending. | The filter Asset detail. |
+
+### Sample
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The rotation stages: the heavy-payload rotator (up to 120 kg, 1-20 deg/s, 0.02 deg) is documented, but the standard sample rotation stage range / bearing / model and the rotator wobble spec are not. | A `RotaryStage` for the tomographic theta; a standard-stage variant and the wobble spec pending. | The rotation-stage modelling. |
+| SAMPLE-1 | Blocks-go-live | The five-axis sample-positioning stage: motor vendors, micro-positioning resolution, axes, and handles. | A `LinearStage` facet set; vendors / resolution / axis map pending. | The sample-stage modelling. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The default routine-tomography camera and its pixel size and field of view: the sCMOS (2048x2048, 0.9-5.7 um) or the CCD (4008x2672, 4.5 um)? | Both bind `Camera`; the routine camera is pending. | The detector modelling. |
+| DET-2 | Nice-to-have | The sample-to-detector propagation rail and the two-axis detector rail handles. | A `LinearStage` (range 3-160 cm). | The propagation-rail Asset. |
+| DET-3 | Nice-to-have | The routine scintillator screen type and thickness (published configs cite GGG:Eu). | A `Scintillator`; type and thickness pending. | The scintillator Asset. |
+| DET-4 | Nice-to-have | The XC Hydra photon-counting detector pixel size and configuration, and when it is used. | A `Camera` for the large-specimen / helical CT mode; pixel size pending. | The photon-counting detector modelling. |
+
+### Controls and acquisition
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | The Tango device namespaces and the DonkiOrchestra (Elettra 2.0: "Executer") scan-engine handles: SYRMEP's control source is not public. | A Tango device floor with the in-house DonkiOrchestra scan engine; handles are confirm-pending placeholders. | The whole control plane (every device handle in the Inventory). |
+| PSS-1 | Blocks-go-live | The Elettra personnel-safety permit signals and the front-end / safety shutters. | Enclosure permit leaves and a `Shutter`, carried pending, not invented. | The safety / interlock structure. |
+
+### Techniques and compute
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Nice-to-have | The technique scope: core tomography reuses catalog Methods, but helical CT, white-beam tomography, and phase retrieval are not yet catalog Methods. | The core tomography Practices reuse catalog Methods; the rest are pending and render unlinked. | Whether the new techniques enter the catalog (a CORA-scope call on [Model](#deliberately-not-here-yet)). |
+| COMPUTE-1 | Nice-to-have | The reconstruction pipeline (the SYRMEP Tomo Project: phase retrieval, ring removal, FBP / iterative on ASTRA + TomoPy) and whether CORA records its invocation as Method / Compute provenance. | Post-acquisition compute CORA records as provenance, not data it owns. | The compute-provenance modelling. |
+| SUP-1 | Nice-to-have | The facility supplies a run draws on (cooling water for the optics, the vacuum extent of the white-beam path). | `PhotonBeam`, `CoolingWater`, `Vacuum`. | The Supply detail. |
+
+### Governance
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GOV-1 | Nice-to-have | The Elettra operator pool and safety-review structure (site-level). | Carried pending on the Elettra Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/syrmep/questions.md b/docs/deployments/syrmep/questions.md
deleted file mode 100644
index 36fe6a8b813..00000000000
--- a/docs/deployments/syrmep/questions.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Open questions
-
-*What CORA needs the SYRMEP team to confirm before the model can be trusted.*
-
-SYRMEP was reverse-engineered from public material (the [elettra.eu SYRMEP pages](https://www.elettra.eu/elettra-beamlines/syrmep.html), the EPJ Plus 2024 SYRMEP review, and the J. Synchrotron Rad. 2023 large-FOV paper). The hardware facts are read from those sources, but **the control handles are not in public source**: the in-house DonkiOrchestra scan engine's source location is unconfirmed and the acquisition code lives in the private `gitlab.elettra.eu` `syrmep_acquisition` group. So unlike the ID32 BLISS scaffold, the device handles on the [device pages](index.md) are confirm-pending placeholders rather than read addresses. This is CORA's first Elettra Site and first Tango / DonkiOrchestra controls house-style. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | The hutch grouping: a white-beam optics zone feeding one imaging / tomography endstation, or a different layout? | A shared `syrmep-optics` zone and the `syrmep-experiment` endstation. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The bending-magnet source detail (critical energy, field across the 2.0 / 2.4 GeV modes). | A bending-magnet source (section 6); 5.59 keV critical energy and 1.45 T field at 2.4 GeV. | The source Asset detail. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The Elettra storage-ring state SYRMEP reads (the 2.0 GeV / 300 mA and 2.4 GeV modes; current, fill). | Observe-only machine state, a loose `StorageRing`; exact Tango handles pending. | The machine-state observation. |
-| MONO-1 | Blocks-go-live | The Si(111) DCM energy range and the authoritative bound: the EPJ Plus 2024 review states mono 10-40 keV, the elettra.eu spec still lists 9-40 keV. The Bragg / offset handles. | A `Monochromator` (Si(111), fixed-exit, 20 mm offset); energy a `PseudoAxis`; range 10-40 keV mono. | The monochromator and incident-energy Assets. |
-| MODE-1 | Blocks-go-live | The mono / white (pink) beam switch: how the beam bypasses the DCM, and the white-beam energy (~16-30 keV average). | The beam mode is a per-Asset setting on the `Monochromator` (the 2-BM DMM insert/retract precedent). | The beam-mode modelling. |
-| OPT-1 | Nice-to-have | The white-beam-defining mask dimensions and drawing. | A fixed `Mask` upstream of the optics. | The mask Asset detail. |
-| OPT-2 | Blocks-go-live | The laminar-beam slit blade-axis map and handles, and the beam dimensions (sources cite ~120 x 4 mm at 20 m and ~160 x 5 mm at 23 m). | Slits bound to `Slit`; a ~120-160 mm wide, ~4-5 mm tall laminar beam at 7 mrad acceptance. | The slit Asset detail and beam geometry. |
-| FOIL-1 | Nice-to-have | The absorption / beam-hardening filter foils and the selector handle. | Filters bound to `Filter`; foils pending. | The filter Asset detail. |
-
-## Sample
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The rotation stages: the heavy-payload rotator (up to 120 kg, 1-20 deg/s, 0.02 deg) is documented, but the standard sample rotation stage range / bearing / model and the rotator wobble spec are not. | A `RotaryStage` for the tomographic theta; a standard-stage variant and the wobble spec pending. | The rotation-stage modelling. |
-| SAMPLE-1 | Blocks-go-live | The five-axis sample-positioning stage: motor vendors, micro-positioning resolution, axes, and handles. | A `LinearStage` facet set; vendors / resolution / axis map pending. | The sample-stage modelling. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The default routine-tomography camera and its pixel size and field of view: the sCMOS (2048x2048, 0.9-5.7 um) or the CCD (4008x2672, 4.5 um)? | Both bind `Camera`; the routine camera is pending. | The detector modelling. |
-| DET-2 | Nice-to-have | The sample-to-detector propagation rail and the two-axis detector rail handles. | A `LinearStage` (range 3-160 cm). | The propagation-rail Asset. |
-| DET-3 | Nice-to-have | The routine scintillator screen type and thickness (published configs cite GGG:Eu). | A `Scintillator`; type and thickness pending. | The scintillator Asset. |
-| DET-4 | Nice-to-have | The XC Hydra photon-counting detector pixel size and configuration, and when it is used. | A `Camera` for the large-specimen / helical CT mode; pixel size pending. | The photon-counting detector modelling. |
-
-## Controls and acquisition
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | The Tango device namespaces and the DonkiOrchestra (Elettra 2.0: "Executer") scan-engine handles: SYRMEP's control source is not public. | A Tango device floor with the in-house DonkiOrchestra scan engine; handles are confirm-pending placeholders. | The whole control plane (every device handle in the Inventory). |
-| PSS-1 | Blocks-go-live | The Elettra personnel-safety permit signals and the front-end / safety shutters. | Enclosure permit leaves and a `Shutter`, carried pending, not invented. | The safety / interlock structure. |
-
-## Techniques and compute
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Nice-to-have | The technique scope: core tomography reuses catalog Methods, but helical CT, white-beam tomography, and phase retrieval are not yet catalog Methods. | The core tomography Practices reuse catalog Methods; the rest are pending and render unlinked. | Whether the new techniques enter the catalog (a CORA-scope call on [Model](model.md#deliberately-not-here-yet)). |
-| COMPUTE-1 | Nice-to-have | The reconstruction pipeline (the SYRMEP Tomo Project: phase retrieval, ring removal, FBP / iterative on ASTRA + TomoPy) and whether CORA records its invocation as Method / Compute provenance. | Post-acquisition compute CORA records as provenance, not data it owns. | The compute-provenance modelling. |
-| SUP-1 | Nice-to-have | The facility supplies a run draws on (cooling water for the optics, the vacuum extent of the white-beam path). | `PhotonBeam`, `CoolingWater`, `Vacuum`. | The Supply detail. |
-
-## Governance
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GOV-1 | Nice-to-have | The Elettra operator pool and safety-review structure (site-level). | Carried pending on the Elettra Site, not instantiated per beamline. | The governance principals. |
diff --git a/docs/deployments/syrmep/techniques.md b/docs/deployments/syrmep/techniques.md
deleted file mode 100644
index 90c9891f957..00000000000
--- a/docs/deployments/syrmep/techniques.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Techniques
-
-*What the modelled part of SYRMEP is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../elettra/index.md) is how a facility adapts it. SYRMEP is a hard X-ray microtomography beamline, so its core imaging techniques reuse the catalog Methods the fleet's imaging beamlines already share; the helical, white-beam, and phase-retrieval Methods are new to CORA's catalog and render unlinked, carried pending until a technique enters scope (`TECH-1`).
-
-## Microtomography: absorption and phase contrast
-
-SYRMEP sets the X-ray energy with the Si(111) monochromator (or passes white / pink beam), then rotates the specimen while the detector records projections. It does absorption tomography, propagation-based phase-contrast tomography (the long sample-to-detector rail), and diffraction-enhanced imaging.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Microtomography | [`tomography`](../../catalog/methods.md) | the canonical imaging routine on the [rotation stage](sample.md) and [camera](detector.md); reuses the 2-BM tomography Method directly |
-| Continuous (fly) tomography | [`continuous_rotation_tomography`](../../catalog/methods.md) | trigger-driven continuous rotation under DonkiOrchestra; reuses the catalog Method |
-| Wide / laminar-beam tomography | [`mosaic_tomography`](../../catalog/methods.md) | tiled tomography for samples beyond the field of view; reuses the catalog Method |
-| Dark / flat field | [`dark_field`](../../catalog/methods.md), [`flat_field`](../../catalog/methods.md) | the reconstruction baseline frames; reuse the catalog acquisition Methods |
-| Rotation-axis centring | [`center_alignment`](../../catalog/methods.md) | the alignment step; reuses the catalog Method |
-| Helical CT | `helical_tomography` | the large-specimen continuous-pitch mode (the XC Hydra photon-counting setup); Method not yet in the catalog, renders unlinked |
-| White / pink-beam tomography | `white_beam_tomography` | fast tomography with the DCM bypassed; Method not yet in the catalog |
-| Phase retrieval | `phase_retrieval` | single-distance TIE-HOM / Paganin retrieval (the SYRMEP Tomo Project pipeline); a compute Method not yet in the catalog (`COMPUTE-1`) |
-
-## A clean re-test of the imaging spine
-
-SYRMEP's significance for the catalog is that it forces nothing new at the Family level: every device binds an existing imaging Family (`RotaryStage`, `LinearStage`, `Camera`, `Scintillator`, `Slit`, `Filter`, `Monochromator`), and the core tomography Practices bind real catalog Methods. It is the cleanest re-test the fleet has of whether the imaging spine ports to a brand-new Site and control house-style. The clinical breast-CT programme (SYRMA-3D) and the large-specimen helical work are extensions that would earn new Methods if the deployment enters pilot scope.
-
-## Not modelled yet
-
-The concrete acquisition recipes (the exposure, projection counts, angle ranges, propagation distances, and the phase-retrieval and ring-removal parameters) are not written yet; they join as the deployment approaches the point where CORA drives SYRMEP. Whether helical CT, white-beam tomography, and phase retrieval enter CORA's catalog is an owner-scope decision on [Model](model.md#deliberately-not-here-yet); see [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/tomowise/governance.md b/docs/deployments/tomowise/governance.md
deleted file mode 100644
index 179c4e69cf0..00000000000
--- a/docs/deployments/tomowise/governance.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Governance
-
-*Who will act at TomoWISE, and the trust shape that will gate it. Design-phase.*
-
-Governance at TomoWISE follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [MAX IV Site](../maxiv/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-TomoWISE is pre-build, so this shape is not yet instantiated. The MAX IV operator and safety-review structure is still being defined and is carried pending on the [MAX IV site page](../maxiv/index.md#safety-and-governance); CORA does not invent a MAX IV operator pool or review chain ahead of confirmation.
-
-What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the MAX IV Site, not on the beamline, and the beamline links up to them rather than restating them. The MAX IV safety-form names themselves are an open question (PSS-1 on [Open questions](questions.md)).
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape.
diff --git a/docs/deployments/tomowise/model.md b/docs/deployments/tomowise/model.md
deleted file mode 100644
index 86f89396a4c..00000000000
--- a/docs/deployments/tomowise/model.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's TomoWISE content lives, the cross-facility `Microscope` / `Optics` Assemblies it reuses with 2-BM, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at TomoWISE |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What is deliberately not here yet
-
-- **Integration scenarios.** No `test_tomowise_*.py` registers TomoWISE Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, moving-target beamline would commit speculative structure. It lands when the design firms and the team approves.
-- **Vendor Models.** Only one catalog Model is bound: `optique_peter_micrx080` on the microscope Housings (reused from 2-BM, pending confirmation, DET-2). The remaining "(target)" models in the TDR are [open questions](questions.md), not bindings, because part numbers are not yet procured.
-- **Operations and experiment views.** A runbook and live experiment view for an unbuilt beamline would be invention; see the note on the [index](index.md#not-yet-documented).
-- **Detector assemblies (done).** The two microscopes now compose the cross-facility `Microscope` / `Optics` Assemblies that 2-BM uses (Housing-anchored: turret + objectives + selector over a scintillator), rather than a loose family. The catalog assembly was generalized (`camera` and `propagation_distance` made `ZeroOrOne`) so TomoWISE can share its four cameras and the one gantry propagation rail across both microscopes. This also removed the prior name collision between the loose `Microscope` family and the catalog `Microscope` Assembly. What remains deferred is the integration scenario that registers the Fixture (slot -> Asset bindings) and a standalone fixture page; both wait until the design firms.
diff --git a/docs/deployments/tomowise/notes.md b/docs/deployments/tomowise/notes.md
new file mode 100644
index 00000000000..d42d560cf5d
--- /dev/null
+++ b/docs/deployments/tomowise/notes.md
@@ -0,0 +1,94 @@
+# Notes
+
+## Techniques
+
+*What TomoWISE is designed to do, as intent. Design-phase.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../maxiv/index.md#the-techniques-adapted-here) is how a facility adapts it. TomoWISE is pre-build, so the techniques below are design intent: the MAX IV Practices that will bind them are carried pending on the [MAX IV site page](../maxiv/index.md#the-techniques-adapted-here). The function view survives the eventual equipment choices, which is why it can be written before the hardware is procured.
+
+The beamline's five operation modes (TDR) select the source, filtering, monochromator, and KB optics for a given technique:
+
+| Technique | Source | Monochromator | KB | What it is for |
+| --- | --- | --- | --- | --- |
+| Standard microtomography | CPMU14 | MLM | no | high-throughput monochromatic CT |
+| High-speed microtomography (small FOV) | CPMU14 | MLM or none | no | sub-micron pixel, fast dynamics |
+| Large-FOV / white-beam microtomography | 3T3PW | none | no | large or highly attenuating samples |
+| Nanotomography | CPMU14 | MLM | yes | 200-nm-class cone-beam imaging |
+| Laminography | CPMU14 | MLM | no | flat, extended samples (tilt axis, not a separate fixture) |
+
+A few points of intent shape the model:
+
+- **Source switching is first-class.** Two insertion devices (one `InsertionDevice` Family, two Assets) are selected per mode, unlike the single bending-magnet source at 2-BM. The mode determines which is in the beam.
+- **Laminography is a tilt setpoint, not a separate station.** It runs on the microtomography endstation's tilt axis, mirroring the 2-BM laminography decision: the same installed stack, a different Method, not a new Fixture.
+- **Monochromatic and white-beam are the same beamline.** Inserting or bypassing the MLM (and the filter chain) picks the spectrum; it is an operation mode over one set of optics, not two beamlines.
+
+The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the beamline approaches commissioning. See [Open questions](#open-questions) for what must be confirmed first.
+
+## Governance
+
+*Who will act at TomoWISE, and the trust shape that will gate it. Design-phase.*
+
+Governance at TomoWISE follows the same model as the 2-BM pilot: people and autonomous agents are facility principals at the [MAX IV Site](../maxiv/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+TomoWISE is pre-build, so this shape is not yet instantiated. The MAX IV operator and safety-review structure is still being defined and is carried pending on the [MAX IV site page](../maxiv/index.md#safety-and-governance); CORA does not invent a MAX IV operator pool or review chain ahead of confirmation.
+
+What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the MAX IV Site, not on the beamline, and the beamline links up to them rather than restating them. The MAX IV safety-form names themselves are an open question (PSS-1 on [Open questions](#open-questions)).
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the beamline approaches commissioning, following the [2-BM governance](../2-bm/governance.md) shape.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's TomoWISE content lives, the cross-facility `Microscope` / `Optics` Assemblies it reuses with 2-BM, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at TomoWISE |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What is deliberately not here yet
+
+- **Integration scenarios.** No `test_tomowise_*.py` registers TomoWISE Assets into the event store. Scenario code is where Assets become real, and hard-registering a design-phase, moving-target beamline would commit speculative structure. It lands when the design firms and the team approves.
+- **Vendor Models.** Only one catalog Model is bound: `optique_peter_micrx080` on the microscope Housings (reused from 2-BM, pending confirmation, DET-2). The remaining "(target)" models in the TDR are [open questions](#open-questions), not bindings, because part numbers are not yet procured.
+- **Operations and experiment views.** A runbook and live experiment view for an unbuilt beamline would be invention; see the note on the [index](index.md#not-yet-documented).
+- **Detector assemblies (done).** The two microscopes now compose the cross-facility `Microscope` / `Optics` Assemblies that 2-BM uses (Housing-anchored: turret + objectives + selector over a scintillator), rather than a loose family. The catalog assembly was generalized (`camera` and `propagation_distance` made `ZeroOrOne`) so TomoWISE can share its four cameras and the one gantry propagation rail across both microscopes. This also removed the prior name collision between the loose `Microscope` family and the catalog `Microscope` Assembly. What remains deferred is the integration scenario that registers the Fixture (slot -> Asset bindings) and a standalone fixture page; both wait until the design firms.
+
+## Open questions
+
+*What CORA needs the TomoWISE team to confirm before the model can be trusted.*
+
+TomoWISE is in the design phase, so this page is long by design: almost every value on the [device pages](index.md) is a TDR design specification, not a commissioned measurement. Each row below is a fact the beamline team or the TDR owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-build | What are the Tango/Sardana device and attribute names for each device? | Control handles are unassigned; CORA leaves the device handle empty (no EPICS PV). | Wiring each Asset to a real control handle. |
+| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for the optics and experiment hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
+
+### Sources and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| OPT-1 | Nice-to-have | Which MLM coating is selected? The TDR text lists W/SiC or W/B4C; Table 8.3 lists W/Si. | The MLM is one Monochromator Asset; coating is a setting. | The MLM coating setting. |
+| LAYOUT-1 | Nice-to-have | What is the single z-coordinate reference for the layout? The TDR mixes "from the CPMU14 source" (front end) and "from the straight-section centre" (optics and downstream), about 505 mm apart. | z values are carried as approximate from-source and flagged confirm. | Exact device z positions. |
+
+### Endstations
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| NANO-1 | Blocks-go-live | Are the nanotomography sample-manipulator model bindings final? The TDR specifies the six-axis stack in Table 9.5 (tilt, coarse X/Y/Z, continuous rotary, fine Xs/Zs); only the per-axis model procurement remains. | The TDR-specified stack, reusing the micro-endstation Families, with a "(target)" model per axis carried unbound. | The nanotomography stage Model bindings. |
+| STAGE-1 | Blocks-go-live | Is the rotary stage the Lab Motion Systems RT100AX, and are its specs final? | The "(target)" RT100AX, used as the trigger master clock. | The rotary stage Model binding. |
+| STAGE-2 | Nice-to-have | Is the sample positioning stage the Lab Motion Systems XY150B-12? | The "(target)" XY150B-12. | The sample positioning Model binding. |
+
+### Detector
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | Which camera models will be procured for cameras I to IV? (Chosen in project year 2.) | Four cameras at the stated design-target sensors/speeds; models unbound. | The camera Model bindings. |
+| DET-2 | Blocks-go-live | Confirm the microscope optics model. Each Housing binds the 2-BM candidate `optique_peter_micrx080`; the TDR names only the vendor (Optique Peter), so confirm this model or name the procured alternative (project year 2). | Two microscopes (MicLFOV, MicHR) composed as `Microscope` Assemblies, Housing model bound to `optique_peter_micrx080` pending confirmation. | The microscope Model confirmation. |
+| TRIG-1 | Blocks-go-live | Will the rotary TTL (3600 pulses/rev) feed the camera triggers directly, or is an FPGA conditioner needed? | Direct TTL, no conditioner; may evolve once camera trigger requirements are firm. | The trigger/sync chain. |
diff --git a/docs/deployments/tomowise/questions.md b/docs/deployments/tomowise/questions.md
deleted file mode 100644
index dcbc926e9b1..00000000000
--- a/docs/deployments/tomowise/questions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Open questions
-
-*What CORA needs the TomoWISE team to confirm before the model can be trusted.*
-
-TomoWISE is in the design phase, so this page is long by design: almost every value on the [device pages](index.md) is a TDR design specification, not a commissioned measurement. Each row below is a fact the beamline team or the TDR owns, not a CORA modelling choice. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed (with the reason in the commit). Priorities are `Blocks-build` (needed before the model is built for real), `Blocks-go-live` (needed before first users), and `Nice-to-have`.
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-build | What are the Tango/Sardana device and attribute names for each device? | Control handles are unassigned; CORA leaves the device handle empty (no EPICS PV). | Wiring each Asset to a real control handle. |
-| PSS-1 | Blocks-build | What are the PSS permit signals and access-interlock names for the optics and experiment hutches? | Both hutches exist with permit signals to be named. | The Enclosure permit signals. |
-
-## Sources and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| OPT-1 | Nice-to-have | Which MLM coating is selected? The TDR text lists W/SiC or W/B4C; Table 8.3 lists W/Si. | The MLM is one Monochromator Asset; coating is a setting. | The MLM coating setting. |
-| LAYOUT-1 | Nice-to-have | What is the single z-coordinate reference for the layout? The TDR mixes "from the CPMU14 source" (front end) and "from the straight-section centre" (optics and downstream), about 505 mm apart. | z values are carried as approximate from-source and flagged confirm. | Exact device z positions. |
-
-## Endstations
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| NANO-1 | Blocks-go-live | Are the nanotomography sample-manipulator model bindings final? The TDR specifies the six-axis stack in Table 9.5 (tilt, coarse X/Y/Z, continuous rotary, fine Xs/Zs); only the per-axis model procurement remains. | The TDR-specified stack, reusing the micro-endstation Families, with a "(target)" model per axis carried unbound. | The nanotomography stage Model bindings. |
-| STAGE-1 | Blocks-go-live | Is the rotary stage the Lab Motion Systems RT100AX, and are its specs final? | The "(target)" RT100AX, used as the trigger master clock. | The rotary stage Model binding. |
-| STAGE-2 | Nice-to-have | Is the sample positioning stage the Lab Motion Systems XY150B-12? | The "(target)" XY150B-12. | The sample positioning Model binding. |
-
-## Detector
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | Which camera models will be procured for cameras I to IV? (Chosen in project year 2.) | Four cameras at the stated design-target sensors/speeds; models unbound. | The camera Model bindings. |
-| DET-2 | Blocks-go-live | Confirm the microscope optics model. Each Housing binds the 2-BM candidate `optique_peter_micrx080`; the TDR names only the vendor (Optique Peter), so confirm this model or name the procured alternative (project year 2). | Two microscopes (MicLFOV, MicHR) composed as `Microscope` Assemblies, Housing model bound to `optique_peter_micrx080` pending confirmation. | The microscope Model confirmation. |
-| TRIG-1 | Blocks-go-live | Will the rotary TTL (3600 pulses/rev) feed the camera triggers directly, or is an FPGA conditioner needed? | Direct TTL, no conditioner; may evolve once camera trigger requirements are firm. | The trigger/sync chain. |
diff --git a/docs/deployments/tomowise/techniques.md b/docs/deployments/tomowise/techniques.md
deleted file mode 100644
index 9e988623ac8..00000000000
--- a/docs/deployments/tomowise/techniques.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Techniques
-
-*What TomoWISE is designed to do, as intent. Design-phase.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../maxiv/index.md#the-techniques-adapted-here) is how a facility adapts it. TomoWISE is pre-build, so the techniques below are design intent: the MAX IV Practices that will bind them are carried pending on the [MAX IV site page](../maxiv/index.md#the-techniques-adapted-here). The function view survives the eventual equipment choices, which is why it can be written before the hardware is procured.
-
-The beamline's five operation modes (TDR) select the source, filtering, monochromator, and KB optics for a given technique:
-
-| Technique | Source | Monochromator | KB | What it is for |
-| --- | --- | --- | --- | --- |
-| Standard microtomography | CPMU14 | MLM | no | high-throughput monochromatic CT |
-| High-speed microtomography (small FOV) | CPMU14 | MLM or none | no | sub-micron pixel, fast dynamics |
-| Large-FOV / white-beam microtomography | 3T3PW | none | no | large or highly attenuating samples |
-| Nanotomography | CPMU14 | MLM | yes | 200-nm-class cone-beam imaging |
-| Laminography | CPMU14 | MLM | no | flat, extended samples (tilt axis, not a separate fixture) |
-
-A few points of intent shape the model:
-
-- **Source switching is first-class.** Two insertion devices (one `InsertionDevice` Family, two Assets) are selected per mode, unlike the single bending-magnet source at 2-BM. The mode determines which is in the beam.
-- **Laminography is a tilt setpoint, not a separate station.** It runs on the microtomography endstation's tilt axis, mirroring the 2-BM laminography decision: the same installed stack, a different Method, not a new Fixture.
-- **Monochromatic and white-beam are the same beamline.** Inserting or bypassing the MLM (and the filter chain) picks the spectrum; it is an operation mode over one set of optics, not two beamlines.
-
-The concrete acquisition recipes (scan sequences, energies, exposure) are not written yet; they join as the beamline approaches commissioning. See [Open questions](questions.md) for what must be confirmed first.
diff --git a/docs/deployments/tps-05a/governance.md b/docs/deployments/tps-05a/governance.md
deleted file mode 100644
index 9c737fa3a8f..00000000000
--- a/docs/deployments/tps-05a/governance.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Governance
-
-*Who may act at TPS 05A and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSRRC Site](../nsrrc/index.md#safety-and-governance); on the beamline they surface through the actions they take. TPS 05A's governance is **identical to [TPS 07A](../tps-07a/governance.md)'s**, because both beamlines share the one NSRRC Site: the same principals, the same LDAP-backed staff (`ldap://10.7.1.1`), and the same mandatory radiation-safety-training portal (`safetytraining.nsrrc.org.tw`). The human roster is not in public source (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSRRC Site. A TPS 05A beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site, and at 05A it is literally reused from 07A, both share the NSRRC Site, so the second beamline registers no new facility principals. That reuse is the point: the Access kernel scopes at the Site, not per-beamline.
-
-The NSRRC mandatory training portal maps to CORA's **worldwide-invariant training axis**: a fact carried on the Access principals, not a separate Clearance kind (GOV-1).
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer or its LDAP groups. It holds across the seam: a command CORA's EdgeConductor issues in place of DCSS (start an oscillation, drive a motor, arm the detector) is gated exactly as any spine command is. The facility proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Unattended autonomous collection
-
-TPS 05A's throughput model is unattended, the same as 07A: the ISARA robot mounts a crystal, the MD3 centres it (mesh scan), the EIGER2 collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
-
-The PSS search-and-secure permit leaves that gate the hutch are not in public source (PSS-1) and are carried as a confirm.
diff --git a/docs/deployments/tps-05a/model.md b/docs/deployments/tps-05a/model.md
deleted file mode 100644
index 792d7944d4a..00000000000
--- a/docs/deployments/tps-05a/model.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's TPS 05A content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at TPS 05A |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (TPS-05A-OH optics, TPS-05A-EH experiment) |
-| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [NSRRC Site](../nsrrc/index.md), [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines and especially its sibling [TPS 07A](../tps-07a/model.md). Left out on purpose:
-
-- **No new Family.** TPS 05A reuses every Family TPS 07A binds: the graduated `Goniometer` for the MD3, `Camera` for the EIGER2 / OAV, `Monochromator`, `Filter`, `BeamStop`, `Shutter`, `Mirror`, `TemperatureController`, `LinearStage` / `MotionController`, plus the loose `StorageRing` and `PositionMonitor`. The only device-level difference from 07A is the EIGER2 size (9M vs 16M), a per-Asset fact.
-- **No new Site, principals, or seam.** The NSRRC Site, its Access principals, and the Blu-Ice/DCSS-over-EPICS seam were all created by 07A; 05A reuses them unchanged. This is the deployment's whole point: demonstrating that the Site, the device-library, and the seam generalize across the MX cluster.
-- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 / 07A / MX3 shape.
-- **The frame egress and any mesh-scan compute.** The EIGER2 frame stream is a `TransferPort` leg into the Dataset of record; spot-scoring / indexing is `ComputePort` work, an Observe / Compute leg off the control seam (DET-1).
-- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods, recorded as the `TPS05A_*` Practices on the Site; 05A reinforces the case at a further MX deployment without coining any (TECH-1).
-- **A verified PV namespace.** Unlike 07A (whose `07a:` / `07a-ES:` namespace was read from its control tree), 05A has no dedicated public tree, so its `05a:` / `05a-ES:` namespace is inferred by cluster convention and carried pending (PV-1), the fleet's most conservative PV posture.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/tps-05a/notes.md b/docs/deployments/tps-05a/notes.md
new file mode 100644
index 00000000000..eed0d0b3b9d
--- /dev/null
+++ b/docs/deployments/tps-05a/notes.md
@@ -0,0 +1,118 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at TPS 05A: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [NSRRC Practice](../nsrrc/index.md#the-techniques-adapted-here). TPS 05A reuses the same MX Methods as [TPS 07A](../tps-07a/notes.md#techniques) and Diamond [I03](../i03/notes.md#techniques), so it coins nothing new.*
+
+TPS 05A's technique, rotation MX (in its microcrystallography form), is the macromolecular-crystallography shape CORA already saw at i03, TPS 07A, and MX3. The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the EIGER2 X 9M, orchestrated through Blu-Ice/DCSS; the i03 Method, pending (TECH-1) |
+| Mesh / grid scan | `grid_scan` | mesh scan for crystal location / centring on the MD3; the i03 Method (TECH-1) |
+| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
+
+All three are recorded as pending [Practices](../nsrrc/index.md#the-techniques-adapted-here) on the NSRRC Site (the `TPS05A_*` practices), reusing the same Method names TPS 07A and Diamond i03 carry.
+
+### Why the Methods are reused, not coined
+
+TPS 05A brings nothing new at the technique layer: it is the MX-cluster sibling of TPS 07A. Rotation MX, mesh-scan centring, and robot sample exchange are the i03 shapes, so 05A binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and 05A reinforces the case at a **further MX deployment** (after i03, NSLS-II FMX / AMX, MX3, Sirius MANACA, and TPS 07A). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the EIGER2 presents Detector via `Camera`), so nothing new is needed in the device model either.
+
+The autonomous sample exchange reuses the i03 / i24 / 07A / MX3 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1).
+
+TPS 05A contributes no new vocabulary anywhere; its value is reinforcing that the NSRRC Site, the Blu-Ice/DCSS-over-EPICS seam, and the MX Methods cover the cluster, not just 07A.
+
+## Governance
+
+*Who may act at TPS 05A and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSRRC Site](../nsrrc/index.md#safety-and-governance); on the beamline they surface through the actions they take. TPS 05A's governance is **identical to [TPS 07A](../tps-07a/notes.md#governance)'s**, because both beamlines share the one NSRRC Site: the same principals, the same LDAP-backed staff (`ldap://10.7.1.1`), and the same mandatory radiation-safety-training portal (`safetytraining.nsrrc.org.tw`). The human roster is not in public source (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSRRC Site. A TPS 05A beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site, and at 05A it is literally reused from 07A, both share the NSRRC Site, so the second beamline registers no new facility principals. That reuse is the point: the Access kernel scopes at the Site, not per-beamline.
+
+The NSRRC mandatory training portal maps to CORA's **worldwide-invariant training axis**: a fact carried on the Access principals, not a separate Clearance kind (GOV-1).
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer or its LDAP groups. It holds across the seam: a command CORA's EdgeConductor issues in place of DCSS (start an oscillation, drive a motor, arm the detector) is gated exactly as any spine command is. The facility proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Unattended autonomous collection
+
+TPS 05A's throughput model is unattended, the same as 07A: the ISARA robot mounts a crystal, the MD3 centres it (mesh scan), the EIGER2 collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+The PSS search-and-secure permit leaves that gate the hutch are not in public source (PSS-1) and are carried as a confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's TPS 05A content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at TPS 05A |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (TPS-05A-OH optics, TPS-05A-EH experiment) |
+| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [NSRRC Site](../nsrrc/index.md), [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines and especially its sibling [TPS 07A](../tps-07a/notes.md#model). Left out on purpose:
+
+- **No new Family.** TPS 05A reuses every Family TPS 07A binds: the graduated `Goniometer` for the MD3, `Camera` for the EIGER2 / OAV, `Monochromator`, `Filter`, `BeamStop`, `Shutter`, `Mirror`, `TemperatureController`, `LinearStage` / `MotionController`, plus the loose `StorageRing` and `PositionMonitor`. The only device-level difference from 07A is the EIGER2 size (9M vs 16M), a per-Asset fact.
+- **No new Site, principals, or seam.** The NSRRC Site, its Access principals, and the Blu-Ice/DCSS-over-EPICS seam were all created by 07A; 05A reuses them unchanged. This is the deployment's whole point: demonstrating that the Site, the device-library, and the seam generalize across the MX cluster.
+- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 / 07A / MX3 shape.
+- **The frame egress and any mesh-scan compute.** The EIGER2 frame stream is a `TransferPort` leg into the Dataset of record; spot-scoring / indexing is `ComputePort` work, an Observe / Compute leg off the control seam (DET-1).
+- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods, recorded as the `TPS05A_*` Practices on the Site; 05A reinforces the case at a further MX deployment without coining any (TECH-1).
+- **A verified PV namespace.** Unlike 07A (whose `07a:` / `07a-ES:` namespace was read from its control tree), 05A has no dedicated public tree, so its `05a:` / `05a-ES:` namespace is inferred by cluster convention and carried pending (PV-1), the fleet's most conservative PV posture.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the NSRRC / TPS 05A team to confirm. This model is reverse-engineered from public open source, but TPS 05A's source is thinner than [TPS 07A](../tps-07a/notes.md#open-questions)'s: there is no dedicated 05A control tree (the public `NSRRC_TPS05A_BeamMonitor` repo is an empty stub), so the device kit is read from the [SPXF facility pages](https://nsrrcspxf.github.io/nsrrcspxf/index.html) and the 2025 J. Synchrotron Rad. cluster paper, and the seam / PV model is inherited from the 07A reading. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Provenance (05A-specific)
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| PV-1 | Blocks-go-live | The EPICS PV namespace. 07A's `07a:` / `07a-ES:` was read from its control tree; 05A has no public tree, so its namespace is **inferred** as `05a:` / `05a-ES:` by cluster convention. Is that correct? | The 05A beamline namespace is `05a:` and the endstation `05a-ES:`, inferred, not verified. | The PV namespace for every Asset. |
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The insertion-device / front-end source: TPS 05A is fed by a TPS undulator (per the SPXF page), but no source PV is in public source. | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. No PSS permit signals are in public source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? Public source exposes no enclosure structure. | An optics hutch (DCM, mirrors) plus an experiment hutch (the MD3 / EIGER2 / robot). | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The double-crystal monochromator crystal cut and exact range, and the attenuator foil set. | A Si DCM over ~5.7-20 keV and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
+| OPT-1 | Nice-to-have | The focusing optic and the microcrystallography spot size (not stated in public source for 05A). | A KB focusing mirror system (`KBMirrors`, Mirror family), configuration and spot blank. | The mirror Assets, spot size, and PVs. |
+| ENERGY-1 | Nice-to-have | Does TPS 05A scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
+
+### Sample, detector, robot
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer axis PV records, the full axis set, and the settling confirmation that 05A's live scan orchestration is Blu-Ice/DCSS and not a live MXCuBE deployment (the 2025 cluster paper says Blu-Ice/DCS for all three MX endstations; high confidence, but per-beamline confirmation is owed). | A `Goniometer` Asset on the EPICS floor; the DCSS-over-EPICS seam (the 07A / 2-BM pattern), not MXCuBE; PV records deployment config. | The Goniometer interface, axes, and the seam confirmation. |
+| DET-1 | Blocks-go-live | The EIGER2 X 9M detector PV records, its SIMPLON REST endpoint, and any detector minimum-distance interlock (07A has one at 139 mm; 05A's is unknown). | An EIGER2 X 9M `Camera` commanded through the DCSS workflow; endpoint and interlock deployment config. | The detector interface and safety limit. |
+| ENV-1 | Nice-to-have | The cryostream sample-cooling vendor and PV. | A `TemperatureController` Asset, settings blank. | The cryostream Model and PV. |
+| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (the same model as 07A). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the i03 / i24 / 07A / MX3 shape. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
+| DIAG-1 | Nice-to-have | The beam-position / XBPM and OAV-camera channel maps and PVs. | Read-only beam-position (graduated catalog `PositionMonitor`) and OAV (`Camera`) probes; channel maps blank. | The diagnostic bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs behind the endstation, goniometer-base, and detector stages. | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the MX Capabilities enter CORA's catalog, or stay deferred? The same owner-scope decision i03 opened; 05A reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
diff --git a/docs/deployments/tps-05a/questions.md b/docs/deployments/tps-05a/questions.md
deleted file mode 100644
index b1a1105e844..00000000000
--- a/docs/deployments/tps-05a/questions.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Open questions
-
-*What CORA needs the NSRRC / TPS 05A team to confirm. This model is reverse-engineered from public open source, but TPS 05A's source is thinner than [TPS 07A](../tps-07a/questions.md)'s: there is no dedicated 05A control tree (the public `NSRRC_TPS05A_BeamMonitor` repo is an empty stub), so the device kit is read from the [SPXF facility pages](https://nsrrcspxf.github.io/nsrrcspxf/index.html) and the 2025 J. Synchrotron Rad. cluster paper, and the seam / PV model is inherited from the 07A reading. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Provenance (05A-specific)
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| PV-1 | Blocks-go-live | The EPICS PV namespace. 07A's `07a:` / `07a-ES:` was read from its control tree; 05A has no public tree, so its namespace is **inferred** as `05a:` / `05a-ES:` by cluster convention. Is that correct? | The 05A beamline namespace is `05a:` and the endstation `05a-ES:`, inferred, not verified. | The PV namespace for every Asset. |
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The insertion-device / front-end source: TPS 05A is fed by a TPS undulator (per the SPXF page), but no source PV is in public source. | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. No PSS permit signals are in public source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? Public source exposes no enclosure structure. | An optics hutch (DCM, mirrors) plus an experiment hutch (the MD3 / EIGER2 / robot). | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The double-crystal monochromator crystal cut and exact range, and the attenuator foil set. | A Si DCM over ~5.7-20 keV and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
-| OPT-1 | Nice-to-have | The focusing optic and the microcrystallography spot size (not stated in public source for 05A). | A KB focusing mirror system (`KBMirrors`, Mirror family), configuration and spot blank. | The mirror Assets, spot size, and PVs. |
-| ENERGY-1 | Nice-to-have | Does TPS 05A scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
-
-## Sample, detector, robot
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer axis PV records, the full axis set, and the settling confirmation that 05A's live scan orchestration is Blu-Ice/DCSS and not a live MXCuBE deployment (the 2025 cluster paper says Blu-Ice/DCS for all three MX endstations; high confidence, but per-beamline confirmation is owed). | A `Goniometer` Asset on the EPICS floor; the DCSS-over-EPICS seam (the 07A / 2-BM pattern), not MXCuBE; PV records deployment config. | The Goniometer interface, axes, and the seam confirmation. |
-| DET-1 | Blocks-go-live | The EIGER2 X 9M detector PV records, its SIMPLON REST endpoint, and any detector minimum-distance interlock (07A has one at 139 mm; 05A's is unknown). | An EIGER2 X 9M `Camera` commanded through the DCSS workflow; endpoint and interlock deployment config. | The detector interface and safety limit. |
-| ENV-1 | Nice-to-have | The cryostream sample-cooling vendor and PV. | A `TemperatureController` Asset, settings blank. | The cryostream Model and PV. |
-| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (the same model as 07A). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the i03 / i24 / 07A / MX3 shape. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
-| DIAG-1 | Nice-to-have | The beam-position / XBPM and OAV-camera channel maps and PVs. | Read-only beam-position (graduated catalog `PositionMonitor`) and OAV (`Camera`) probes; channel maps blank. | The diagnostic bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs behind the endstation, goniometer-base, and detector stages. | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the MX Capabilities enter CORA's catalog, or stay deferred? The same owner-scope decision i03 opened; 05A reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
diff --git a/docs/deployments/tps-05a/techniques.md b/docs/deployments/tps-05a/techniques.md
deleted file mode 100644
index db78155ada0..00000000000
--- a/docs/deployments/tps-05a/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What CORA would run at TPS 05A: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [NSRRC Practice](../nsrrc/index.md#the-techniques-adapted-here). TPS 05A reuses the same MX Methods as [TPS 07A](../tps-07a/techniques.md) and Diamond [I03](../i03/techniques.md), so it coins nothing new.*
-
-TPS 05A's technique, rotation MX (in its microcrystallography form), is the macromolecular-crystallography shape CORA already saw at i03, TPS 07A, and MX3. The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the EIGER2 X 9M, orchestrated through Blu-Ice/DCSS; the i03 Method, pending (TECH-1) |
-| Mesh / grid scan | `grid_scan` | mesh scan for crystal location / centring on the MD3; the i03 Method (TECH-1) |
-| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
-
-All three are recorded as pending [Practices](../nsrrc/index.md#the-techniques-adapted-here) on the NSRRC Site (the `TPS05A_*` practices), reusing the same Method names TPS 07A and Diamond i03 carry.
-
-## Why the Methods are reused, not coined
-
-TPS 05A brings nothing new at the technique layer: it is the MX-cluster sibling of TPS 07A. Rotation MX, mesh-scan centring, and robot sample exchange are the i03 shapes, so 05A binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and 05A reinforces the case at a **further MX deployment** (after i03, NSLS-II FMX / AMX, MX3, Sirius MANACA, and TPS 07A). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the EIGER2 presents Detector via `Camera`), so nothing new is needed in the device model either.
-
-The autonomous sample exchange reuses the i03 / i24 / 07A / MX3 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1).
-
-TPS 05A contributes no new vocabulary anywhere; its value is reinforcing that the NSRRC Site, the Blu-Ice/DCSS-over-EPICS seam, and the MX Methods cover the cluster, not just 07A.
diff --git a/docs/deployments/tps-07a/governance.md b/docs/deployments/tps-07a/governance.md
deleted file mode 100644
index ec1701efd55..00000000000
--- a/docs/deployments/tps-07a/governance.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Governance
-
-*Who may act at TPS 07A and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSRRC Site](../nsrrc/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the public control trees (GOV-1), so the principals are the design shape, not a registered list. The trees do expose two governance facts CORA maps onto its own model: LDAP-backed authentication (`ldap://10.7.1.1`) and a mandatory radiation-safety-training portal (`safetytraining.nsrrc.org.tw`).
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSRRC Site. A TPS 07A beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site; NSRRC being a new Site is exactly the test that the Federation / Access kernel ports unchanged.
-
-The NSRRC mandatory training portal maps to CORA's **worldwide-invariant training axis**: a fact carried on the Access principals (has-this-person-completed-the-required-training), not a separate Clearance kind. CORA records it as a property of the principal rather than coining a new facility form (GOV-1).
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer or its LDAP groups. It holds across the seam: a command CORA's EdgeConductor issues in place of DCSS (start an oscillation, drive a motor, arm the detector) is gated exactly as any spine command is. The facility proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## Unattended autonomous collection
-
-TPS 07A's throughput model is unattended: the ISARA robot mounts a crystal, the MD3 centres it (mesh scan + Dozor scoring), the EIGER2 collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough (the CHiMP crystal-detection output is the natural input), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
-
-## The detector safety interlock
-
-The control tree exposes a hard detector minimum-distance interlock (139 mm): the detector stage may not approach the sample closer than that. This is a floor-level hardware safety limit, not a CORA-owned gate; CORA's conduct path respects it as a constraint on the detector-distance command, the same way it respects an EPICS soft limit. The PSS search-and-secure permit leaves that gate the hutch are not in the public source (PSS-1) and are carried as a confirm.
diff --git a/docs/deployments/tps-07a/model.md b/docs/deployments/tps-07a/model.md
deleted file mode 100644
index c47ab6aa776..00000000000
--- a/docs/deployments/tps-07a/model.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's TPS 07A content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at TPS 07A |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (TPS-07A-OH optics, TPS-07A-EH experiment) |
-| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [NSRRC Site](../nsrrc/index.md), [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines. Left out on purpose:
-
-- **No new Family.** TPS 07A's novelty is the Site and the seam, not its devices: the MD3 goniometer binds the graduated `Goniometer` (the i03 / MX3 MX precedent), the detectors `Camera`, the DCM `Monochromator`, the cryostream `TemperatureController`, the attenuator `Filter`, the beamstop `BeamStop`, the shutters `Shutter`, the mirrors `Mirror`, the stages `LinearStage` / `MotionController`.
-- **The reused loose families.** `StorageRing` (the ring-current monitor) and `BeamPositionMonitor` (the beam-position diagnostic) are bound loose, each already allowlisted from earlier deployments; TPS 07A coins no new loose family.
-- **The DCSS-over-EPICS seam.** TPS 07A drives a single EPICS floor with a Blu-Ice/DCSS orchestration layer above it, reached through an EPICS Device Handler Server. This is modelled as `ControlPort` actuation over EPICS plus a CORA EdgeConductor that replaces the DCSS orchestration, not new aggregates; it is the 2-BM TomoScan seam, not the MX3 multi-transport seam. See [Controls](controls.md). The MD3 axis PV records and the DCSS-vs-MXCuBE confirmation are GONIO-1.
-- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 / MX3 shape, not a new device family.
-- **The frame egress and mesh-scan compute.** The EIGER2 ZMQ / ASAP::O frame stream is a `TransferPort` leg into the Dataset of record; the Dozor spot-scoring and CHiMP crystal-detection are `ComputePort` work, an Observe / Compute leg off the control seam, not beamline Methods or Assets (DET-1).
-- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods (`mx_data_collection` / `grid_scan` / `sample_exchange`), recorded as Practices on the Site; TPS 07A reinforces the case at a further MX facility without coining any (TECH-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/tps-07a/notes.md b/docs/deployments/tps-07a/notes.md
new file mode 100644
index 00000000000..c42426edfca
--- /dev/null
+++ b/docs/deployments/tps-07a/notes.md
@@ -0,0 +1,115 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at TPS 07A: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [NSRRC Practice](../nsrrc/index.md#the-techniques-adapted-here). TPS 07A reuses the MX Methods Diamond [I03](../i03/notes.md#techniques) introduced, so it coins nothing new.*
+
+TPS 07A's technique, rotation MX, is the macromolecular-crystallography shape CORA already saw at i03 (and at the Australian Synchrotron [MX3](../mx3/notes.md#techniques), and in its serial form at i24 and LCLS-MFX). The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog, exactly as at i03 and MX3.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the EIGER2 X 16M, orchestrated through Blu-Ice/DCSS; the i03 Method, pending (TECH-1) |
+| Mesh / grid scan | `grid_scan` | mesh scan for crystal location / centring on the MD3, with Dozor spot-scoring (the Meshbest path); the i03 Method (TECH-1) |
+| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
+
+All three are recorded as pending [Practices](../nsrrc/index.md#the-techniques-adapted-here) on the NSRRC Site, reusing the same Method names Diamond i03 carries.
+
+### Why the Methods are reused, not coined
+
+TPS 07A brings a new Site and a new seam, not a new technique. Rotation MX, mesh-scan centring, and robot sample exchange are the i03 shapes, so TPS 07A binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and TPS 07A reinforces the case at a further MX facility (after i03, NSLS-II FMX / AMX, MX3, and Sirius MANACA). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the EIGER2 presents Detector via `Camera`), so nothing new is needed in the device model either.
+
+The autonomous sample exchange reuses the i03 / i24 / MX3 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1). The mesh-scan Dozor spot-scoring and CHiMP crystal detection are `ComputePort` work (an Observe / Compute leg), not beamline Methods.
+
+The genuinely new things TPS 07A contributes are below the technique layer: a new Site (NSRRC) and the Blu-Ice/DCSS-over-EPICS orchestration seam at an MX beamline (see [Controls](controls.md)), which the technique vocabulary rides over unchanged.
+
+## Governance
+
+*Who may act at TPS 07A and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSRRC Site](../nsrrc/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not in the public control trees (GOV-1), so the principals are the design shape, not a registered list. The trees do expose two governance facts CORA maps onto its own model: LDAP-backed authentication (`ldap://10.7.1.1`) and a mandatory radiation-safety-training portal (`safetytraining.nsrrc.org.tw`).
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSRRC Site. A TPS 07A beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority. This is the same role kernel CORA seeds at every Site; NSRRC being a new Site is exactly the test that the Federation / Access kernel ports unchanged.
+
+The NSRRC mandatory training portal maps to CORA's **worldwide-invariant training axis**: a fact carried on the Access principals (has-this-person-completed-the-required-training), not a separate Clearance kind. CORA records it as a property of the principal rather than coining a new facility form (GOV-1).
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start a collection, move the robot, change the energy, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer or its LDAP groups. It holds across the seam: a command CORA's EdgeConductor issues in place of DCSS (start an oscillation, drive a motor, arm the detector) is gated exactly as any spine command is. The facility proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### Unattended autonomous collection
+
+TPS 07A's throughput model is unattended: the ISARA robot mounts a crystal, the MD3 centres it (mesh scan + Dozor scoring), the EIGER2 collects, the robot unmounts, repeat. That loop is where CORA's custody and trust shapes earn their keep, each crystal threaded through the `Subject` aggregate so its identity and provenance is tracked, the exchange a Procedure gated by a Clearance (ROBOT-1). If an autonomous Agent were added to choose which crystal to collect or when a dataset is good enough (the CHiMP crystal-detection output is the natural input), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+### The detector safety interlock
+
+The control tree exposes a hard detector minimum-distance interlock (139 mm): the detector stage may not approach the sample closer than that. This is a floor-level hardware safety limit, not a CORA-owned gate; CORA's conduct path respects it as a constraint on the detector-distance command, the same way it respects an EPICS soft limit. The PSS search-and-secure permit leaves that gate the hutch are not in the public source (PSS-1) and are carried as a confirm.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's TPS 07A content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at TPS 07A |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (TPS-07A-OH optics, TPS-07A-EH experiment) |
+| Facility (Federation); Zone, Conduit, Policy (Trust); Actor (Access) | [NSRRC Site](../nsrrc/index.md), [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other reverse-engineered beamlines. Left out on purpose:
+
+- **No new Family.** TPS 07A's novelty is the Site and the seam, not its devices: the MD3 goniometer binds the graduated `Goniometer` (the i03 / MX3 MX precedent), the detectors `Camera`, the DCM `Monochromator`, the cryostream `TemperatureController`, the attenuator `Filter`, the beamstop `BeamStop`, the shutters `Shutter`, the mirrors `Mirror`, the stages `LinearStage` / `MotionController`.
+- **The reused loose families.** `StorageRing` (the ring-current monitor) and `BeamPositionMonitor` (the beam-position diagnostic) are bound loose, each already allowlisted from earlier deployments; TPS 07A coins no new loose family.
+- **The DCSS-over-EPICS seam.** TPS 07A drives a single EPICS floor with a Blu-Ice/DCSS orchestration layer above it, reached through an EPICS Device Handler Server. This is modelled as `ControlPort` actuation over EPICS plus a CORA EdgeConductor that replaces the DCSS orchestration, not new aggregates; it is the 2-BM TomoScan seam, not the MX3 multi-transport seam. See [Controls](controls.md). The MD3 axis PV records and the DCSS-vs-MXCuBE confirmation are GONIO-1.
+- **The ISARA robot as a Procedure.** Autonomous sample exchange is a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i24 / MX3 shape, not a new device family.
+- **The frame egress and mesh-scan compute.** The EIGER2 ZMQ / ASAP::O frame stream is a `TransferPort` leg into the Dataset of record; the Dozor spot-scoring and CHiMP crystal-detection are `ComputePort` work, an Observe / Compute leg off the control seam, not beamline Methods or Assets (DET-1).
+- **No new Capability or Method.** Rotation MX reuses the pending i03 Methods (`mx_data_collection` / `grid_scan` / `sample_exchange`), recorded as Practices on the Site; TPS 07A reinforces the case at a further MX facility without coining any (TECH-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the NSRRC / TPS 07A team to confirm. This model is reverse-engineered from public open source (the [`light911/NSRRC_TPS07A`](https://github.com/light911/NSRRC_TPS07A) control tree and [`light911/TPS07A-Meshbest`](https://github.com/light911/TPS07A-Meshbest) app): the EPICS PV namespace (`07a:` / `07a-ES:`) is read from it, but per-device PV records, vendor identities, physical positions, the source, and the PSS signals are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The insertion-device / front-end source: TPS 07A is fed by the IU22 in-vacuum undulator (per the SPXF spec page), but no source PV is in the public tree. | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. No PSS permit signals are in the public source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? The trees expose no enclosure structure. | An optics hutch (DCM, mirrors) plus an experiment hutch (the MD3 / EIGER2 / robot). | The Enclosure set and roles. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The double-crystal monochromator crystal cut and exact range, and the attenuator foil set. | A Si DCM over 6-20 keV and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
+| OPT-1 | Nice-to-have | The micro-focus optic delivering the ~2.9 x 1.8 micron spot: is it a KB mirror pair, and what are its PVs? The SPXF page states the focal spot, not the optic. | A KB micro-focus mirror system (`KBMirrors`, Mirror family), configuration blank. | The mirror Assets and PVs. |
+| ENERGY-1 | Nice-to-have | Does TPS 07A scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
+
+### Sample, detector, robot
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer axis PV records (`07a-ES:` namespace, reached through the EPICS DHS), the full axis set, and the settling confirmation that the live scan orchestration is Blu-Ice/DCSS and not a live MXCuBE `mxcubecore` HardwareObjects deployment. (Public evidence is high-confidence DCSS; a live MXCuBE config for 07A would flip the seam to mixed.) | A `Goniometer` Asset (omega / kappa / phi + centring / alignment) on the EPICS floor; the DCSS-over-EPICS seam (the 2-BM pattern), not MXCuBE; PV records deployment config. | The Goniometer interface, axes, and the seam confirmation. |
+| DET-1 | Blocks-go-live | The EIGER2 X 16M detector PV records and its SIMPLON REST endpoint, and whether the ZMQ frame egress has migrated to DESY ASAP::O in production. | An EIGER2 `Camera` commanded through the DCSS workflow; frames over ZMQ migrating to ASAP::O; endpoint deployment config. | The detector Model, interface, and frame-egress path. |
+| ENV-1 | Nice-to-have | The cryostream sample-cooling vendor and PV. | A `TemperatureController` Asset, settings blank. | The cryostream Model and PV. |
+| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (mount / unmount trajectories gated on the MD3 state). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the i03 / i24 / MX3 loops. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
+| DIAG-1 | Nice-to-have | The beam-position / XBPM and OAV-camera channel maps and PVs. | Read-only beam-position (graduated catalog `PositionMonitor`) and OAV (`Camera`) probes; channel maps blank. | The diagnostic bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs behind the endstation, goniometer-base, and detector stages (EPICS motor records reached through the DHS). | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the MX Capabilities (rotation data collection, mesh / grid scan) enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i03 opened; TPS 07A reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
+| GOV-1 | Nice-to-have | The operator / beamline-scientist roster and review structure (the trees show LDAP auth at `ldap://10.7.1.1` and a mandatory training portal at `safetytraining.nsrrc.org.tw`, but no roster). | CORA's role kernel scoped at the Site; the training portal maps to the worldwide-invariant training axis on the principal. | The Actor roster and training-axis binding. |
diff --git a/docs/deployments/tps-07a/questions.md b/docs/deployments/tps-07a/questions.md
deleted file mode 100644
index af5a4b383a4..00000000000
--- a/docs/deployments/tps-07a/questions.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Open questions
-
-*What CORA needs the NSRRC / TPS 07A team to confirm. This model is reverse-engineered from public open source (the [`light911/NSRRC_TPS07A`](https://github.com/light911/NSRRC_TPS07A) control tree and [`light911/TPS07A-Meshbest`](https://github.com/light911/TPS07A-Meshbest) app): the EPICS PV namespace (`07a:` / `07a-ES:`) is read from it, but per-device PV records, vendor identities, physical positions, the source, and the PSS signals are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The insertion-device / front-end source: TPS 07A is fed by the IU22 in-vacuum undulator (per the SPXF spec page), but no source PV is in the public tree. | An insertion-device source, identity-only, no PV; the ring-current monitor stands in as the source representation. | The Source Asset and its PV. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. No PSS permit signals are in the public source. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENC-1 | Nice-to-have | The hutch layout and names: which devices sit in the optics hutch versus the experiment hutch? The trees expose no enclosure structure. | An optics hutch (DCM, mirrors) plus an experiment hutch (the MD3 / EIGER2 / robot). | The Enclosure set and roles. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The double-crystal monochromator crystal cut and exact range, and the attenuator foil set. | A Si DCM over 6-20 keV and one Filter Asset, settings blank. | The Monochromator / Filter settings. |
-| OPT-1 | Nice-to-have | The micro-focus optic delivering the ~2.9 x 1.8 micron spot: is it a KB mirror pair, and what are its PVs? The SPXF page states the focal spot, not the optic. | A KB micro-focus mirror system (`KBMirrors`, Mirror family), configuration blank. | The mirror Assets and PVs. |
-| ENERGY-1 | Nice-to-have | Does TPS 07A scan energy as the measurement (anomalous / MAD MX), or run fixed-energy per dataset? | Fixed-energy; the master energy axis is a setpoint. | The energy Capability decision. |
-
-## Sample, detector, robot
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| GONIO-1 | Blocks-go-live | The MD3 microdiffractometer axis PV records (`07a-ES:` namespace, reached through the EPICS DHS), the full axis set, and the settling confirmation that the live scan orchestration is Blu-Ice/DCSS and not a live MXCuBE `mxcubecore` HardwareObjects deployment. (Public evidence is high-confidence DCSS; a live MXCuBE config for 07A would flip the seam to mixed.) | A `Goniometer` Asset (omega / kappa / phi + centring / alignment) on the EPICS floor; the DCSS-over-EPICS seam (the 2-BM pattern), not MXCuBE; PV records deployment config. | The Goniometer interface, axes, and the seam confirmation. |
-| DET-1 | Blocks-go-live | The EIGER2 X 16M detector PV records and its SIMPLON REST endpoint, and whether the ZMQ frame egress has migrated to DESY ASAP::O in production. | An EIGER2 `Camera` commanded through the DCSS workflow; frames over ZMQ migrating to ASAP::O; endpoint deployment config. | The detector Model, interface, and frame-egress path. |
-| ENV-1 | Nice-to-have | The cryostream sample-cooling vendor and PV. | A `TemperatureController` Asset, settings blank. | The cryostream Model and PV. |
-| ROBOT-1 | Nice-to-have | The ISARA sample-mounting robot (mount / unmount trajectories gated on the MD3 state). CORA would model autonomous sample exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the i03 / i24 / MX3 loops. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-exchange Procedure and Subject custody thread. |
-| DIAG-1 | Nice-to-have | The beam-position / XBPM and OAV-camera channel maps and PVs. | Read-only beam-position (graduated catalog `PositionMonitor`) and OAV (`Camera`) probes; channel maps blank. | The diagnostic bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box firmware / IPs behind the endstation, goniometer-base, and detector stages (EPICS motor records reached through the DHS). | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the MX Capabilities (rotation data collection, mesh / grid scan) enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i03 opened; TPS 07A reuses the pending `mx_data_collection` / `grid_scan` / `sample_exchange` Methods. | Methods deferred (pending Practices on the Site), no catalog Method coined. | The MX Capability scope. |
-| GOV-1 | Nice-to-have | The operator / beamline-scientist roster and review structure (the trees show LDAP auth at `ldap://10.7.1.1` and a mandatory training portal at `safetytraining.nsrrc.org.tw`, but no roster). | CORA's role kernel scoped at the Site; the training portal maps to the worldwide-invariant training axis on the principal. | The Actor roster and training-axis binding. |
diff --git a/docs/deployments/tps-07a/techniques.md b/docs/deployments/tps-07a/techniques.md
deleted file mode 100644
index 1300e6055ee..00000000000
--- a/docs/deployments/tps-07a/techniques.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Techniques
-
-*What CORA would run at TPS 07A: rotation macromolecular crystallography, each technique a [Catalog](../../catalog/methods.md) Method bound through an [NSRRC Practice](../nsrrc/index.md#the-techniques-adapted-here). TPS 07A reuses the MX Methods Diamond [I03](../i03/techniques.md) introduced, so it coins nothing new.*
-
-TPS 07A's technique, rotation MX, is the macromolecular-crystallography shape CORA already saw at i03 (and at the Australian Synchrotron [MX3](../mx3/techniques.md), and in its serial form at i24 and LCLS-MFX). The Methods render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog, exactly as at i03 and MX3.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| Rotation MX data collection | `mx_data_collection` | oscillation collection on the MD3 goniometer + the EIGER2 X 16M, orchestrated through Blu-Ice/DCSS; the i03 Method, pending (TECH-1) |
-| Mesh / grid scan | `grid_scan` | mesh scan for crystal location / centring on the MD3, with Dozor spot-scoring (the Meshbest path); the i03 Method (TECH-1) |
-| Autonomous sample exchange | `sample_exchange` | the ISARA robot load / centre / collect / unmount loop, a Procedure over the spine (ROBOT-1) |
-
-All three are recorded as pending [Practices](../nsrrc/index.md#the-techniques-adapted-here) on the NSRRC Site, reusing the same Method names Diamond i03 carries.
-
-## Why the Methods are reused, not coined
-
-TPS 07A brings a new Site and a new seam, not a new technique. Rotation MX, mesh-scan centring, and robot sample exchange are the i03 shapes, so TPS 07A binds the same pending Methods (`mx_data_collection`, `grid_scan`, `sample_exchange`) rather than coining anything; whether those Methods enter the catalog is the cross-facility owner-scope decision i03 opened (TECH-1), and TPS 07A reinforces the case at a further MX facility (after i03, NSLS-II FMX / AMX, MX3, and Sirius MANACA). The device Roles already exist (the MD3 presents Positioner via the graduated `Goniometer`, the EIGER2 presents Detector via `Camera`), so nothing new is needed in the device model either.
-
-The autonomous sample exchange reuses the i03 / i24 / MX3 autonomous-loop shape: a Procedure over the spine threaded through `Subject` custody, not a new device family (ROBOT-1). The mesh-scan Dozor spot-scoring and CHiMP crystal detection are `ComputePort` work (an Observe / Compute leg), not beamline Methods.
-
-The genuinely new things TPS 07A contributes are below the technique layer: a new Site (NSRRC) and the Blu-Ice/DCSS-over-EPICS orchestration seam at an MX beamline (see [Controls](controls.md)), which the technique vocabulary rides over unchanged.
diff --git a/docs/deployments/xfm/governance.md b/docs/deployments/xfm/governance.md
deleted file mode 100644
index 2fd15332fe5..00000000000
--- a/docs/deployments/xfm/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at XFM and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An XFM beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, start a raster map, run the Maia fly-scan, change the focusing optic, override a caution, or commit an energy calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## The scanning map under custody
-
-XFM's defining operation is the raster XRF map: the UTS stage sweeps the sample through the focused spot while the detectors count per pixel. CORA's Campaign and Trust shapes are where that resolves: starting a map (step or Maia fly) is a command the trust boundary gates, and the per-map energy and flux normalization are facts under custody. If an autonomous Agent were added to drive a mapping survey (a common pattern at high-throughput microprobes), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/xfm/model.md b/docs/deployments/xfm/model.md
deleted file mode 100644
index b580c7fbeae..00000000000
--- a/docs/deployments/xfm/model.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's XFM content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at XFM |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (4-BM-A optics, 4-BM-C endstation) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What this deployment graduates: nothing
-
-XFM is a clean **pure-reuse** scanning-XRF deployment, the second after 2-ID. It coins no Family and graduates nothing: the multi-element silicon-drift fluorescence detectors (the Xspress3 and the Maia) reuse `EnergyDispersiveSpectrometer` (graduated when 2-ID and 7-BM shared it), the raster stage reuses `LinearStage`, the scaler I0 channels reuse `FluxMonitor` (graduated in #353), the bending-magnet source binds the loose `Beam` PhotonBeam supply (the 2-BM / BMM precedent), and the monochromator / focusing optic / slits bind the catalog `Monochromator` / `Mirror` / `Slit`. The scanning XRF technique reuses the `scanning_fluorescence_microscopy` Method 2-ID left pending: XFM is its second consumer, which strengthens but does not coin it.
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring 2-ID / SRX and the other NSLS-II beamlines. Left out on purpose:
-
-- **No catalog change.** XFM graduates nothing and coins nothing. `scanning_fluorescence_microscopy` stays pending (2-ID + XFM = 2 consumers; Methods have no mechanical promotion, the `energy_scan` deferral discipline; METHOD-1). XANES microspectroscopy leans on the deferred `energy_scan` Capability (ENERGY-1), no practice recorded.
-- **The endstation-only profile.** The public profile collection exposes only the raster stage, the Xspress3, the scaler, and the Maia (in a bypass file). The bending-magnet source, the monochromator, the focusing optic, and the shutters are not in the profile, so they are carried confirm-only with no PV (no fabricated PVs; PROFILE-1). The model is honest about being thin: it asserts the device classes a BM XRF / XANES microprobe must have, with their handles pending the team.
-- **The Maia detector.** XFM's signature fast continuous-mapping array (`XFM:MAIA`) is read from the bypass profile (`rvt/bypass40-maia.py`), not the active startup; it is modelled as a second `EnergyDispersiveSpectrometer` Asset and flagged (MAIA-1).
-- **XRF-tomography.** Out of scope: the profile exposes an X/Y/Z raster stage but no rotation axis, so the raster-x-rotation XRF-tomography (the SRX shape) is not modelled (TECH-1).
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/xfm/notes.md b/docs/deployments/xfm/notes.md
new file mode 100644
index 00000000000..e128b223420
--- /dev/null
+++ b/docs/deployments/xfm/notes.md
@@ -0,0 +1,106 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at XFM: scanning X-ray fluorescence microscopy, a [Catalog](../../catalog/methods.md) Method bound through an NSLS-II [Practice](../nsls2/index.md). XFM is the second scanning-XRF beamline (after 2-ID) and follows the same Method-deferral discipline.*
+
+XFM's science is element mapping: raster the sample through a focused beam and read the fluorescence spectrum at each point, in a step grid or a Maia continuous fly-scan. The Method below renders unlinked and stays pending until the owner-scope decision (METHOD-1) brings it into the catalog.
+
+| Technique | Mode | Detector | Status in CORA |
+| --- | --- | --- | --- |
+| Scanning XRF mapping | raster (step grid or Maia fly) | `EnergyDispersiveSpectrometer` (Xspress3 / Maia) | the 2-ID `scanning_fluorescence_microscopy` Method, pending; XFM is the 2nd consumer (METHOD-1) |
+| XANES microspectroscopy | energy sweep over the `EnergyAxis` | `EnergyDispersiveSpectrometer` | the BMM energy-scan question; `energy_scan` deferred (ENERGY-1), no practice |
+| XRF-tomography | raster x rotation | `EnergyDispersiveSpectrometer` | out of scope: no rotation axis in the profile (TECH-1) |
+
+### Why the Method stays pending
+
+XFM reuses the `scanning_fluorescence_microscopy` Method that 2-ID left pending. Unlike a loose device *Family* (which a second sighting promotes on a mechanical rule-of-three), a pending *Method* has no automatic promotion: it is coined by deliberate decision when a conduct-path needs it, the same discipline that keeps `energy_scan` deferred even across several consumers. XFM makes `scanning_fluorescence_microscopy` a two-consumer Method (2-ID + XFM), which strengthens the eventual case to coin it but does not force it in a descriptor scaffold (METHOD-1). The device Roles already exist (the SDD presents the energy-dispersive Sensor, the raster stage presents Positioner), so what is pending is the recipe, not a device shape.
+
+The XANES microspectroscopy leg sweeps the monochromator energy across an absorption edge, which leans on the deferred `energy_scan` Capability (the BMM ENERGY-1 question); no XANES practice is recorded until that Capability lands, the SRX / BMM discipline. The XRF fitting and any tomographic reconstruction are `ComputePort` work, not beamline Methods.
+
+## Governance
+
+*Who may act at XFM and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An XFM beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may set the energy, start a raster map, run the Maia fly-scan, change the focusing optic, override a caution, or commit an energy calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### The scanning map under custody
+
+XFM's defining operation is the raster XRF map: the UTS stage sweeps the sample through the focused spot while the detectors count per pixel. CORA's Campaign and Trust shapes are where that resolves: starting a map (step or Maia fly) is a command the trust boundary gates, and the per-map energy and flux normalization are facts under custody. If an autonomous Agent were added to drive a mapping survey (a common pattern at high-throughput microprobes), it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's XFM content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at XFM |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (4-BM-A optics, 4-BM-C endstation) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What this deployment graduates: nothing
+
+XFM is a clean **pure-reuse** scanning-XRF deployment, the second after 2-ID. It coins no Family and graduates nothing: the multi-element silicon-drift fluorescence detectors (the Xspress3 and the Maia) reuse `EnergyDispersiveSpectrometer` (graduated when 2-ID and 7-BM shared it), the raster stage reuses `LinearStage`, the scaler I0 channels reuse `FluxMonitor` (graduated in #353), the bending-magnet source binds the loose `Beam` PhotonBeam supply (the 2-BM / BMM precedent), and the monochromator / focusing optic / slits bind the catalog `Monochromator` / `Mirror` / `Slit`. The scanning XRF technique reuses the `scanning_fluorescence_microscopy` Method 2-ID left pending: XFM is its second consumer, which strengthens but does not coin it.
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring 2-ID / SRX and the other NSLS-II beamlines. Left out on purpose:
+
+- **No catalog change.** XFM graduates nothing and coins nothing. `scanning_fluorescence_microscopy` stays pending (2-ID + XFM = 2 consumers; Methods have no mechanical promotion, the `energy_scan` deferral discipline; METHOD-1). XANES microspectroscopy leans on the deferred `energy_scan` Capability (ENERGY-1), no practice recorded.
+- **The endstation-only profile.** The public profile collection exposes only the raster stage, the Xspress3, the scaler, and the Maia (in a bypass file). The bending-magnet source, the monochromator, the focusing optic, and the shutters are not in the profile, so they are carried confirm-only with no PV (no fabricated PVs; PROFILE-1). The model is honest about being thin: it asserts the device classes a BM XRF / XANES microprobe must have, with their handles pending the team.
+- **The Maia detector.** XFM's signature fast continuous-mapping array (`XFM:MAIA`) is read from the bypass profile (`rvt/bypass40-maia.py`), not the active startup; it is modelled as a second `EnergyDispersiveSpectrometer` Asset and flagged (MAIA-1).
+- **XRF-tomography.** Out of scope: the profile exposes an X/Y/Z raster stage but no rotation axis, so the raster-x-rotation XRF-tomography (the SRX shape) is not modelled (TECH-1).
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the XFM team to confirm. This model is reverse-engineered from public open source (the `NSLS2/xfm-profile-collection` bluesky / ophyd startup files), which is endstation-only: the raster stage and detectors are read from the `startup/*.py` device classes, but the bending-magnet source, the optics, and the shutters are not in the profile and are carried confirm-only. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Nice-to-have | The 4-BM bending-magnet source parameters (critical energy, fan, the front-end acceptance). 4-BM is a bending magnet, not an insertion device. | A bending-magnet source, recorded as a PhotonBeam Supply (the 2-BM / BMM precedent). | The source modelling. |
+| PROFILE-1 | Blocks-build | The public profile collection exposes only the endstation (the raster stage + detectors). What are the source, monochromator, focusing-optic, and shutter device handles? They are carried confirm-only with no PV here. | The optics exist physically (a BM XRF / XANES microprobe needs a DCM + focusing optic + shutters); their PVs await the team. | The optics device handles. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the front-end / photon shutter PVs (not in the profile collection). | The permit and shutter signals are confirm notes, not guessed PVs. | The Enclosure permit + shutter signals. |
+| ENC-1 | Nice-to-have | The hutch names / numbering and the A / B / C layout. The endstation PV zone is `XF:04BMC`; the optics zone is inferred. | An optics hutch (4-BM-A) plus the endstation (4-BM-C). | The Enclosure set. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The monochromator crystal cut (Si(111) is the known 4-BM crystal), d-spacing, and energy range. Not in the profile collection. | One `Monochromator` Asset, crystal settings blank. | The Monochromator settings. |
+| OPT-1 | Nice-to-have | The microfocusing optic type (a KB mirror pair or a capillary) and its parameters. Not in the profile collection. | One `Mirror` Asset (the focusing optic), type to confirm. | The focusing-optic modelling. |
+| ENERGY-1 | Nice-to-have | Is energy scanned as the measurement (XANES microspectroscopy sweeps the DCM across an edge), warranting the energy-scan Capability the catalog anticipates? | XANES mapped to the deferred energy_scan Capability (the BMM question). | The spectroscopy Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The Xspress3 element count and ROI map (the profile configures four channels). | A four-channel `EnergyDispersiveSpectrometer` Asset; ROIs to confirm. | The fluorescence-detector modelling. |
+| MAIA-1 | Nice-to-have | The Maia continuous-mapping detector: its element count, live status, and whether it is the primary mapping detector. It is in a bypass profile file (`rvt/bypass40-maia.py`), not the active startup. | A second `EnergyDispersiveSpectrometer` Asset (the Maia array) for fast continuous mapping. | The Maia detector modelling. |
+| DIAG-1 | Nice-to-have | The SIS3820 scaler flux-channel map (which channels are I0, transmitted, the Maia deadtime). | Read-only flux (`FluxMonitor`) channels; the map blank. | The FluxMonitor bindings. |
+
+### Controls and technique scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The raster-stage and optics motion-controller box models, firmware, IPs. | Family bound (MotionController), specifics blank. | The MotionController Models. |
+| METHOD-1 | Blocks-go-live | Does the scanning XRF microprobe technique (`scanning_fluorescence_microscopy`) enter CORA's catalog as a Method, or stay pending? XFM is the second consumer after 2-ID. | The Method reused pending (no mechanical promotion for Methods; the energy_scan deferral discipline). | The scanning-XRF Method scope. |
+| TECH-1 | Nice-to-have | Beyond XRF mapping, does XFM run XANES microspectroscopy and XRF-tomography in CORA scope? XANES leans on the deferred energy_scan; XRF-tomography would need a rotation axis (not in the profile). | XRF mapping modelled; XANES deferred (energy_scan); XRF-tomography out of scope. | The technique scope. |
diff --git a/docs/deployments/xfm/questions.md b/docs/deployments/xfm/questions.md
deleted file mode 100644
index 6196adc5bd8..00000000000
--- a/docs/deployments/xfm/questions.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Open questions
-
-*What CORA needs the XFM team to confirm. This model is reverse-engineered from public open source (the `NSLS2/xfm-profile-collection` bluesky / ophyd startup files), which is endstation-only: the raster stage and detectors are read from the `startup/*.py` device classes, but the bending-magnet source, the optics, and the shutters are not in the profile and are carried confirm-only. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Nice-to-have | The 4-BM bending-magnet source parameters (critical energy, fan, the front-end acceptance). 4-BM is a bending magnet, not an insertion device. | A bending-magnet source, recorded as a PhotonBeam Supply (the 2-BM / BMM precedent). | The source modelling. |
-| PROFILE-1 | Blocks-build | The public profile collection exposes only the endstation (the raster stage + detectors). What are the source, monochromator, focusing-optic, and shutter device handles? They are carried confirm-only with no PV here. | The optics exist physically (a BM XRF / XANES microprobe needs a DCM + focusing optic + shutters); their PVs await the team. | The optics device handles. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs and the front-end / photon shutter PVs (not in the profile collection). | The permit and shutter signals are confirm notes, not guessed PVs. | The Enclosure permit + shutter signals. |
-| ENC-1 | Nice-to-have | The hutch names / numbering and the A / B / C layout. The endstation PV zone is `XF:04BMC`; the optics zone is inferred. | An optics hutch (4-BM-A) plus the endstation (4-BM-C). | The Enclosure set. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The monochromator crystal cut (Si(111) is the known 4-BM crystal), d-spacing, and energy range. Not in the profile collection. | One `Monochromator` Asset, crystal settings blank. | The Monochromator settings. |
-| OPT-1 | Nice-to-have | The microfocusing optic type (a KB mirror pair or a capillary) and its parameters. Not in the profile collection. | One `Mirror` Asset (the focusing optic), type to confirm. | The focusing-optic modelling. |
-| ENERGY-1 | Nice-to-have | Is energy scanned as the measurement (XANES microspectroscopy sweeps the DCM across an edge), warranting the energy-scan Capability the catalog anticipates? | XANES mapped to the deferred energy_scan Capability (the BMM question). | The spectroscopy Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The Xspress3 element count and ROI map (the profile configures four channels). | A four-channel `EnergyDispersiveSpectrometer` Asset; ROIs to confirm. | The fluorescence-detector modelling. |
-| MAIA-1 | Nice-to-have | The Maia continuous-mapping detector: its element count, live status, and whether it is the primary mapping detector. It is in a bypass profile file (`rvt/bypass40-maia.py`), not the active startup. | A second `EnergyDispersiveSpectrometer` Asset (the Maia array) for fast continuous mapping. | The Maia detector modelling. |
-| DIAG-1 | Nice-to-have | The SIS3820 scaler flux-channel map (which channels are I0, transmitted, the Maia deadtime). | Read-only flux (`FluxMonitor`) channels; the map blank. | The FluxMonitor bindings. |
-
-## Controls and technique scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The raster-stage and optics motion-controller box models, firmware, IPs. | Family bound (MotionController), specifics blank. | The MotionController Models. |
-| METHOD-1 | Blocks-go-live | Does the scanning XRF microprobe technique (`scanning_fluorescence_microscopy`) enter CORA's catalog as a Method, or stay pending? XFM is the second consumer after 2-ID. | The Method reused pending (no mechanical promotion for Methods; the energy_scan deferral discipline). | The scanning-XRF Method scope. |
-| TECH-1 | Nice-to-have | Beyond XRF mapping, does XFM run XANES microspectroscopy and XRF-tomography in CORA scope? XANES leans on the deferred energy_scan; XRF-tomography would need a rotation axis (not in the profile). | XRF mapping modelled; XANES deferred (energy_scan); XRF-tomography out of scope. | The technique scope. |
diff --git a/docs/deployments/xfm/techniques.md b/docs/deployments/xfm/techniques.md
deleted file mode 100644
index aa84539d365..00000000000
--- a/docs/deployments/xfm/techniques.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Techniques
-
-*What CORA would run at XFM: scanning X-ray fluorescence microscopy, a [Catalog](../../catalog/methods.md) Method bound through an NSLS-II [Practice](../nsls2/index.md). XFM is the second scanning-XRF beamline (after 2-ID) and follows the same Method-deferral discipline.*
-
-XFM's science is element mapping: raster the sample through a focused beam and read the fluorescence spectrum at each point, in a step grid or a Maia continuous fly-scan. The Method below renders unlinked and stays pending until the owner-scope decision (METHOD-1) brings it into the catalog.
-
-| Technique | Mode | Detector | Status in CORA |
-| --- | --- | --- | --- |
-| Scanning XRF mapping | raster (step grid or Maia fly) | `EnergyDispersiveSpectrometer` (Xspress3 / Maia) | the 2-ID `scanning_fluorescence_microscopy` Method, pending; XFM is the 2nd consumer (METHOD-1) |
-| XANES microspectroscopy | energy sweep over the `EnergyAxis` | `EnergyDispersiveSpectrometer` | the BMM energy-scan question; `energy_scan` deferred (ENERGY-1), no practice |
-| XRF-tomography | raster x rotation | `EnergyDispersiveSpectrometer` | out of scope: no rotation axis in the profile (TECH-1) |
-
-## Why the Method stays pending
-
-XFM reuses the `scanning_fluorescence_microscopy` Method that 2-ID left pending. Unlike a loose device *Family* (which a second sighting promotes on a mechanical rule-of-three), a pending *Method* has no automatic promotion: it is coined by deliberate decision when a conduct-path needs it, the same discipline that keeps `energy_scan` deferred even across several consumers. XFM makes `scanning_fluorescence_microscopy` a two-consumer Method (2-ID + XFM), which strengthens the eventual case to coin it but does not force it in a descriptor scaffold (METHOD-1). The device Roles already exist (the SDD presents the energy-dispersive Sensor, the raster stage presents Positioner), so what is pending is the recipe, not a device shape.
-
-The XANES microspectroscopy leg sweeps the monochromator energy across an absorption edge, which leans on the deferred `energy_scan` Capability (the BMM ENERGY-1 question); no XANES practice is recorded until that Capability lands, the SRX / BMM discipline. The XRF fitting and any tomographic reconstruction are `ComputePort` work, not beamline Methods.
diff --git a/docs/deployments/xfp/governance.md b/docs/deployments/xfp/governance.md
deleted file mode 100644
index f3387cd1266..00000000000
--- a/docs/deployments/xfp/governance.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Governance
-
-*Who will act at XFP, and the trust shape that will gate it. First cut.*
-
-Governance at XFP follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
-
-XFP is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. XFP is a Case Western Reserve University partner beamline operated within NSLS-II, so its operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), with the partner-beamline operating model itself an open question (`GOV-1`).
-
-## The safety boundary
-
-The safety tier is the other piece that is not yet settled. Only the front-end photon-shutter enable status is in the beamline's profile collection (interlock-derived; plans refuse to open the shutter when it is disabled), so the Enclosure permit leaves and the rest of the search-and-secure structure are carried pending and not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
-
-XFP brings two distinctive hazards: a high-flux white beam, and the dose it delivers. They land with the equipment and the experiment that bring them, and an experiment Clearance would carry them.
-
-| Hazard class | Where it lands | Tracking |
-| --- | --- | --- |
-| High-flux white / pink X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (FE:C17B, XF:17BM / XF:17BMA) (`ENC-1`) | (`PSS-1`, `WHITE-1`) |
-| Delivered radiolytic dose to biological samples | the [dose-delivery gating](source.md) and the [Sample](sample.md) side | (`DOSE-1`, `SUBJECT-1`) |
-| Vacuum white-beam optics | the [Source](source.md) walk | (`SUP-1`) |
-| Biological samples, buffers, and fluidics | the [Sample](sample.md) delivery chain | (`FLOW-1`, `SUBJECT-1`) |
-
-The high-flux white beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The delivered dose is itself a controlled hazard at a footprinting beamline, distinctive to its dose-delivery character, and travels with the dose-gating chain and the Subject (`DOSE-1`, `SUBJECT-1`). The biological-sample and fluidics hazards travel with the delivery chain (`FLOW-1`). None of these is invented; each is carried against its question.
-
-## When the shape lands
-
-The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives XFP, following the [2-BM governance](../2-bm/governance.md) shape. Because XFP shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The distinctive wrinkles are the partner-beamline operating model (`GOV-1`) and the offline-readout seam: a Conduit would bound the dose-delivery command surfaces, while the downstream mass-spec analysis sits outside the beamline's trust boundary entirely (`READOUT-1`). The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
diff --git a/docs/deployments/xfp/model.md b/docs/deployments/xfp/model.md
deleted file mode 100644
index ff49571493c..00000000000
--- a/docs/deployments/xfp/model.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's XFP content lives, how it models a beamline with no detector and an offline readout, and the record of what is deliberately deferred. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at XFP |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [the index](index.md#enclosures) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## What makes XFP new
-
-XFP is the most structurally distinct deployment in the fleet. Every other beamline CORA models is a measurement beamline: condition a beam, place a sample, record a detector signal. XFP is a **dose-delivery** beamline with **no detector**. Its contributions:
-
-- **Dose as the experiment variable.** The controlled quantity is the delivered radiolytic dose (exposure time times incident flux times attenuation), not a detector setting. The whole apparatus, the timed shutters, the delay-generator-fired millisecond fast shutter, the Al filter wheel, and the flux monitors, exists to set and measure that dose.
-- **A sample-and-record output, not frames.** A footprinting run produces a footprinted sample (an irradiated aliquot) plus a dose record (exposure time, filter thickness, flux time-series, well / tube identity). There are no measurement frames.
-- **The offline-readout seam.** The structural readout (which residues were modified) is offline mass spectrometry, downstream and off the beamline. CORA is the system of record for the dose and the sample provenance; the MS analysis is a separate, later step.
-- **A solution Subject.** Like LIX, the specimen is a biological macromolecule in a buffer, delivered fluidically.
-
-## No new families
-
-XFP coins no new Family and changes nothing in the catalog. The whole device tree reuses existing vocabulary; the novelty is in the Method, the Subject, and the seam, not in device classes.
-
-- **17-BM is a bending-magnet, white / pink beam source** (no insertion device, no monochromator in the footprinting path); machine state is observed through the loose `StorageRing`, and the white-versus-mono scope is `SRC-1` / `WHITE-1`.
-- **The dose chain reuses the catalog:** the bendable mirror binds `Mirror`; the slits bind `Slit`; the Al filter wheel binds `Filter` (it sets the dose rate); the timed shutters bind `Shutter`; the delay generator that fires the millisecond Uniblitz fast shutter binds `TimingController` (its opening-time setpoint is the dose time); the QuadEM electrometers bind `FluxMonitor`; the Sydor beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; per-Asset channel map open, `DIAG-1`); the sample stages bind `LinearStage`.
-
-## How a beamline with no detector is modelled
-
-XFP has no Detector-role imaging device, and CORA models that honestly rather than inventing one:
-
-- the detection side holds **flux / dose monitors** (`FluxMonitor`, the graduated catalog `PositionMonitor`), which measure the delivered dose, not a sample signal;
-- the dose-delivery role is expressed by the **Source gating** (Shutter + `TimingController` + `Filter`) plus those flux monitors, not by a detector;
-- the structural readout is the **offline-readout seam**: the run's product is a footprinted sample plus a dose record, and the mass-spec analysis happens downstream, off the beamline (`READOUT-1`).
-
-This is the deliberate inversion: where a measurement beamline's run is anchored on a Dataset of detector frames, an XFP run is anchored on a dose record and a Subject (the footprinted aliquot), with the structural Dataset produced elsewhere and linked back later.
-
-## The FlowController rule-of-three
-
-The one device reuse worth naming is the sample-delivery pump. Its anatomy is a settable flow / pump actuator (rate / volume setpoints, a run command), exactly the catalog `FlowController` Family that i22, 7-BM, and LIX already use. So the pump **reuses** `FlowController`; it coins nothing. XFP is its **fourth** consumer (i22, 7-BM, LIX, XFP), and `FlowController` has now **graduated** into the catalog on this rule-of-three: it presents the existing `Regulator` Role (the settable-actuator sibling of `TemperatureController`), earned across i22 / 7-BM / LIX / XFP, like `EmissionSpectrometer` and `TemperatureController` before it. The wider fluidic chain beyond the pump (selector valves, SEC columns, flow cells, fraction collectors) stays in the `ControlPort` seam pending its own rule-of-three (`FLUID-1`).
-
-## Deliberately not here yet
-
-- **The fraction collector Family (`FC-1`).** The fraction collector is a PV-bound aliquot-routing actuator with no clean existing Family. At n=1 CORA does not coin a `FractionCollector` Family; it is carried in the sample-custody seam (the footprinted-sample hand-off to offline MS).
-- **The 96-well plate handler (`HT-1`).** The plate is addressed in pure Python (8 columns x 12 rows, a coordinate table, no robot and no PV); it is a Procedure over the spine plus a Subject custody thread, the i03 / MX3 / LIX custody-as-Procedure precedent (XFP at the no-robot end of that spectrum), not a device Family.
-- **The offline mass-spec readout (`READOUT-1`).** The structural analysis is downstream, off the beamline, and absent from the profile collection. A future integration could link the offline MS result back to the dose record; it is not modelled here.
-- **The Method.** Whether `x_ray_footprinting` (or a broader controlled-dose / irradiation Capability) enters CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
-- **The intermittently-connected and out-of-scope hardware.** The 0-9 mm Al z-attenuator, the beam-defining pinhole stages, the greenfield Galil stages, and the temperature / bias diagnostics are intermittently connected or read-only and not modelled as core devices (`ATTN-1`, `TEMP-1`); the monochromatic XAS endstation (ES:3) is a separate endstation, out of scope for footprinting (`WHITE-1`).
-- **The time-resolved mixing mode.** The stopped-flow time-resolved footprinting mode is flagged unfinished in the source; no Practice is recorded for it (`TECH-1`).
-- **The simulated devices and full asset-tree scenarios.** No `test_xfp_*.py` registers the asset tree, and no vendor Models are bound.
-- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
diff --git a/docs/deployments/xfp/notes.md b/docs/deployments/xfp/notes.md
new file mode 100644
index 00000000000..ba80f8ba7b8
--- /dev/null
+++ b/docs/deployments/xfp/notes.md
@@ -0,0 +1,181 @@
+# Notes
+
+## Techniques
+
+*What the modelled part of XFP is designed to do, as intent. First cut.*
+
+A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. XFP does one technique, **X-ray footprinting**, in two delivery modes: static / capillary-flow, and shutterless high-throughput. The Method below renders unlinked and is carried pending until the owner-scope decision (`TECH-1`) brings it into the catalog.
+
+| Technique | Catalog method | Notes |
+| --- | --- | --- |
+| X-ray footprinting (capillary-flow / static) | `x_ray_footprinting` | gate a timed white-beam dose onto a flowing solution capillary or flow-cell sample, recording exposure time x flux x attenuation as the delivered dose; the fleet's first dose-delivery Method, new to the catalog; readout is offline mass spec (`TECH-1`, `READOUT-1`) |
+| High-throughput footprinting (HTFly) | `x_ray_footprinting` | sweep a fly-cell row through the defining slit at a set stage velocity so the exposure (dose) is the slit gap over the velocity, across a 96-well plate; the same `x_ray_footprinting` Method with the HTFly stage as the dose-timing (`TECH-1`, `HT-1`) |
+
+Both modes need the [white-beam chain](source.md) (the mirror, the slits, the Al filter wheel for dose rate), the [dose gating](source.md) (the timed shutters or the delay-generator-fired Uniblitz, or the HTFly velocity), the [sample side](sample.md) (a stage and the delivery pump), and the [flux monitors](detector.md) (to record the delivered dose). They differ only in how the exposure is timed and how many samples are handled.
+
+### The technique is dose delivery, and the readout is offline
+
+This is the heart of what makes XFP a new shape for CORA. X-ray footprinting is not a measurement technique in the sense the rest of the fleet uses: the beamline does not record a structural signal. It **delivers a controlled radiolytic dose** to a biological macromolecule in solution, generating hydroxyl radicals that covalently modify the molecule at solvent-accessible sites. The modified sample is then analysed **offline by mass spectrometry**, which reveals which residues were exposed and thus maps the molecule's surface and conformational changes.
+
+So the Method `x_ray_footprinting` is a **dose-delivery** Method:
+
+- its controlled variable is the delivered dose (exposure time times flux times attenuation), not a detector setting;
+- its product is a footprinted sample plus a dose record, not a measurement frame;
+- its structural readout is the offline-readout seam (mass spec, downstream and off the beamline, `READOUT-1`).
+
+That is why `x_ray_footprinting` is proposed as a Method distinct from anything in the catalog: not because the optics are unusual (a white beam, a filter, a shutter), but because the experiment shape, dose-in, sample-out, structure-read-elsewhere, is genuinely new. Whether the catalog ultimately holds a `x_ray_footprinting` Capability, or a broader "controlled-dose / irradiation" Capability with footprinting as a Practice adaptation, is the owner-scope decision (`TECH-1`); XFP records the case, it does not mint the vocabulary. The matching Site Practices (`XFP_footprinting_practice`, `XFP_high_throughput_footprinting_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
+
+### A time-resolved mode, deferred
+
+The profile collection also contains a time-resolved capillary-flow mode (a stopped-flow style mixing experiment before irradiation), but it is flagged unfinished in the source, so no Practice is recorded for it here; it is a later mode that would reuse the same `x_ray_footprinting` Method with a mixing step in the Procedure (`TECH-1`).
+
+### Not modelled yet
+
+The concrete acquisition recipes are not written yet. For footprinting that is the dose series (the set of exposure times or filter thicknesses that build a dose-response curve), the flow program that presents fresh sample, the aliquot-collection pattern, and the flux-to-absorbed-dose calibration that converts the measured flux to the dose the sample received (a seam constant that lives in offline analysis, `DOSE-1`). The downstream linkage to the offline mass-spec result is the offline-readout seam, not a beamline recipe (`READOUT-1`). These join as the deployment approaches the point where CORA drives XFP.
+
+Whether `x_ray_footprinting` enters CORA's catalog is an owner-scope decision on [Model](#model): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. See [Open questions](#open-questions) for the world-facts to confirm first.
+
+## Governance
+
+*Who will act at XFP, and the trust shape that will gate it. First cut.*
+
+Governance at XFP follows the same model as the other NSLS-II beamlines: people and autonomous agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), and on the beamline they surface through the actions they take. Their commands are gated by a trust shape (a Zone grouping the beamline's resources, a Conduit binding the surfaces that may issue commands, and Policies that say who may do what).
+
+XFP is not yet driven by CORA, so this shape is not yet instantiated. As a modelling-exercise scaffold, the deployment is descriptor and docs today, so the concrete Zone, Conduit, and Policy instances are deliberately not materialized. XFP is a Case Western Reserve University partner beamline operated within NSLS-II, so its operator and review structure is carried pending on the [NSLS-II Site](../nsls2/index.md#safety-and-governance), with the partner-beamline operating model itself an open question (`GOV-1`).
+
+### The safety boundary
+
+The safety tier is the other piece that is not yet settled. Only the front-end photon-shutter enable status is in the beamline's profile collection (interlock-derived; plans refuse to open the shutter when it is disabled), so the Enclosure permit leaves and the rest of the search-and-secure structure are carried pending and not invented here (`PSS-1`). What is already settled is the boundary: clearances (the safety forms that must be active to start) are issued at the [NSLS-II Site](../nsls2/index.md#safety-and-governance), not on the beamline, and the beamline links up to them.
+
+XFP brings two distinctive hazards: a high-flux white beam, and the dose it delivers. They land with the equipment and the experiment that bring them, and an experiment Clearance would carry them.
+
+| Hazard class | Where it lands | Tracking |
+| --- | --- | --- |
+| High-flux white / pink X-ray beam | the [optics](index.md) and [endstation](index.md) enclosures (FE:C17B, XF:17BM / XF:17BMA) (`ENC-1`) | (`PSS-1`, `WHITE-1`) |
+| Delivered radiolytic dose to biological samples | the [dose-delivery gating](source.md) and the [Sample](sample.md) side | (`DOSE-1`, `SUBJECT-1`) |
+| Vacuum white-beam optics | the [Source](source.md) walk | (`SUP-1`) |
+| Biological samples, buffers, and fluidics | the [Sample](sample.md) delivery chain | (`FLOW-1`, `SUBJECT-1`) |
+
+The high-flux white beam is the interlocked hazard; its permit leaves stay pending until the PSS signals are confirmed (`PSS-1`). The delivered dose is itself a controlled hazard at a footprinting beamline, distinctive to its dose-delivery character, and travels with the dose-gating chain and the Subject (`DOSE-1`, `SUBJECT-1`). The biological-sample and fluidics hazards travel with the delivery chain (`FLOW-1`). None of these is invented; each is carried against its question.
+
+### When the shape lands
+
+The concrete Zone, Conduit, and Policy instances, and the operator pool, land when the deployment approaches the point where CORA drives XFP, following the [2-BM governance](../2-bm/governance.md) shape. Because XFP shares the NSLS-II EPICS and ophyd floor with the rest of the fleet, it re-tests the Site and Federation kernel rather than introducing a new trust model. The distinctive wrinkles are the partner-beamline operating model (`GOV-1`) and the offline-readout seam: a Conduit would bound the dose-delivery command surfaces, while the downstream mass-spec analysis sits outside the beamline's trust boundary entirely (`READOUT-1`). The Zone groups the same optics and endstation resources the [inventory](index.md) lists; the Policies bind to the NSLS-II operator roles carried pending at the Site (`GOV-1`).
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's XFP content lives, how it models a beamline with no detector and an offline readout, and the record of what is deliberately deferred. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC [modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at XFP |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [the index](index.md#enclosures) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### What makes XFP new
+
+XFP is the most structurally distinct deployment in the fleet. Every other beamline CORA models is a measurement beamline: condition a beam, place a sample, record a detector signal. XFP is a **dose-delivery** beamline with **no detector**. Its contributions:
+
+- **Dose as the experiment variable.** The controlled quantity is the delivered radiolytic dose (exposure time times incident flux times attenuation), not a detector setting. The whole apparatus, the timed shutters, the delay-generator-fired millisecond fast shutter, the Al filter wheel, and the flux monitors, exists to set and measure that dose.
+- **A sample-and-record output, not frames.** A footprinting run produces a footprinted sample (an irradiated aliquot) plus a dose record (exposure time, filter thickness, flux time-series, well / tube identity). There are no measurement frames.
+- **The offline-readout seam.** The structural readout (which residues were modified) is offline mass spectrometry, downstream and off the beamline. CORA is the system of record for the dose and the sample provenance; the MS analysis is a separate, later step.
+- **A solution Subject.** Like LIX, the specimen is a biological macromolecule in a buffer, delivered fluidically.
+
+### No new families
+
+XFP coins no new Family and changes nothing in the catalog. The whole device tree reuses existing vocabulary; the novelty is in the Method, the Subject, and the seam, not in device classes.
+
+- **17-BM is a bending-magnet, white / pink beam source** (no insertion device, no monochromator in the footprinting path); machine state is observed through the loose `StorageRing`, and the white-versus-mono scope is `SRC-1` / `WHITE-1`.
+- **The dose chain reuses the catalog:** the bendable mirror binds `Mirror`; the slits bind `Slit`; the Al filter wheel binds `Filter` (it sets the dose rate); the timed shutters bind `Shutter`; the delay generator that fires the millisecond Uniblitz fast shutter binds `TimingController` (its opening-time setpoint is the dose time); the QuadEM electrometers bind `FluxMonitor`; the Sydor beam-position monitor binds the graduated catalog `PositionMonitor` (presenting `Sensor`, distinct from `FluxMonitor` by measuring beam position rather than flux; per-Asset channel map open, `DIAG-1`); the sample stages bind `LinearStage`.
+
+### How a beamline with no detector is modelled
+
+XFP has no Detector-role imaging device, and CORA models that honestly rather than inventing one:
+
+- the detection side holds **flux / dose monitors** (`FluxMonitor`, the graduated catalog `PositionMonitor`), which measure the delivered dose, not a sample signal;
+- the dose-delivery role is expressed by the **Source gating** (Shutter + `TimingController` + `Filter`) plus those flux monitors, not by a detector;
+- the structural readout is the **offline-readout seam**: the run's product is a footprinted sample plus a dose record, and the mass-spec analysis happens downstream, off the beamline (`READOUT-1`).
+
+This is the deliberate inversion: where a measurement beamline's run is anchored on a Dataset of detector frames, an XFP run is anchored on a dose record and a Subject (the footprinted aliquot), with the structural Dataset produced elsewhere and linked back later.
+
+### The FlowController rule-of-three
+
+The one device reuse worth naming is the sample-delivery pump. Its anatomy is a settable flow / pump actuator (rate / volume setpoints, a run command), exactly the catalog `FlowController` Family that i22, 7-BM, and LIX already use. So the pump **reuses** `FlowController`; it coins nothing. XFP is its **fourth** consumer (i22, 7-BM, LIX, XFP), and `FlowController` has now **graduated** into the catalog on this rule-of-three: it presents the existing `Regulator` Role (the settable-actuator sibling of `TemperatureController`), earned across i22 / 7-BM / LIX / XFP, like `EmissionSpectrometer` and `TemperatureController` before it. The wider fluidic chain beyond the pump (selector valves, SEC columns, flow cells, fraction collectors) stays in the `ControlPort` seam pending its own rule-of-three (`FLUID-1`).
+
+### Deliberately not here yet
+
+- **The fraction collector Family (`FC-1`).** The fraction collector is a PV-bound aliquot-routing actuator with no clean existing Family. At n=1 CORA does not coin a `FractionCollector` Family; it is carried in the sample-custody seam (the footprinted-sample hand-off to offline MS).
+- **The 96-well plate handler (`HT-1`).** The plate is addressed in pure Python (8 columns x 12 rows, a coordinate table, no robot and no PV); it is a Procedure over the spine plus a Subject custody thread, the i03 / MX3 / LIX custody-as-Procedure precedent (XFP at the no-robot end of that spectrum), not a device Family.
+- **The offline mass-spec readout (`READOUT-1`).** The structural analysis is downstream, off the beamline, and absent from the profile collection. A future integration could link the offline MS result back to the dose record; it is not modelled here.
+- **The Method.** Whether `x_ray_footprinting` (or a broader controlled-dose / irradiation Capability) enters CORA's catalog is an owner decision; the Practices render unlinked, pending (`TECH-1`).
+- **The intermittently-connected and out-of-scope hardware.** The 0-9 mm Al z-attenuator, the beam-defining pinhole stages, the greenfield Galil stages, and the temperature / bias diagnostics are intermittently connected or read-only and not modelled as core devices (`ATTN-1`, `TEMP-1`); the monochromatic XAS endstation (ES:3) is a separate endstation, out of scope for footprinting (`WHITE-1`).
+- **The time-resolved mixing mode.** The stopped-flow time-resolved footprinting mode is flagged unfinished in the source; no Practice is recorded for it (`TECH-1`).
+- **The simulated devices and full asset-tree scenarios.** No `test_xfp_*.py` registers the asset tree, and no vendor Models are bound.
+- **Operations and experiment views.** A runbook and live experiment view for a beamline CORA does not yet drive would be invention; see the note on the [index](index.md#not-yet-documented).
+
+## Open questions
+
+*What CORA needs the XFP team to confirm before the model can be trusted.*
+
+XFP was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/xfp-profile-collection](https://github.com/NSLS2/xfp-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
+
+### Topology and scope
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| ENC-1 | Blocks-go-live | Are the optics (FE:C17B, XF:17BM-OP / XF:17BMA-OP) and the endstations (XF:17BMA-ES:1, ES:2) separate hutches? | Two enclosures: a `xfp-optics` zone and the `xfp-endstation` hutch. | The Enclosure grouping. |
+| SRC-1 | Nice-to-have | The 17-BM source (a bending magnet is implied by the name and the white-beam design; the profile collection exposes no source device, only ring current). | A bending-magnet source, observed only through the machine state. | The source Asset detail. |
+| WHITE-1 | Blocks-go-live | Is routine footprinting white beam or pink beam (filtered by the mirror cutoff and the Al filters), and is there any monochromator in the footprinting path? (A DCM exists only on a separate XAS endstation, ES:3, excluded here.) | White / pink beam, no monochromator in the footprinting path; ES:3 out of scope. | The beam-conditioning model. |
+
+### Source and optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| MACHINE-1 | Nice-to-have | The storage-ring state XFP reads (only the ring current is read for a beam-present suspender). | Observe-only machine state, a loose `StorageRing`; the rest pending. | The machine-state observation. |
+| OPT-1 | Nice-to-have | The front-end mirror coating and bend mechanism (a bendable mirror with a Bend focus axis and thermocouples). | A bendable focusing `Mirror`; coating and bend pending. | The mirror Asset detail. |
+| OPT-2 | Nice-to-have | The blade-axis roles of the white-beam, PB / PDS, and ADC defining slits (the ADC horizontal gap sets the HTFly exposure window). | Four-blade / center-gap slits bound to `Slit`. | The slit Asset detail. |
+| ATTN-1 | Blocks-go-live | The attenuation chain that sets the dose RATE: the eight-position Al filter wheel, plus the intermittently-connected 0-9 mm Al z-attenuator and the beam-defining pinhole apertures. | The filter wheel binds `Filter`; the pinhole / z-attenuator are further attenuators carried pending. | The dose-rate attenuator modelling. |
+
+### Dose delivery
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DOSE-1 | Blocks-go-live | The dose-delivery chain: the timed shutters (the EPS pre-shutter, the PPS photon shutter, the inner DIODE sample shutter), the DG535 delay generator that fires the millisecond Uniblitz fast shutter (its opening-time setpoint is the dose time), and the flux-to-absorbed-dose calibration (which lives in offline analysis). | Seconds-scale dose is software-timed on the pre-shutter (`Shutter`); millisecond dose is the delay-generator-fired Uniblitz (`TimingController`); the dose calibration is offline. | The dose-delivery modelling. |
+
+### Sample and delivery
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SAMPLE-1 | Blocks-go-live | The capillary-flow sample stage axes and how a flowing solution capillary mounts in the beam. | A `LinearStage` for the capillary-flow stage; the flow is the fluidic seam. | The sample-stage modelling. |
+| HT-1 | Blocks-go-live | The high-throughput modes: the 96-well plate stage and addressing (8 columns x 12 rows, addressed in pure Python with a coordinate table, no robot and no PV), and the shutterless HTFly stage (exposure = defining-slit gap over stage velocity). | `LinearStage` stages; the well addressing and the HTFly dose-timing are Procedures over the spine plus a Subject custody thread. | The high-throughput modelling. |
+| FLOW-1 | Nice-to-have | The sample-delivery pumps (an M50 pump and a PHD2000 infusion pump, both with rate / volume setpoints), which units are live, and the per-Asset pump detail. | The pump binds the graduated catalog `FlowController` (presents Regulator; earned on the i22 / 7-BM / LIX / XFP rule-of-three); the wider fluidic chain stays in the seam (`FLUID-1`). | The pump modelling; the CORA decision is on [Model](#deliberately-not-here-yet). |
+| FC-1 | Nice-to-have | The fraction collector (a PV-bound aliquot-routing actuator: a collect / waste valve, a tube index, a fill pattern) that captures footprinted aliquots, and whether it earns a Family. | Carried in the sample-custody seam (the footprinted-sample hand-off to offline MS); no `FractionCollector` Family coined at n=1. | The fraction-collector modelling. |
+| SUBJECT-1 | Nice-to-have | The solution Subject: a biological macromolecule (protein / nucleic acid) in a buffer, irradiated, with its own provenance. | A liquid Subject; the footprinted aliquot is the run's output, carried to offline MS. | The Subject modelling. |
+| TEMP-1 | Nice-to-have | The temperature / bias diagnostics (the SR630 thermocouple monitor and the Sydor bias / thermocouple controller), used as alignment-flux proxies. | Read-only diagnostics, not core footprinting devices; deferred. | The temperature-diagnostic modelling. |
+
+### Detection and readout
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DET-1 | Blocks-go-live | The flux / dose monitors: the QuadEM electrometers (incident flux plus a per-exposure time-series), the DIODE PDM array-logger, and which channels measure the delivered dose. | `FluxMonitor` Assets; the channel map and the dose computation carried pending. | The flux / dose-monitor modelling. |
+| DIAG-1 | Nice-to-have | The Sydor beam-position monitor (per-quadrant currents, beam x / y, a sum-current total flux) and the per-Asset position-versus-intensity split. The `PositionMonitor` Family itself is settled (graduated catalog Family presenting `Sensor`). | A graduated catalog `PositionMonitor` (earned across the wide fleet that shares it); only the per-Asset channel map is pending. | The beam-position-monitor channel map. |
+| READOUT-1 | Blocks-go-live | The offline mass-spectrometry readout: what artifact the beamline hands off (a footprinted aliquot in a fraction-collector tube? a capillary?), whether a sample-ID barcode is recorded, and where the dose record is the system of record. | The beamline produces a footprinted sample plus a dose record; the MS structural analysis is downstream, off the beamline. | The offline-readout seam. |
+
+### Control and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the data plane Kafka plus Redis (no Tiled, no queue-server)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (only the front-end photon-shutter enable status is in the profile collection). | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
+| SUP-1 | Nice-to-have | The vacuum extent (the white-beam optics) and the cooling supply, plus the footprinting consumables (buffers, radical scavengers, the flow medium). | Photon beam, cooling water, and vacuum on the optics; the consumables as Supply. | The Supply observations. |
+| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure, and XFP's partner-beamline (Case Western) operating model. | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
+
+### Technique
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| TECH-1 | Blocks-go-live | Does X-ray footprinting (the dose-delivery technique, with offline MS readout) enter CORA's catalog as a Capability / Method? | Deferred: carried as pending Practices; `x_ray_footprinting` is new, the fleet's first dose-delivery Method; not coined. | The technique Capability. |
diff --git a/docs/deployments/xfp/questions.md b/docs/deployments/xfp/questions.md
deleted file mode 100644
index c80f6d31043..00000000000
--- a/docs/deployments/xfp/questions.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Open questions
-
-*What CORA needs the XFP team to confirm before the model can be trusted.*
-
-XFP was reverse-engineered from the beamline's own bluesky profile collection ([NSLS2/xfp-profile-collection](https://github.com/NSLS2/xfp-profile-collection)), so the control handles on the [device pages](index.md) are the beamline's real PVs, read from the `startup/` files rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on [Model](model.md#deliberately-not-here-yet)). It is a delete-on-answer queue. Priorities are `Blocks-build`, `Blocks-go-live`, and `Nice-to-have`.
-
-## Topology and scope
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| ENC-1 | Blocks-go-live | Are the optics (FE:C17B, XF:17BM-OP / XF:17BMA-OP) and the endstations (XF:17BMA-ES:1, ES:2) separate hutches? | Two enclosures: a `xfp-optics` zone and the `xfp-endstation` hutch. | The Enclosure grouping. |
-| SRC-1 | Nice-to-have | The 17-BM source (a bending magnet is implied by the name and the white-beam design; the profile collection exposes no source device, only ring current). | A bending-magnet source, observed only through the machine state. | The source Asset detail. |
-| WHITE-1 | Blocks-go-live | Is routine footprinting white beam or pink beam (filtered by the mirror cutoff and the Al filters), and is there any monochromator in the footprinting path? (A DCM exists only on a separate XAS endstation, ES:3, excluded here.) | White / pink beam, no monochromator in the footprinting path; ES:3 out of scope. | The beam-conditioning model. |
-
-## Source and optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| MACHINE-1 | Nice-to-have | The storage-ring state XFP reads (only the ring current is read for a beam-present suspender). | Observe-only machine state, a loose `StorageRing`; the rest pending. | The machine-state observation. |
-| OPT-1 | Nice-to-have | The front-end mirror coating and bend mechanism (a bendable mirror with a Bend focus axis and thermocouples). | A bendable focusing `Mirror`; coating and bend pending. | The mirror Asset detail. |
-| OPT-2 | Nice-to-have | The blade-axis roles of the white-beam, PB / PDS, and ADC defining slits (the ADC horizontal gap sets the HTFly exposure window). | Four-blade / center-gap slits bound to `Slit`. | The slit Asset detail. |
-| ATTN-1 | Blocks-go-live | The attenuation chain that sets the dose RATE: the eight-position Al filter wheel, plus the intermittently-connected 0-9 mm Al z-attenuator and the beam-defining pinhole apertures. | The filter wheel binds `Filter`; the pinhole / z-attenuator are further attenuators carried pending. | The dose-rate attenuator modelling. |
-
-## Dose delivery
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DOSE-1 | Blocks-go-live | The dose-delivery chain: the timed shutters (the EPS pre-shutter, the PPS photon shutter, the inner DIODE sample shutter), the DG535 delay generator that fires the millisecond Uniblitz fast shutter (its opening-time setpoint is the dose time), and the flux-to-absorbed-dose calibration (which lives in offline analysis). | Seconds-scale dose is software-timed on the pre-shutter (`Shutter`); millisecond dose is the delay-generator-fired Uniblitz (`TimingController`); the dose calibration is offline. | The dose-delivery modelling. |
-
-## Sample and delivery
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SAMPLE-1 | Blocks-go-live | The capillary-flow sample stage axes and how a flowing solution capillary mounts in the beam. | A `LinearStage` for the capillary-flow stage; the flow is the fluidic seam. | The sample-stage modelling. |
-| HT-1 | Blocks-go-live | The high-throughput modes: the 96-well plate stage and addressing (8 columns x 12 rows, addressed in pure Python with a coordinate table, no robot and no PV), and the shutterless HTFly stage (exposure = defining-slit gap over stage velocity). | `LinearStage` stages; the well addressing and the HTFly dose-timing are Procedures over the spine plus a Subject custody thread. | The high-throughput modelling. |
-| FLOW-1 | Nice-to-have | The sample-delivery pumps (an M50 pump and a PHD2000 infusion pump, both with rate / volume setpoints), which units are live, and the per-Asset pump detail. | The pump binds the graduated catalog `FlowController` (presents Regulator; earned on the i22 / 7-BM / LIX / XFP rule-of-three); the wider fluidic chain stays in the seam (`FLUID-1`). | The pump modelling; the CORA decision is on [Model](model.md#deliberately-not-here-yet). |
-| FC-1 | Nice-to-have | The fraction collector (a PV-bound aliquot-routing actuator: a collect / waste valve, a tube index, a fill pattern) that captures footprinted aliquots, and whether it earns a Family. | Carried in the sample-custody seam (the footprinted-sample hand-off to offline MS); no `FractionCollector` Family coined at n=1. | The fraction-collector modelling. |
-| SUBJECT-1 | Nice-to-have | The solution Subject: a biological macromolecule (protein / nucleic acid) in a buffer, irradiated, with its own provenance. | A liquid Subject; the footprinted aliquot is the run's output, carried to offline MS. | The Subject modelling. |
-| TEMP-1 | Nice-to-have | The temperature / bias diagnostics (the SR630 thermocouple monitor and the Sydor bias / thermocouple controller), used as alignment-flux proxies. | Read-only diagnostics, not core footprinting devices; deferred. | The temperature-diagnostic modelling. |
-
-## Detection and readout
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DET-1 | Blocks-go-live | The flux / dose monitors: the QuadEM electrometers (incident flux plus a per-exposure time-series), the DIODE PDM array-logger, and which channels measure the delivered dose. | `FluxMonitor` Assets; the channel map and the dose computation carried pending. | The flux / dose-monitor modelling. |
-| DIAG-1 | Nice-to-have | The Sydor beam-position monitor (per-quadrant currents, beam x / y, a sum-current total flux) and the per-Asset position-versus-intensity split. The `PositionMonitor` Family itself is settled (graduated catalog Family presenting `Sensor`). | A graduated catalog `PositionMonitor` (earned across the wide fleet that shares it); only the per-Asset channel map is pending. | The beam-position-monitor channel map. |
-| READOUT-1 | Blocks-go-live | The offline mass-spectrometry readout: what artifact the beamline hands off (a footprinted aliquot in a fraction-collector tube? a capillary?), whether a sample-ID barcode is recorded, and where the dose record is the system of record. | The beamline produces a footprinted sample plus a dose record; the MS structural analysis is downstream, off the beamline. | The offline-readout seam. |
-
-## Control and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| CTRL-1 | Blocks-go-live | Are the EPICS PV handles read from the profile collection current and correct, and is the data plane Kafka plus Redis (no Tiled, no queue-server)? | The handles in the descriptor are taken from the profile collection and carried confirm; the data plane is the seam CORA's edge replaces. | Verifying each Asset's control handle and the data plane. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit signals and the front-end / photon shutters (only the front-end photon-shutter enable status is in the profile collection). | Permit leaves to be named; not invented here. | The Enclosure permit signals and the safety tier. |
-| SUP-1 | Nice-to-have | The vacuum extent (the white-beam optics) and the cooling supply, plus the footprinting consumables (buffers, radical scavengers, the flow medium). | Photon beam, cooling water, and vacuum on the optics; the consumables as Supply. | The Supply observations. |
-| GOV-1 | Nice-to-have | The NSLS-II operator pool and safety-review structure, and XFP's partner-beamline (Case Western) operating model. | Carried pending on the NSLS-II Site, not instantiated per beamline. | The governance principals. |
-
-## Technique
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| TECH-1 | Blocks-go-live | Does X-ray footprinting (the dose-delivery technique, with offline MS readout) enter CORA's catalog as a Capability / Method? | Deferred: carried as pending Practices; `x_ray_footprinting` is new, the fleet's first dose-delivery Method; not coined. | The technique Capability. |
diff --git a/docs/deployments/xfp/techniques.md b/docs/deployments/xfp/techniques.md
deleted file mode 100644
index ecb2cd70c4f..00000000000
--- a/docs/deployments/xfp/techniques.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Techniques
-
-*What the modelled part of XFP is designed to do, as intent. First cut.*
-
-A technique is a portable [Catalog](../../catalog/methods.md) Method; a [Practice](../nsls2/index.md#the-techniques-adapted-here) is how a facility adapts it. XFP does one technique, **X-ray footprinting**, in two delivery modes: static / capillary-flow, and shutterless high-throughput. The Method below renders unlinked and is carried pending until the owner-scope decision (`TECH-1`) brings it into the catalog.
-
-| Technique | Catalog method | Notes |
-| --- | --- | --- |
-| X-ray footprinting (capillary-flow / static) | `x_ray_footprinting` | gate a timed white-beam dose onto a flowing solution capillary or flow-cell sample, recording exposure time x flux x attenuation as the delivered dose; the fleet's first dose-delivery Method, new to the catalog; readout is offline mass spec (`TECH-1`, `READOUT-1`) |
-| High-throughput footprinting (HTFly) | `x_ray_footprinting` | sweep a fly-cell row through the defining slit at a set stage velocity so the exposure (dose) is the slit gap over the velocity, across a 96-well plate; the same `x_ray_footprinting` Method with the HTFly stage as the dose-timing (`TECH-1`, `HT-1`) |
-
-Both modes need the [white-beam chain](source.md) (the mirror, the slits, the Al filter wheel for dose rate), the [dose gating](source.md) (the timed shutters or the delay-generator-fired Uniblitz, or the HTFly velocity), the [sample side](sample.md) (a stage and the delivery pump), and the [flux monitors](detector.md) (to record the delivered dose). They differ only in how the exposure is timed and how many samples are handled.
-
-## The technique is dose delivery, and the readout is offline
-
-This is the heart of what makes XFP a new shape for CORA. X-ray footprinting is not a measurement technique in the sense the rest of the fleet uses: the beamline does not record a structural signal. It **delivers a controlled radiolytic dose** to a biological macromolecule in solution, generating hydroxyl radicals that covalently modify the molecule at solvent-accessible sites. The modified sample is then analysed **offline by mass spectrometry**, which reveals which residues were exposed and thus maps the molecule's surface and conformational changes.
-
-So the Method `x_ray_footprinting` is a **dose-delivery** Method:
-
-- its controlled variable is the delivered dose (exposure time times flux times attenuation), not a detector setting;
-- its product is a footprinted sample plus a dose record, not a measurement frame;
-- its structural readout is the offline-readout seam (mass spec, downstream and off the beamline, `READOUT-1`).
-
-That is why `x_ray_footprinting` is proposed as a Method distinct from anything in the catalog: not because the optics are unusual (a white beam, a filter, a shutter), but because the experiment shape, dose-in, sample-out, structure-read-elsewhere, is genuinely new. Whether the catalog ultimately holds a `x_ray_footprinting` Capability, or a broader "controlled-dose / irradiation" Capability with footprinting as a Practice adaptation, is the owner-scope decision (`TECH-1`); XFP records the case, it does not mint the vocabulary. The matching Site Practices (`XFP_footprinting_practice`, `XFP_high_throughput_footprinting_practice`) are carried pending in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); each binding lands when its Capability does.
-
-## A time-resolved mode, deferred
-
-The profile collection also contains a time-resolved capillary-flow mode (a stopped-flow style mixing experiment before irradiation), but it is flagged unfinished in the source, so no Practice is recorded for it here; it is a later mode that would reuse the same `x_ray_footprinting` Method with a mixing step in the Procedure (`TECH-1`).
-
-## Not modelled yet
-
-The concrete acquisition recipes are not written yet. For footprinting that is the dose series (the set of exposure times or filter thicknesses that build a dose-response curve), the flow program that presents fresh sample, the aliquot-collection pattern, and the flux-to-absorbed-dose calibration that converts the measured flux to the dose the sample received (a seam constant that lives in offline analysis, `DOSE-1`). The downstream linkage to the offline mass-spec result is the offline-readout seam, not a beamline recipe (`READOUT-1`). These join as the deployment approaches the point where CORA drives XFP.
-
-Whether `x_ray_footprinting` enters CORA's catalog is an owner-scope decision on [Model](model.md): a modelling exercise reinforces the case but does not mint cross-facility Method vocabulary on its own. See [Open questions](questions.md) for the world-facts to confirm first.
diff --git a/docs/deployments/xpd/governance.md b/docs/deployments/xpd/governance.md
deleted file mode 100644
index 729470bebe6..00000000000
--- a/docs/deployments/xpd/governance.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Governance
-
-*Who may act at XPD and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
-
-People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
-
-## Who acts
-
-CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An XPD beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
-
-## The trust boundary
-
-CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start an acquisition, change the detector distance, run a temperature program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
-
-## High-throughput and the sample robot
-
-XPD's strength is throughput: a sample-array stage and a sample-changing robot let it run many powders unattended, often across temperature ramps. That is where CORA's custody and trust shapes earn their keep. CORA would model the autonomous exchange as a Procedure over the spine, threaded through the `Subject` aggregate so each sample's identity and provenance is tracked, and gated by a Clearance, the same shape as the I03 macromolecular-crystallography loop and the I15-1 powder exchange (ROBOT-1). If an autonomous Agent were added to choose the next sample or decide when a pattern is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
diff --git a/docs/deployments/xpd/model.md b/docs/deployments/xpd/model.md
deleted file mode 100644
index f21d584f08a..00000000000
--- a/docs/deployments/xpd/model.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Model
-
-*The developer's by-kind index: where each CORA aggregate's XPD content lives. It hosts no content of its own. Design-phase scaffold.*
-
-For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
-[modules](../../architecture/modules/index.md).
-
-| Aggregate (BC) | Where at XPD |
-| --- | --- |
-| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
-| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
-| Capability, Method (Recipe) | [Techniques](techniques.md) |
-| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (28-ID-A optics, 28-ID-C experiment) |
-| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](governance.md) |
-| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
-
-## Deliberately not here yet
-
-This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
-
-- **No new Family.** XPD is a reuse-and-reinforce deployment, the NSLS-II twin of Diamond i11 (powder diffraction) and i15-1 (total scattering / PDF): the flat panels bind `Camera`, the flux counters `FluxMonitor`, the sample environment `TemperatureController` (which i11 graduated, reinforced here at a second facility), the double-Laue monochromator `Monochromator`, the mirror `Mirror`, the pinhole `Aperture`, the exposure shutter `Shutter`.
-- **The graduated `PositionMonitor`.** The optics-hutch beam-position monitor binds the graduated catalog `PositionMonitor` Family that several APS and NSLS-II deployments share: it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset ion-chamber / quad-electrometer channel map stays open (DIAG-1), recorded in the promotion-review register.
-- **No new Capability or Method.** Powder diffraction and total scattering sit on the deferred `powder_diffraction` / `total_scattering` Capabilities Diamond i11 and i15-1 left pending (TECH-1); XPD reinforces both without coining either and records no Practice. The azimuthal integration and PDF reduction are `ComputePort` work.
-- **The autonomous sample robot.** Modelled as a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i15-1 autonomous-loop shape, not a new device family.
-- **The high-resolution channel** alongside the modelled main PDF channel: the high-resolution monochromator (`Mono:HRM`, in the 28-ID-C hutch) and the downstream high-resolution endstation (28-ID-D) are noted and deferred together (ENDSTATION-1), the way SRX deferred its micro endstation and 32-ID modelled one of several instruments.
-- **The calibration diffractometer (`Dif:2`)** and its Ecal wavelength-calibration routine (scanning against a standard to fit the beam wavelength) are a routine powder/PDF operation, deferred to a named question (CALIB-1) rather than modelled at this design phase. The dormant multi-analyzer stage (`MAD:DMS`) and the mono beam-defining slits (`Slt:MB1` / `Slt:MB2`) are deferred alongside it.
-- **The in-situ / operando accessories**: a QEPro UV-Vis spectrometer read in parallel with the diffraction pattern (a distinct optical-spectroscopy modality, not a `Camera`), the gas switcher, and the flash-sintering / electrochemistry power system, deferred to a named question (OPERANDO-1); the UV-Vis channel would need its own family decision when it lands.
-- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
diff --git a/docs/deployments/xpd/notes.md b/docs/deployments/xpd/notes.md
new file mode 100644
index 00000000000..d351174554e
--- /dev/null
+++ b/docs/deployments/xpd/notes.md
@@ -0,0 +1,109 @@
+# Notes
+
+## Techniques
+
+*What CORA would run at XPD: powder-diffraction and total-scattering techniques, each a [Catalog](../../catalog/methods.md) Method. XPD is the NSLS-II twin of the Diamond [I11](../i11/notes.md#techniques) (powder diffraction) and [I15-1](../i15-1/notes.md#techniques) (total scattering / PDF) beamlines, and it follows their deferral exactly.*
+
+XPD's techniques are powder diffraction and total scattering, a science domain Diamond's i11 and i15-1 brought to CORA as new Capabilities. As there, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
+
+| Technique | Mode | Notes |
+| --- | --- | --- |
+| Powder diffraction | monochromatic, flat panel | Debye-Scherrer rings on the flat panel at a chosen energy; the i11 Capability, new Capability pending (TECH-1) |
+| Total scattering / PDF | fixed high energy, close detector | wide-Q on the flat panel at a close detector distance; the i15-1 Capability, new Capability pending (TECH-1) |
+| Variable-temperature diffraction | over a temperature ramp | the same, over a ramp on the sample-environment stages (TEMP-1) |
+| Autonomous sample exchange | n/a | a Procedure over the spine, threaded through `Subject` custody and gated by a Clearance (ROBOT-1) |
+
+All the scattering techniques need the [diffractometer and sample stages](sample.md), the [flat-panel detectors](detector.md), and the detector distance; the exposure shutter gates the frames.
+
+### Why the Capabilities stay deferred
+
+Diamond i11 and i15-1 opened the question of whether the powder-diffraction and total-scattering Capabilities enter CORA's catalog (TECH-1), and `main` deliberately left them pending: a powder or PDF measurement is a new science Capability binding device Roles that already exist (the flat panel presents Detector, the diffractometer and mono present Positioner), so what is new is the Capability, not a device shape. XPD reinforces the case for both at a second facility without coining either, the same earn-the-abstraction discipline the deferred `xpcs` (CHX), `scanning` (HXN), and `energy_scan` (BMM) Capabilities follow. Because the defining Capabilities are not in the catalog, XPD records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); the binding lands when the Capability does.
+
+The azimuthal integration and pair-distribution-function reduction (the Fourier transform of the total-scattering structure function into a real-space PDF) are `ComputePort` work, not beamline Methods. The autonomous sample exchange reuses the i03 / i15-1 autonomous-loop shape: a Procedure over the spine, not a new device family (ROBOT-1).
+
+## Governance
+
+*Who may act at XPD and the trust shape CORA applies. This is CORA's governance design landing on the beamline, not a description of the beamline's current controls authority.*
+
+People and agents are facility principals at the [NSLS-II Site](../nsls2/index.md#safety-and-governance); on the beamline they surface through the actions they take. The human roster is not known from the profile collection (GOV-1), so the principals are the design shape, not a registered list.
+
+### Who acts
+
+CORA brings its own Access model: a small set of facility roles (operator, beamline scientist, safety reviewer, and the autonomous-agent and service principals) scoped at the NSLS-II Site. An XPD beamtime is run by an operator or beamline scientist Actor; a safety reviewer holds the clearance authority.
+
+### The trust boundary
+
+CORA's Trust BC (Zone, Conduit, Policy) gates every command by who is acting and what the beamline state allows: who may start an acquisition, change the detector distance, run a temperature program, override a caution, or commit a calibration. This authority is CORA's own, expressed per Actor, not inherited from the beamline's controls layer. The NSLS-II proposal and cycle are a fact CORA's Campaign uses for custody.
+
+### High-throughput and the sample robot
+
+XPD's strength is throughput: a sample-array stage and a sample-changing robot let it run many powders unattended, often across temperature ramps. That is where CORA's custody and trust shapes earn their keep. CORA would model the autonomous exchange as a Procedure over the spine, threaded through the `Subject` aggregate so each sample's identity and provenance is tracked, and gated by a Clearance, the same shape as the I03 macromolecular-crystallography loop and the I15-1 powder exchange (ROBOT-1). If an autonomous Agent were added to choose the next sample or decide when a pattern is good enough, it would be a facility principal scoped at the Site, governed by the same trust boundary, with each choice recorded as a [Decision](../../architecture/modules/decision/index.md). None is declared yet.
+
+## Model
+
+*The developer's by-kind index: where each CORA aggregate's XPD content lives. It hosts no content of its own. Design-phase scaffold.*
+
+For the aggregate shapes see the [architecture model](../../architecture/model.md) and the per-BC
+[modules](../../architecture/modules/index.md).
+
+| Aggregate (BC) | Where at XPD |
+| --- | --- |
+| Asset (Equipment) | the stage pages: [Source](source.md), [Sample](sample.md), [Detector](detector.md) |
+| Computed / virtual axes (Equipment) | [Source](source.md) (EnergyAxis) |
+| Capability, Method (Recipe) | [Techniques](#techniques) |
+| Enclosure (Enclosure) | [The beamline](index.md#enclosures) (28-ID-A optics, 28-ID-C experiment) |
+| Zone, Conduit, Policy (Trust); Actor (Access) | [Governance](#governance) |
+| Procedure, Recipe, Caution, Supply, Subject, Run, Campaign, Dataset, Decision | deferred (design-phase; see below) |
+
+### Deliberately not here yet
+
+This is a design-phase scaffold (descriptor + docs), mirroring the other NSLS-II and Diamond beamlines. Left out on purpose:
+
+- **No new Family.** XPD is a reuse-and-reinforce deployment, the NSLS-II twin of Diamond i11 (powder diffraction) and i15-1 (total scattering / PDF): the flat panels bind `Camera`, the flux counters `FluxMonitor`, the sample environment `TemperatureController` (which i11 graduated, reinforced here at a second facility), the double-Laue monochromator `Monochromator`, the mirror `Mirror`, the pinhole `Aperture`, the exposure shutter `Shutter`.
+- **The graduated `PositionMonitor`.** The optics-hutch beam-position monitor binds the graduated catalog `PositionMonitor` Family that several APS and NSLS-II deployments share: it presents the `Sensor` Role, earned across the wide fleet that shares it, distinct from `FluxMonitor` by measuring beam position rather than flux. The per-Asset ion-chamber / quad-electrometer channel map stays open (DIAG-1), recorded in the promotion-review register.
+- **No new Capability or Method.** Powder diffraction and total scattering sit on the deferred `powder_diffraction` / `total_scattering` Capabilities Diamond i11 and i15-1 left pending (TECH-1); XPD reinforces both without coining either and records no Practice. The azimuthal integration and PDF reduction are `ComputePort` work.
+- **The autonomous sample robot.** Modelled as a deferred Procedure over the spine threaded through `Subject` custody (ROBOT-1), reusing the i03 / i15-1 autonomous-loop shape, not a new device family.
+- **The high-resolution channel** alongside the modelled main PDF channel: the high-resolution monochromator (`Mono:HRM`, in the 28-ID-C hutch) and the downstream high-resolution endstation (28-ID-D) are noted and deferred together (ENDSTATION-1), the way SRX deferred its micro endstation and 32-ID modelled one of several instruments.
+- **The calibration diffractometer (`Dif:2`)** and its Ecal wavelength-calibration routine (scanning against a standard to fit the beam wavelength) are a routine powder/PDF operation, deferred to a named question (CALIB-1) rather than modelled at this design phase. The dormant multi-analyzer stage (`MAD:DMS`) and the mono beam-defining slits (`Slt:MB1` / `Slt:MB2`) are deferred alongside it.
+- **The in-situ / operando accessories**: a QEPro UV-Vis spectrometer read in parallel with the diffraction pattern (a distinct optical-spectroscopy modality, not a `Camera`), the gas switcher, and the flash-sintering / electrochemistry power system, deferred to a named question (OPERANDO-1); the UV-Vis channel would need its own family decision when it lands.
+- **Operations and experiment views, integration scenarios, vendor Models.** A runbook and registered Assets for a beamline CORA does not yet drive would be invention; they land when the design firms and the team confirms.
+
+## Open questions
+
+*What CORA needs the XPD team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/xpd-profile-collection`](https://github.com/NSLS2/xpd-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the source and endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
+
+Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
+
+### Source and safety
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| SRC-1 | Blocks-go-live | The source: 28-ID is a damping-wiggler beamline, but no source PV or parameters are in the profile collection. | An insertion-device (damping wiggler), identity-only, no PV. | The Source Asset PV and settings. |
+| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the endstation exposure shutter (`XF:28IDC-ES:1{Sh:Exp}`) is in source, not the front-end PPS leaves. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
+| ENDSTATION-1 | Nice-to-have | The high-resolution channel: the high-resolution monochromator (`Mono:HRM`, in the 28-ID-C hutch) and the downstream high-resolution endstation (28-ID-D) with its own sample stack (the `Stg:Stack` fine axes) and a third flat panel (`Det:PE3`). | The main PDF channel (DLM mono + 28-ID-C endstation) is modelled; the high-resolution channel is noted, deferred. | The HRM and 28-ID-D Assets. |
+
+### Optics
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DCM-1 | Nice-to-have | The double-Laue monochromator crystal and energy range, and the high-resolution monochromator crystal. Both (`Mono:DLM`, `Mono:HRM`) are in source. | Two Monochromator Assets, settings blank. | The Monochromator settings. |
+| ENERGY-1 | Nice-to-have | Does XPD ever scan energy as the measurement, or is it always fixed-energy per experiment? | Fixed-energy; energy_scan not modelled. | The energy Capability decision. |
+
+### Sample and detectors
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| STAGE-1 | Blocks-go-live | The full diffractometer axis set behind `Dif:1`, and whether the goniometric axes warrant a `Goniometer` plus a Diffractometer Assembly (the 8-ID / i11 precedent). | A `LinearStage` sample stack, rotation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
+| DET-1 | Blocks-go-live | Which flat panels are live (PerkinElmer pe1 / pe2, Dexela, the 28-ID-D pe3) vs the spare set, and the detector distance range. | pe1 primary, Dexela secondary; all Cameras; distance range blank. | The detector roster and Q-range. |
+| TEMP-1 | Nice-to-have | Which sample-environment units are live (Cryostream cs700 / cs800, Eurotherm, hot-air blower, Lakeshore cryostat, Linkam furnace)? | One `TemperatureController` Asset (the Cryostream); the others noted. | The sample-environment Assets. |
+| DIAG-1 | Nice-to-have | The ion-chamber and quad-electrometer channel map (which channel is I0); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only this per-Asset channel map stays open. | Read-only flux counters (`FluxMonitor`), the graduated catalog `PositionMonitor`; channel map blank. | The IonChamber / QuadElectrometer bindings. |
+| CALIB-1 | Nice-to-have | The energy / wavelength calibration: the calibration diffractometer (`Dif:2`: `th_cal`, `tth_cal`, `ecal_x`, `ecal_y`) and the Ecal routine that scans a standard to fit the beam wavelength, plus the dormant multi-analyzer stage (`MAD:DMS`) and the mono beam-defining slits (`Slt:MB1` / `Slt:MB2`). | A Procedure over the spine; these support devices deferred at this design phase. | The calibration Procedure and its devices. |
+| OPERANDO-1 | Nice-to-have | The in-situ / operando accessories: the QEPro UV-Vis spectrometer read in parallel with the diffraction pattern (a distinct optical-spectroscopy modality, not a `Camera`), the gas switcher (`Env:02`), and the flash-sintering / electrochemistry power system. | Deferred; the UV-Vis channel needs its own family decision when it lands. | The operando detector and sample-environment Assets. |
+| ROBOT-1 | Nice-to-have | The sample-changing robot (`XF:28IDC-ES:1{SM}`): CORA would model autonomous powder / capillary exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the I03 MX loop and the I15-1 powder exchange. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-handling Procedure and Subject custody thread. |
+
+### Controls
+
+| ID | Priority | Question | CORA assumes | Resolves |
+| --- | --- | --- | --- | --- |
+| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
+| TECH-1 | Blocks-go-live | Do the powder-diffraction and total-scattering / PDF Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i11 and i15-1 opened. | Capabilities deferred (rendered unlinked), no Practice recorded. | The powder / PDF Capability scope. |
diff --git a/docs/deployments/xpd/questions.md b/docs/deployments/xpd/questions.md
deleted file mode 100644
index 9b44d291044..00000000000
--- a/docs/deployments/xpd/questions.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Open questions
-
-*What CORA needs the XPD team to confirm. This model is reverse-engineered from public open source (the [`NSLS2/xpd-profile-collection`](https://github.com/NSLS2/xpd-profile-collection) profile collection): the EPICS PVs are read from it, but vendor identities, physical positions, and the source and endstation configuration are not. Each row is a fact the beamline team owns. It is a delete-on-answer queue.*
-
-Priorities: `Blocks-build`, `Blocks-go-live`, `Nice-to-have`.
-
-## Source and safety
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| SRC-1 | Blocks-go-live | The source: 28-ID is a damping-wiggler beamline, but no source PV or parameters are in the profile collection. | An insertion-device (damping wiggler), identity-only, no PV. | The Source Asset PV and settings. |
-| PSS-1 | Blocks-go-live | The PSS search-and-secure permit-leaf PVs. Only the endstation exposure shutter (`XF:28IDC-ES:1{Sh:Exp}`) is in source, not the front-end PPS leaves. | The permit signal is a confirm note, not a guessed PV. | The Enclosure permit signals. |
-| ENDSTATION-1 | Nice-to-have | The high-resolution channel: the high-resolution monochromator (`Mono:HRM`, in the 28-ID-C hutch) and the downstream high-resolution endstation (28-ID-D) with its own sample stack (the `Stg:Stack` fine axes) and a third flat panel (`Det:PE3`). | The main PDF channel (DLM mono + 28-ID-C endstation) is modelled; the high-resolution channel is noted, deferred. | The HRM and 28-ID-D Assets. |
-
-## Optics
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DCM-1 | Nice-to-have | The double-Laue monochromator crystal and energy range, and the high-resolution monochromator crystal. Both (`Mono:DLM`, `Mono:HRM`) are in source. | Two Monochromator Assets, settings blank. | The Monochromator settings. |
-| ENERGY-1 | Nice-to-have | Does XPD ever scan energy as the measurement, or is it always fixed-energy per experiment? | Fixed-energy; energy_scan not modelled. | The energy Capability decision. |
-
-## Sample and detectors
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| STAGE-1 | Blocks-go-live | The full diffractometer axis set behind `Dif:1`, and whether the goniometric axes warrant a `Goniometer` plus a Diffractometer Assembly (the 8-ID / i11 precedent). | A `LinearStage` sample stack, rotation axes and the Assembly deferred. | The SampleStage axes and orientation modelling. |
-| DET-1 | Blocks-go-live | Which flat panels are live (PerkinElmer pe1 / pe2, Dexela, the 28-ID-D pe3) vs the spare set, and the detector distance range. | pe1 primary, Dexela secondary; all Cameras; distance range blank. | The detector roster and Q-range. |
-| TEMP-1 | Nice-to-have | Which sample-environment units are live (Cryostream cs700 / cs800, Eurotherm, hot-air blower, Lakeshore cryostat, Linkam furnace)? | One `TemperatureController` Asset (the Cryostream); the others noted. | The sample-environment Assets. |
-| DIAG-1 | Nice-to-have | The ion-chamber and quad-electrometer channel map (which channel is I0); the `PositionMonitor` Family is settled (graduated catalog Family presenting `Sensor`), so only this per-Asset channel map stays open. | Read-only flux counters (`FluxMonitor`), the graduated catalog `PositionMonitor`; channel map blank. | The IonChamber / QuadElectrometer bindings. |
-| CALIB-1 | Nice-to-have | The energy / wavelength calibration: the calibration diffractometer (`Dif:2`: `th_cal`, `tth_cal`, `ecal_x`, `ecal_y`) and the Ecal routine that scans a standard to fit the beam wavelength, plus the dormant multi-analyzer stage (`MAD:DMS`) and the mono beam-defining slits (`Slt:MB1` / `Slt:MB2`). | A Procedure over the spine; these support devices deferred at this design phase. | The calibration Procedure and its devices. |
-| OPERANDO-1 | Nice-to-have | The in-situ / operando accessories: the QEPro UV-Vis spectrometer read in parallel with the diffraction pattern (a distinct optical-spectroscopy modality, not a `Camera`), the gas switcher (`Env:02`), and the flash-sintering / electrochemistry power system. | Deferred; the UV-Vis channel needs its own family decision when it lands. | The operando detector and sample-environment Assets. |
-| ROBOT-1 | Nice-to-have | The sample-changing robot (`XF:28IDC-ES:1{SM}`): CORA would model autonomous powder / capillary exchange as a Procedure over the spine threaded through the `Subject` aggregate and gated by a Clearance, the same shape as the I03 MX loop and the I15-1 powder exchange. | The robot is deferred autonomous-loop machinery, not a beam-path Asset. | The sample-handling Procedure and Subject custody thread. |
-
-## Controls
-
-| ID | Priority | Question | CORA assumes | Resolves |
-| --- | --- | --- | --- | --- |
-| DRIVE-1 | Blocks-go-live | The motion-controller box models, firmware, IPs. | Families bound (MotionController), specifics blank. | The MotionController Models. |
-| TECH-1 | Blocks-go-live | Do the powder-diffraction and total-scattering / PDF Capabilities enter CORA's catalog, or stay deferred? This is the same owner-scope decision Diamond i11 and i15-1 opened. | Capabilities deferred (rendered unlinked), no Practice recorded. | The powder / PDF Capability scope. |
diff --git a/docs/deployments/xpd/techniques.md b/docs/deployments/xpd/techniques.md
deleted file mode 100644
index 4cfac760599..00000000000
--- a/docs/deployments/xpd/techniques.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Techniques
-
-*What CORA would run at XPD: powder-diffraction and total-scattering techniques, each a [Catalog](../../catalog/methods.md) Method. XPD is the NSLS-II twin of the Diamond [I11](../i11/techniques.md) (powder diffraction) and [I15-1](../i15-1/techniques.md) (total scattering / PDF) beamlines, and it follows their deferral exactly.*
-
-XPD's techniques are powder diffraction and total scattering, a science domain Diamond's i11 and i15-1 brought to CORA as new Capabilities. As there, the Methods below render unlinked and are carried pending until the owner-scope decision (TECH-1) brings them into the catalog.
-
-| Technique | Mode | Notes |
-| --- | --- | --- |
-| Powder diffraction | monochromatic, flat panel | Debye-Scherrer rings on the flat panel at a chosen energy; the i11 Capability, new Capability pending (TECH-1) |
-| Total scattering / PDF | fixed high energy, close detector | wide-Q on the flat panel at a close detector distance; the i15-1 Capability, new Capability pending (TECH-1) |
-| Variable-temperature diffraction | over a temperature ramp | the same, over a ramp on the sample-environment stages (TEMP-1) |
-| Autonomous sample exchange | n/a | a Procedure over the spine, threaded through `Subject` custody and gated by a Clearance (ROBOT-1) |
-
-All the scattering techniques need the [diffractometer and sample stages](sample.md), the [flat-panel detectors](detector.md), and the detector distance; the exposure shutter gates the frames.
-
-## Why the Capabilities stay deferred
-
-Diamond i11 and i15-1 opened the question of whether the powder-diffraction and total-scattering Capabilities enter CORA's catalog (TECH-1), and `main` deliberately left them pending: a powder or PDF measurement is a new science Capability binding device Roles that already exist (the flat panel presents Detector, the diffractometer and mono present Positioner), so what is new is the Capability, not a device shape. XPD reinforces the case for both at a second facility without coining either, the same earn-the-abstraction discipline the deferred `xpcs` (CHX), `scanning` (HXN), and `energy_scan` (BMM) Capabilities follow. Because the defining Capabilities are not in the catalog, XPD records **no Practice** in the [NSLS-II Site](../nsls2/index.md#the-techniques-adapted-here); the binding lands when the Capability does.
-
-The azimuthal integration and pair-distribution-function reduction (the Fourier transform of the total-scattering structure function into a real-space PDF) are `ComputePort` work, not beamline Methods. The autonomous sample exchange reuses the i03 / i15-1 autonomous-loop shape: a Procedure over the spine, not a new device family (ROBOT-1).
diff --git a/mkdocs.yml b/mkdocs.yml
index 2a6ff91f63d..f2e4d0c8138 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -115,828 +115,19 @@ nav:
         - LLM debrief comparison: deployments/2-bm/llm_debrief.md
         - Model: deployments/2-bm/model.md
         - Open questions: deployments/2-bm/questions.md
-      - 2-ID:
-        - deployments/2-id/index.md
-        - Source: deployments/2-id/source.md
-        - Sample: deployments/2-id/sample.md
-        - Detector: deployments/2-id/detector.md
-        - Controls: deployments/2-id/controls.md
-        - Techniques: deployments/2-id/techniques.md
-        - Governance: deployments/2-id/governance.md
-        - Model: deployments/2-id/model.md
-        - Open questions: deployments/2-id/questions.md
-      - 7-BM:
-        - deployments/7-bm/index.md
-        - Source: deployments/7-bm/source.md
-        - Sample: deployments/7-bm/sample.md
-        - Detector: deployments/7-bm/detector.md
-        - Controls: deployments/7-bm/controls.md
-        - Techniques: deployments/7-bm/techniques.md
-        - Governance: deployments/7-bm/governance.md
-        - Model: deployments/7-bm/model.md
-        - Open questions: deployments/7-bm/questions.md
-      - 19-BM:
-        - deployments/19-bm/index.md
-        - Source: deployments/19-bm/source.md
-        - Sample: deployments/19-bm/sample.md
-        - Detector: deployments/19-bm/detector.md
-        - Controls: deployments/19-bm/controls.md
-        - Techniques: deployments/19-bm/techniques.md
-        - Governance: deployments/19-bm/governance.md
-        - Model: deployments/19-bm/model.md
-        - Open questions: deployments/19-bm/questions.md
-      - 32-ID:
-        - deployments/32-id/index.md
-        - Source: deployments/32-id/source.md
-        - Sample: deployments/32-id/sample.md
-        - Detector: deployments/32-id/detector.md
-        - Controls: deployments/32-id/controls.md
-        - Techniques: deployments/32-id/techniques.md
-        - Governance: deployments/32-id/governance.md
-        - Model: deployments/32-id/model.md
-        - Open questions: deployments/32-id/questions.md
-      - 4-ID:
-        - deployments/4-id/index.md
-        - Source: deployments/4-id/source.md
-        - Sample: deployments/4-id/sample.md
-        - Detector: deployments/4-id/detector.md
-        - Controls: deployments/4-id/controls.md
-        - Techniques: deployments/4-id/techniques.md
-        - Governance: deployments/4-id/governance.md
-        - Model: deployments/4-id/model.md
-        - Open questions: deployments/4-id/questions.md
-      - 8-ID:
-        - deployments/8-id/index.md
-        - Source: deployments/8-id/source.md
-        - Sample: deployments/8-id/sample.md
-        - Detector: deployments/8-id/detector.md
-        - Controls: deployments/8-id/controls.md
-        - Techniques: deployments/8-id/techniques.md
-        - Governance: deployments/8-id/governance.md
-        - Model: deployments/8-id/model.md
-        - Open questions: deployments/8-id/questions.md
-      - 9-ID:
-        - deployments/9-id/index.md
-        - Source: deployments/9-id/source.md
-        - Sample: deployments/9-id/sample.md
-        - Detector: deployments/9-id/detector.md
-        - Controls: deployments/9-id/controls.md
-        - Techniques: deployments/9-id/techniques.md
-        - Governance: deployments/9-id/governance.md
-        - Model: deployments/9-id/model.md
-        - Open questions: deployments/9-id/questions.md
-      - 12-ID:
-        - deployments/12-id/index.md
-        - Source: deployments/12-id/source.md
-        - Sample: deployments/12-id/sample.md
-        - Detector: deployments/12-id/detector.md
-        - Controls: deployments/12-id/controls.md
-        - Techniques: deployments/12-id/techniques.md
-        - Governance: deployments/12-id/governance.md
-        - Model: deployments/12-id/model.md
-        - Open questions: deployments/12-id/questions.md
-      - 13-ID:
-        - deployments/13-id/index.md
-        - Source: deployments/13-id/source.md
-        - Sample: deployments/13-id/sample.md
-        - Detector: deployments/13-id/detector.md
-        - Controls: deployments/13-id/controls.md
-        - Techniques: deployments/13-id/techniques.md
-        - Governance: deployments/13-id/governance.md
-        - Model: deployments/13-id/model.md
-        - Open questions: deployments/13-id/questions.md
-    - MAX IV:
-      - deployments/maxiv/index.md
-      - TomoWise:
-        - deployments/tomowise/index.md
-        - Source: deployments/tomowise/source.md
-        - Sample: deployments/tomowise/sample.md
-        - Detector: deployments/tomowise/detector.md
-        - Controls: deployments/tomowise/controls.md
-        - Techniques: deployments/tomowise/techniques.md
-        - Governance: deployments/tomowise/governance.md
-        - Model: deployments/tomowise/model.md
-        - Open questions: deployments/tomowise/questions.md
-    - Diamond:
-      - deployments/diamond/index.md
-      - I22:
-        - deployments/i22/index.md
-        - Source: deployments/i22/source.md
-        - Sample: deployments/i22/sample.md
-        - Detector: deployments/i22/detector.md
-        - Controls: deployments/i22/controls.md
-        - Techniques: deployments/i22/techniques.md
-        - Governance: deployments/i22/governance.md
-        - Model: deployments/i22/model.md
-        - Open questions: deployments/i22/questions.md
-      - I03:
-        - deployments/i03/index.md
-        - Source: deployments/i03/source.md
-        - Sample: deployments/i03/sample.md
-        - Detector: deployments/i03/detector.md
-        - Controls: deployments/i03/controls.md
-        - Techniques: deployments/i03/techniques.md
-        - Governance: deployments/i03/governance.md
-        - Model: deployments/i03/model.md
-        - Open questions: deployments/i03/questions.md
-      - I15-1:
-        - deployments/i15-1/index.md
-        - Source: deployments/i15-1/source.md
-        - Sample: deployments/i15-1/sample.md
-        - Detector: deployments/i15-1/detector.md
-        - Controls: deployments/i15-1/controls.md
-        - Techniques: deployments/i15-1/techniques.md
-        - Governance: deployments/i15-1/governance.md
-        - Model: deployments/i15-1/model.md
-        - Open questions: deployments/i15-1/questions.md
-      - I11:
-        - deployments/i11/index.md
-        - Source: deployments/i11/source.md
-        - Sample: deployments/i11/sample.md
-        - Detector: deployments/i11/detector.md
-        - Controls: deployments/i11/controls.md
-        - Techniques: deployments/i11/techniques.md
-        - Governance: deployments/i11/governance.md
-        - Model: deployments/i11/model.md
-        - Open questions: deployments/i11/questions.md
-      - I24:
-        - deployments/i24/index.md
-        - Source: deployments/i24/source.md
-        - Sample: deployments/i24/sample.md
-        - Detector: deployments/i24/detector.md
-        - Controls: deployments/i24/controls.md
-        - Techniques: deployments/i24/techniques.md
-        - Governance: deployments/i24/governance.md
-        - Model: deployments/i24/model.md
-        - Open questions: deployments/i24/questions.md
-      - I06:
-        - deployments/i06/index.md
-        - Source: deployments/i06/source.md
-        - Sample: deployments/i06/sample.md
-        - Controls: deployments/i06/controls.md
-        - Techniques: deployments/i06/techniques.md
-        - Governance: deployments/i06/governance.md
-        - Model: deployments/i06/model.md
-        - Open questions: deployments/i06/questions.md
-      - I10:
-        - deployments/i10/index.md
-        - Source: deployments/i10/source.md
-        - Sample: deployments/i10/sample.md
-        - Controls: deployments/i10/controls.md
-        - Techniques: deployments/i10/techniques.md
-        - Governance: deployments/i10/governance.md
-        - Model: deployments/i10/model.md
-        - Open questions: deployments/i10/questions.md
-      - I20-1:
-        - deployments/i20-1/index.md
-        - Source: deployments/i20-1/source.md
-        - Sample: deployments/i20-1/sample.md
-        - Detector: deployments/i20-1/detector.md
-        - Controls: deployments/i20-1/controls.md
-        - Techniques: deployments/i20-1/techniques.md
-        - Governance: deployments/i20-1/governance.md
-        - Model: deployments/i20-1/model.md
-        - Open questions: deployments/i20-1/questions.md
-      - I19:
-        - deployments/i19/index.md
-        - Source: deployments/i19/source.md
-        - Sample: deployments/i19/sample.md
-        - Controls: deployments/i19/controls.md
-        - Techniques: deployments/i19/techniques.md
-        - Governance: deployments/i19/governance.md
-        - Model: deployments/i19/model.md
-        - Open questions: deployments/i19/questions.md
-      - I13-1:
-        - deployments/i13-1/index.md
-        - Source: deployments/i13-1/source.md
-        - Sample: deployments/i13-1/sample.md
-        - Controls: deployments/i13-1/controls.md
-        - Techniques: deployments/i13-1/techniques.md
-        - Governance: deployments/i13-1/governance.md
-        - Model: deployments/i13-1/model.md
-        - Open questions: deployments/i13-1/questions.md
-    - NSLS-II:
-      - deployments/nsls2/index.md
-      - FXI:
-        - deployments/fxi/index.md
-        - Source: deployments/fxi/source.md
-        - Sample: deployments/fxi/sample.md
-        - Detector: deployments/fxi/detector.md
-        - Controls: deployments/fxi/controls.md
-        - Techniques: deployments/fxi/techniques.md
-        - Governance: deployments/fxi/governance.md
-        - Model: deployments/fxi/model.md
-        - Open questions: deployments/fxi/questions.md
-      - HXN:
-        - deployments/hxn/index.md
-        - Source: deployments/hxn/source.md
-        - Sample: deployments/hxn/sample.md
-        - Detector: deployments/hxn/detector.md
-        - Controls: deployments/hxn/controls.md
-        - Techniques: deployments/hxn/techniques.md
-        - Governance: deployments/hxn/governance.md
-        - Model: deployments/hxn/model.md
-        - Open questions: deployments/hxn/questions.md
-      - BMM:
-        - deployments/bmm/index.md
-        - Source: deployments/bmm/source.md
-        - Sample: deployments/bmm/sample.md
-        - Detector: deployments/bmm/detector.md
-        - Controls: deployments/bmm/controls.md
-        - Techniques: deployments/bmm/techniques.md
-        - Governance: deployments/bmm/governance.md
-        - Model: deployments/bmm/model.md
-        - Open questions: deployments/bmm/questions.md
-      - SRX:
-        - deployments/srx/index.md
-        - Source: deployments/srx/source.md
-        - Sample: deployments/srx/sample.md
-        - Detector: deployments/srx/detector.md
-        - Controls: deployments/srx/controls.md
-        - Techniques: deployments/srx/techniques.md
-        - Governance: deployments/srx/governance.md
-        - Model: deployments/srx/model.md
-        - Open questions: deployments/srx/questions.md
-      - SIX:
-        - deployments/six/index.md
-        - Source: deployments/six/source.md
-        - Sample: deployments/six/sample.md
-        - Detector: deployments/six/detector.md
-        - Controls: deployments/six/controls.md
-        - Techniques: deployments/six/techniques.md
-        - Governance: deployments/six/governance.md
-        - Model: deployments/six/model.md
-        - Open questions: deployments/six/questions.md
-      - CHX:
-        - deployments/chx/index.md
-        - Source: deployments/chx/source.md
-        - Sample: deployments/chx/sample.md
-        - Detector: deployments/chx/detector.md
-        - Controls: deployments/chx/controls.md
-        - Techniques: deployments/chx/techniques.md
-        - Governance: deployments/chx/governance.md
-        - Model: deployments/chx/model.md
-        - Open questions: deployments/chx/questions.md
-      - CSX:
-        - deployments/csx/index.md
-        - Source: deployments/csx/source.md
-        - Sample: deployments/csx/sample.md
-        - Detector: deployments/csx/detector.md
-        - Controls: deployments/csx/controls.md
-        - Techniques: deployments/csx/techniques.md
-        - Governance: deployments/csx/governance.md
-        - Model: deployments/csx/model.md
-        - Open questions: deployments/csx/questions.md
-      - IOS:
-        - deployments/ios/index.md
-        - Source: deployments/ios/source.md
-        - Sample: deployments/ios/sample.md
-        - Detector: deployments/ios/detector.md
-        - Controls: deployments/ios/controls.md
-        - Techniques: deployments/ios/techniques.md
-        - Governance: deployments/ios/governance.md
-        - Model: deployments/ios/model.md
-        - Open questions: deployments/ios/questions.md
-      - XPD:
-        - deployments/xpd/index.md
-        - Source: deployments/xpd/source.md
-        - Sample: deployments/xpd/sample.md
-        - Detector: deployments/xpd/detector.md
-        - Controls: deployments/xpd/controls.md
-        - Techniques: deployments/xpd/techniques.md
-        - Governance: deployments/xpd/governance.md
-        - Model: deployments/xpd/model.md
-        - Open questions: deployments/xpd/questions.md
-      - ESM:
-        - deployments/esm/index.md
-        - Source: deployments/esm/source.md
-        - Sample: deployments/esm/sample.md
-        - Detector: deployments/esm/detector.md
-        - Controls: deployments/esm/controls.md
-        - Techniques: deployments/esm/techniques.md
-        - Governance: deployments/esm/governance.md
-        - Model: deployments/esm/model.md
-        - Open questions: deployments/esm/questions.md
-      - SMI:
-        - deployments/smi/index.md
-        - Source: deployments/smi/source.md
-        - Sample: deployments/smi/sample.md
-        - Detector: deployments/smi/detector.md
-        - Controls: deployments/smi/controls.md
-        - Techniques: deployments/smi/techniques.md
-        - Governance: deployments/smi/governance.md
-        - Model: deployments/smi/model.md
-        - Open questions: deployments/smi/questions.md
-      - IXS:
-        - deployments/ixs/index.md
-        - Source: deployments/ixs/source.md
-        - Sample: deployments/ixs/sample.md
-        - Detector: deployments/ixs/detector.md
-        - Controls: deployments/ixs/controls.md
-        - Techniques: deployments/ixs/techniques.md
-        - Governance: deployments/ixs/governance.md
-        - Model: deployments/ixs/model.md
-        - Open questions: deployments/ixs/questions.md
-      - SST:
-        - deployments/sst/index.md
-        - Source: deployments/sst/source.md
-        - Sample: deployments/sst/sample.md
-        - Detector: deployments/sst/detector.md
-        - Controls: deployments/sst/controls.md
-        - Techniques: deployments/sst/techniques.md
-        - Governance: deployments/sst/governance.md
-        - Model: deployments/sst/model.md
-        - Open questions: deployments/sst/questions.md
-      - ISS:
-        - deployments/iss/index.md
-        - Source: deployments/iss/source.md
-        - Sample: deployments/iss/sample.md
-        - Detector: deployments/iss/detector.md
-        - Controls: deployments/iss/controls.md
-        - Techniques: deployments/iss/techniques.md
-        - Governance: deployments/iss/governance.md
-        - Model: deployments/iss/model.md
-        - Open questions: deployments/iss/questions.md
-      - FMX:
-        - deployments/fmx/index.md
-        - Source: deployments/fmx/source.md
-        - Sample: deployments/fmx/sample.md
-        - Detector: deployments/fmx/detector.md
-        - Controls: deployments/fmx/controls.md
-        - Techniques: deployments/fmx/techniques.md
-        - Governance: deployments/fmx/governance.md
-        - Model: deployments/fmx/model.md
-        - Open questions: deployments/fmx/questions.md
-      - CMS:
-        - deployments/cms/index.md
-        - Source: deployments/cms/source.md
-        - Sample: deployments/cms/sample.md
-        - Detector: deployments/cms/detector.md
-        - Controls: deployments/cms/controls.md
-        - Techniques: deployments/cms/techniques.md
-        - Governance: deployments/cms/governance.md
-        - Model: deployments/cms/model.md
-        - Open questions: deployments/cms/questions.md
-      - XFM:
-        - deployments/xfm/index.md
-        - Source: deployments/xfm/source.md
-        - Sample: deployments/xfm/sample.md
-        - Detector: deployments/xfm/detector.md
-        - Controls: deployments/xfm/controls.md
-        - Techniques: deployments/xfm/techniques.md
-        - Governance: deployments/xfm/governance.md
-        - Model: deployments/xfm/model.md
-        - Open questions: deployments/xfm/questions.md
-      - LIX:
-        - deployments/lix/index.md
-        - Source: deployments/lix/source.md
-        - Sample: deployments/lix/sample.md
-        - Detector: deployments/lix/detector.md
-        - Controls: deployments/lix/controls.md
-        - Techniques: deployments/lix/techniques.md
-        - Governance: deployments/lix/governance.md
-        - Model: deployments/lix/model.md
-        - Open questions: deployments/lix/questions.md
-      - HEX:
-        - deployments/hex/index.md
-        - Source: deployments/hex/source.md
-        - Sample: deployments/hex/sample.md
-        - Detector: deployments/hex/detector.md
-        - Controls: deployments/hex/controls.md
-        - Techniques: deployments/hex/techniques.md
-        - Governance: deployments/hex/governance.md
-        - Model: deployments/hex/model.md
-        - Open questions: deployments/hex/questions.md
-      - AMX:
-        - deployments/amx/index.md
-        - Source: deployments/amx/source.md
-        - Sample: deployments/amx/sample.md
-        - Detector: deployments/amx/detector.md
-        - Controls: deployments/amx/controls.md
-        - Techniques: deployments/amx/techniques.md
-        - Governance: deployments/amx/governance.md
-        - Model: deployments/amx/model.md
-        - Open questions: deployments/amx/questions.md
-      - XFP:
-        - deployments/xfp/index.md
-        - Source: deployments/xfp/source.md
-        - Sample: deployments/xfp/sample.md
-        - Detector: deployments/xfp/detector.md
-        - Controls: deployments/xfp/controls.md
-        - Techniques: deployments/xfp/techniques.md
-        - Governance: deployments/xfp/governance.md
-        - Model: deployments/xfp/model.md
-        - Open questions: deployments/xfp/questions.md
-      - ISR:
-        - deployments/isr/index.md
-        - Source: deployments/isr/source.md
-        - Sample: deployments/isr/sample.md
-        - Detector: deployments/isr/detector.md
-        - Controls: deployments/isr/controls.md
-        - Techniques: deployments/isr/techniques.md
-        - Governance: deployments/isr/governance.md
-        - Model: deployments/isr/model.md
-        - Open questions: deployments/isr/questions.md
-      - CDI:
-        - deployments/cdi/index.md
-        - Source: deployments/cdi/source.md
-        - Sample: deployments/cdi/sample.md
-        - Detector: deployments/cdi/detector.md
-        - Controls: deployments/cdi/controls.md
-        - Techniques: deployments/cdi/techniques.md
-        - Governance: deployments/cdi/governance.md
-        - Model: deployments/cdi/model.md
-        - Open questions: deployments/cdi/questions.md
-      - PDF:
-        - deployments/pdf/index.md
-        - Source: deployments/pdf/source.md
-        - Sample: deployments/pdf/sample.md
-        - Detector: deployments/pdf/detector.md
-        - Controls: deployments/pdf/controls.md
-        - Techniques: deployments/pdf/techniques.md
-        - Governance: deployments/pdf/governance.md
-        - Model: deployments/pdf/model.md
-        - Open questions: deployments/pdf/questions.md
-    - SLAC:
-      - deployments/slac/index.md
-      - LCLS-MFX:
-        - deployments/lcls-mfx/index.md
-        - Source: deployments/lcls-mfx/source.md
-        - Sample: deployments/lcls-mfx/sample.md
-        - Detector: deployments/lcls-mfx/detector.md
-        - Controls: deployments/lcls-mfx/controls.md
-        - Techniques: deployments/lcls-mfx/techniques.md
-        - Governance: deployments/lcls-mfx/governance.md
-        - Model: deployments/lcls-mfx/model.md
-        - Open questions: deployments/lcls-mfx/questions.md
-    - Australian Synchrotron:
-      - deployments/as/index.md
-      - MX3:
-        - deployments/mx3/index.md
-        - Source: deployments/mx3/source.md
-        - Sample: deployments/mx3/sample.md
-        - Detector: deployments/mx3/detector.md
-        - Controls: deployments/mx3/controls.md
-        - Techniques: deployments/mx3/techniques.md
-        - Governance: deployments/mx3/governance.md
-        - Model: deployments/mx3/model.md
-        - Open questions: deployments/mx3/questions.md
-    - ESRF:
-      - deployments/esrf/index.md
-      - ID32:
-        - deployments/id32/index.md
-        - Source: deployments/id32/source.md
-        - Sample: deployments/id32/sample.md
-        - Detector: deployments/id32/detector.md
-        - Controls: deployments/id32/controls.md
-        - Techniques: deployments/id32/techniques.md
-        - Governance: deployments/id32/governance.md
-        - Model: deployments/id32/model.md
-        - Open questions: deployments/id32/questions.md
-      - ID19:
-        - deployments/id19/index.md
-        - Source: deployments/id19/source.md
-        - Sample: deployments/id19/sample.md
-        - Detector: deployments/id19/detector.md
-        - Controls: deployments/id19/controls.md
-        - Techniques: deployments/id19/techniques.md
-        - Governance: deployments/id19/governance.md
-        - Model: deployments/id19/model.md
-        - Open questions: deployments/id19/questions.md
-      - ID16B:
-        - deployments/id16b/index.md
-        - Source: deployments/id16b/source.md
-        - Sample: deployments/id16b/sample.md
-        - Detector: deployments/id16b/detector.md
-        - Controls: deployments/id16b/controls.md
-        - Techniques: deployments/id16b/techniques.md
-        - Governance: deployments/id16b/governance.md
-        - Model: deployments/id16b/model.md
-        - Open questions: deployments/id16b/questions.md
-      - ID28:
-        - deployments/id28/index.md
-        - Source: deployments/id28/source.md
-        - Sample: deployments/id28/sample.md
-        - Detector: deployments/id28/detector.md
-        - Controls: deployments/id28/controls.md
-        - Techniques: deployments/id28/techniques.md
-        - Governance: deployments/id28/governance.md
-        - Model: deployments/id28/model.md
-        - Open questions: deployments/id28/questions.md
-    - PSI:
-      - deployments/psi/index.md
-      - I-TOMCAT:
-        - deployments/i-tomcat/index.md
-        - Source: deployments/i-tomcat/source.md
-        - Sample: deployments/i-tomcat/sample.md
-        - Detector: deployments/i-tomcat/detector.md
-        - Controls: deployments/i-tomcat/controls.md
-        - Techniques: deployments/i-tomcat/techniques.md
-        - Governance: deployments/i-tomcat/governance.md
-        - Model: deployments/i-tomcat/model.md
-        - Open questions: deployments/i-tomcat/questions.md
-      - Alvra:
-        - deployments/alvra/index.md
-        - Source: deployments/alvra/source.md
-        - Sample: deployments/alvra/sample.md
-        - Detector: deployments/alvra/detector.md
-        - Controls: deployments/alvra/controls.md
-        - Techniques: deployments/alvra/techniques.md
-        - Governance: deployments/alvra/governance.md
-        - Model: deployments/alvra/model.md
-        - Open questions: deployments/alvra/questions.md
-      - Bernina:
-        - deployments/bernina/index.md
-        - Source: deployments/bernina/source.md
-        - Sample: deployments/bernina/sample.md
-        - Detector: deployments/bernina/detector.md
-        - Controls: deployments/bernina/controls.md
-        - Techniques: deployments/bernina/techniques.md
-        - Governance: deployments/bernina/governance.md
-        - Model: deployments/bernina/model.md
-        - Open questions: deployments/bernina/questions.md
-      - Cristallina:
-        - deployments/cristallina/index.md
-        - Source: deployments/cristallina/source.md
-        - Sample: deployments/cristallina/sample.md
-        - Detector: deployments/cristallina/detector.md
-        - Controls: deployments/cristallina/controls.md
-        - Techniques: deployments/cristallina/techniques.md
-        - Governance: deployments/cristallina/governance.md
-        - Model: deployments/cristallina/model.md
-        - Open questions: deployments/cristallina/questions.md
-    - Sirius:
-      - deployments/sirius/index.md
-      - MOGNO:
-        - deployments/mogno/index.md
-        - Source: deployments/mogno/source.md
-        - Sample: deployments/mogno/sample.md
-        - Detector: deployments/mogno/detector.md
-        - Controls: deployments/mogno/controls.md
-        - Techniques: deployments/mogno/techniques.md
-        - Governance: deployments/mogno/governance.md
-        - Model: deployments/mogno/model.md
-        - Open questions: deployments/mogno/questions.md
-      - MANACA:
-        - deployments/manaca/index.md
-        - Source: deployments/manaca/source.md
-        - Sample: deployments/manaca/sample.md
-        - Detector: deployments/manaca/detector.md
-        - Controls: deployments/manaca/controls.md
-        - Techniques: deployments/manaca/techniques.md
-        - Governance: deployments/manaca/governance.md
-        - Model: deployments/manaca/model.md
-        - Open questions: deployments/manaca/questions.md
-    - Elettra:
-      - deployments/elettra/index.md
-      - SYRMEP:
-        - deployments/syrmep/index.md
-        - Source: deployments/syrmep/source.md
-        - Sample: deployments/syrmep/sample.md
-        - Detector: deployments/syrmep/detector.md
-        - Controls: deployments/syrmep/controls.md
-        - Techniques: deployments/syrmep/techniques.md
-        - Governance: deployments/syrmep/governance.md
-        - Model: deployments/syrmep/model.md
-        - Open questions: deployments/syrmep/questions.md
-    - ALBA:
-      - deployments/alba/index.md
-      - FAXTOR:
-        - deployments/faxtor/index.md
-        - Source: deployments/faxtor/source.md
-        - Sample: deployments/faxtor/sample.md
-        - Detector: deployments/faxtor/detector.md
-        - Controls: deployments/faxtor/controls.md
-        - Techniques: deployments/faxtor/techniques.md
-        - Governance: deployments/faxtor/governance.md
-        - Model: deployments/faxtor/model.md
-        - Open questions: deployments/faxtor/questions.md
-    - NSRRC:
-      - deployments/nsrrc/index.md
-      - TPS 07A:
-        - deployments/tps-07a/index.md
-        - Source: deployments/tps-07a/source.md
-        - Sample: deployments/tps-07a/sample.md
-        - Detector: deployments/tps-07a/detector.md
-        - Controls: deployments/tps-07a/controls.md
-        - Techniques: deployments/tps-07a/techniques.md
-        - Governance: deployments/tps-07a/governance.md
-        - Model: deployments/tps-07a/model.md
-        - Open questions: deployments/tps-07a/questions.md
-      - TPS 05A:
-        - deployments/tps-05a/index.md
-        - Source: deployments/tps-05a/source.md
-        - Sample: deployments/tps-05a/sample.md
-        - Detector: deployments/tps-05a/detector.md
-        - Controls: deployments/tps-05a/controls.md
-        - Techniques: deployments/tps-05a/techniques.md
-        - Governance: deployments/tps-05a/governance.md
-        - Model: deployments/tps-05a/model.md
-        - Open questions: deployments/tps-05a/questions.md
-    - PETRA III:
-      - deployments/petra-iii/index.md
-      - P01:
-        - deployments/p01/index.md
-        - Source: deployments/p01/source.md
-        - Sample: deployments/p01/sample.md
-        - Detector: deployments/p01/detector.md
-        - Controls: deployments/p01/controls.md
-        - Techniques: deployments/p01/techniques.md
-        - Governance: deployments/p01/governance.md
-        - Model: deployments/p01/model.md
-        - Open questions: deployments/p01/questions.md
-      - P04:
-        - deployments/p04/index.md
-        - Source: deployments/p04/source.md
-        - Sample: deployments/p04/sample.md
-        - Detector: deployments/p04/detector.md
-        - Controls: deployments/p04/controls.md
-        - Techniques: deployments/p04/techniques.md
-        - Governance: deployments/p04/governance.md
-        - Model: deployments/p04/model.md
-        - Open questions: deployments/p04/questions.md
-      - P06:
-        - deployments/p06/index.md
-        - Source: deployments/p06/source.md
-        - Sample: deployments/p06/sample.md
-        - Detector: deployments/p06/detector.md
-        - Controls: deployments/p06/controls.md
-        - Techniques: deployments/p06/techniques.md
-        - Governance: deployments/p06/governance.md
-        - Model: deployments/p06/model.md
-        - Open questions: deployments/p06/questions.md
-      - P11:
-        - deployments/p11/index.md
-        - Source: deployments/p11/source.md
-        - Sample: deployments/p11/sample.md
-        - Detector: deployments/p11/detector.md
-        - Controls: deployments/p11/controls.md
-        - Techniques: deployments/p11/techniques.md
-        - Governance: deployments/p11/governance.md
-        - Model: deployments/p11/model.md
-        - Open questions: deployments/p11/questions.md
-      - P13:
-        - deployments/p13/index.md
-        - Source: deployments/p13/source.md
-        - Sample: deployments/p13/sample.md
-        - Detector: deployments/p13/detector.md
-        - Controls: deployments/p13/controls.md
-        - Techniques: deployments/p13/techniques.md
-        - Governance: deployments/p13/governance.md
-        - Model: deployments/p13/model.md
-        - Open questions: deployments/p13/questions.md
-      - P14:
-        - deployments/p14/index.md
-        - Source: deployments/p14/source.md
-        - Sample: deployments/p14/sample.md
-        - Detector: deployments/p14/detector.md
-        - Controls: deployments/p14/controls.md
-        - Techniques: deployments/p14/techniques.md
-        - Governance: deployments/p14/governance.md
-        - Model: deployments/p14/model.md
-        - Open questions: deployments/p14/questions.md
-      - P03:
-        - deployments/p03/index.md
-        - Source: deployments/p03/source.md
-        - Sample: deployments/p03/sample.md
-        - Detector: deployments/p03/detector.md
-        - Controls: deployments/p03/controls.md
-        - Techniques: deployments/p03/techniques.md
-        - Governance: deployments/p03/governance.md
-        - Model: deployments/p03/model.md
-        - Open questions: deployments/p03/questions.md
-      - P10:
-        - deployments/p10/index.md
-        - Source: deployments/p10/source.md
-        - Sample: deployments/p10/sample.md
-        - Detector: deployments/p10/detector.md
-        - Controls: deployments/p10/controls.md
-        - Techniques: deployments/p10/techniques.md
-        - Governance: deployments/p10/governance.md
-        - Model: deployments/p10/model.md
-        - Open questions: deployments/p10/questions.md
-      - P09:
-        - deployments/p09/index.md
-        - Source: deployments/p09/source.md
-        - Sample: deployments/p09/sample.md
-        - Detector: deployments/p09/detector.md
-        - Controls: deployments/p09/controls.md
-        - Techniques: deployments/p09/techniques.md
-        - Governance: deployments/p09/governance.md
-        - Model: deployments/p09/model.md
-        - Open questions: deployments/p09/questions.md
-      - P02:
-        - deployments/p02/index.md
-        - Source: deployments/p02/source.md
-        - Sample: deployments/p02/sample.md
-        - Detector: deployments/p02/detector.md
-        - Controls: deployments/p02/controls.md
-        - Techniques: deployments/p02/techniques.md
-        - Governance: deployments/p02/governance.md
-        - Model: deployments/p02/model.md
-        - Open questions: deployments/p02/questions.md
-      - P64:
-        - deployments/p64/index.md
-        - Source: deployments/p64/source.md
-        - Sample: deployments/p64/sample.md
-        - Detector: deployments/p64/detector.md
-        - Controls: deployments/p64/controls.md
-        - Techniques: deployments/p64/techniques.md
-        - Governance: deployments/p64/governance.md
-        - Model: deployments/p64/model.md
-        - Open questions: deployments/p64/questions.md
-      - P65:
-        - deployments/p65/index.md
-        - Source: deployments/p65/source.md
-        - Sample: deployments/p65/sample.md
-        - Detector: deployments/p65/detector.md
-        - Controls: deployments/p65/controls.md
-        - Techniques: deployments/p65/techniques.md
-        - Governance: deployments/p65/governance.md
-        - Model: deployments/p65/model.md
-        - Open questions: deployments/p65/questions.md
-      - P07:
-        - deployments/p07/index.md
-        - Source: deployments/p07/source.md
-        - Sample: deployments/p07/sample.md
-        - Detector: deployments/p07/detector.md
-        - Controls: deployments/p07/controls.md
-        - Techniques: deployments/p07/techniques.md
-        - Governance: deployments/p07/governance.md
-        - Model: deployments/p07/model.md
-        - Open questions: deployments/p07/questions.md
-      - P08:
-        - deployments/p08/index.md
-        - Source: deployments/p08/source.md
-        - Sample: deployments/p08/sample.md
-        - Detector: deployments/p08/detector.md
-        - Controls: deployments/p08/controls.md
-        - Techniques: deployments/p08/techniques.md
-        - Governance: deployments/p08/governance.md
-        - Model: deployments/p08/model.md
-        - Open questions: deployments/p08/questions.md
-      - P21:
-        - deployments/p21/index.md
-        - Source: deployments/p21/source.md
-        - Sample: deployments/p21/sample.md
-        - Detector: deployments/p21/detector.md
-        - Controls: deployments/p21/controls.md
-        - Techniques: deployments/p21/techniques.md
-        - Governance: deployments/p21/governance.md
-        - Model: deployments/p21/model.md
-        - Open questions: deployments/p21/questions.md
-      - P22:
-        - deployments/p22/index.md
-        - Source: deployments/p22/source.md
-        - Sample: deployments/p22/sample.md
-        - Detector: deployments/p22/detector.md
-        - Controls: deployments/p22/controls.md
-        - Techniques: deployments/p22/techniques.md
-        - Governance: deployments/p22/governance.md
-        - Model: deployments/p22/model.md
-        - Open questions: deployments/p22/questions.md
-      - P23:
-        - deployments/p23/index.md
-        - Source: deployments/p23/source.md
-        - Sample: deployments/p23/sample.md
-        - Detector: deployments/p23/detector.md
-        - Controls: deployments/p23/controls.md
-        - Techniques: deployments/p23/techniques.md
-        - Governance: deployments/p23/governance.md
-        - Model: deployments/p23/model.md
-        - Open questions: deployments/p23/questions.md
-      - P24:
-        - deployments/p24/index.md
-        - Source: deployments/p24/source.md
-        - Sample: deployments/p24/sample.md
-        - Detector: deployments/p24/detector.md
-        - Controls: deployments/p24/controls.md
-        - Techniques: deployments/p24/techniques.md
-        - Governance: deployments/p24/governance.md
-        - Model: deployments/p24/model.md
-        - Open questions: deployments/p24/questions.md
-      - P61:
-        - deployments/p61/index.md
-        - Source: deployments/p61/source.md
-        - Sample: deployments/p61/sample.md
-        - Detector: deployments/p61/detector.md
-        - Controls: deployments/p61/controls.md
-        - Techniques: deployments/p61/techniques.md
-        - Governance: deployments/p61/governance.md
-        - Model: deployments/p61/model.md
-        - Open questions: deployments/p61/questions.md
-    - ALS:
-      - deployments/als/index.md
-      - 8.3.2:
-        - deployments/8-3-2/index.md
-        - Source: deployments/8-3-2/source.md
-        - Sample: deployments/8-3-2/sample.md
-        - Detector: deployments/8-3-2/detector.md
-        - Controls: deployments/8-3-2/controls.md
-        - Techniques: deployments/8-3-2/techniques.md
-        - Governance: deployments/8-3-2/governance.md
-        - Model: deployments/8-3-2/model.md
-        - Open questions: deployments/8-3-2/questions.md
+    - MAX IV: deployments/maxiv/index.md
+    - Diamond: deployments/diamond/index.md
+    - NSLS-II: deployments/nsls2/index.md
+    - SLAC: deployments/slac/index.md
+    - Australian Synchrotron: deployments/as/index.md
+    - ESRF: deployments/esrf/index.md
+    - PSI: deployments/psi/index.md
+    - Sirius: deployments/sirius/index.md
+    - Elettra: deployments/elettra/index.md
+    - ALBA: deployments/alba/index.md
+    - NSRRC: deployments/nsrrc/index.md
+    - PETRA III: deployments/petra-iii/index.md
+    - ALS: deployments/als/index.md
   - Catalog:
     - catalog/index.md
     - Capabilities: catalog/capabilities.md
@@ -1039,6 +230,9 @@ strict: false
 
 validation:
   nav:
-    omitted_files: warn
+    # Most deployment pages (all but the 2-BM pilot) are reachable from their
+    # Site's roster and their own index.md "More" links, not force-listed in
+    # nav, so a built-but-unlisted page is expected here, not a mistake.
+    omitted_files: ignore
   links:
     anchors: warn
diff --git a/scripts/beamline_pages.py b/scripts/beamline_pages.py
index a2898eda588..099137bcae5 100644
--- a/scripts/beamline_pages.py
+++ b/scripts/beamline_pages.py
@@ -568,9 +568,8 @@ def _render_index(
 
     blocks.append("## More")
     blocks.append(
-        "- [Techniques](techniques.md): what the beamline is for.\n"
-        "- [Governance](governance.md): who acts, and the trust shape that gates them.\n"
-        "- [Open questions](questions.md): the world-facts CORA needs staff to confirm."
+        "- [Notes](notes.md): techniques, governance, the CORA model index, and "
+        "open modelling questions."
     )
     return "\n\n".join(blocks) + "\n"
 
diff --git a/scripts/mkdocs_hooks.py b/scripts/mkdocs_hooks.py
index a9da332c7b2..4705b954a84 100644
--- a/scripts/mkdocs_hooks.py
+++ b/scripts/mkdocs_hooks.py
@@ -230,46 +230,9 @@ def on_page_markdown(
             descriptor=_beamline_descriptor_for(src_uri),
             src_uri=src_uri,
         )
-    # Every Open questions page asks beamline staff to confirm facts, and until
-    # now only 2-BM told them how to answer or what the priority words mean. The
-    # footer is appended here rather than written into 83 hand-authored files,
-    # and before the link rewrite so its links resolve like any other.
-    if (
-        src_uri.startswith("deployments/")
-        and src_uri.endswith("/questions.md")
-        and "## How to reply" not in markdown
-    ):
-        markdown = markdown.rstrip() + _QUESTIONS_FOOTER
-
     return _rewrite_in_page(src_uri, markdown)
 
 
-# No anchors in here: it lands on 83 pages, so one bad fragment would become 83.
-_QUESTIONS_FOOTER = """
-
-## Answering one of these
-
-Every row above is a question about the real beamline, and any of them can be
-answered by someone who knows the hardware. You do not need to edit this page
-or know where it lives.
-
-Open a short issue at
-[github.com/xmap/cora/issues](https://github.com/xmap/cora/issues), quote the
-item ID, and write the answer in plain text. One answer is as welcome as
-several. If you do not use GitHub, send the same thing to whoever shared this
-page with you. If a row turns out to be a controls, network, or engineering
-question, pass it to the right person or tell us who that is.
-
-The priorities mean: `Blocks-build`, your answer changes the structure of the
-description, so CORA cannot finalise it until you reply; `Blocks-go-live`, a
-guess is fine for the description, but the real value is needed before CORA
-controls or observes the hardware; `Nice-to-have`, extra detail for the record.
-
-Once an item is confirmed we record the value and delete the row, so this page
-always shows only what is still open.
-"""
-
-
 def on_files(files: Any, *, config: Any) -> Any:
     """Inject the generated pages as virtual files.