docs(2-bm): fold the vibration answers, drop the one-off baseline stubs (VIB-1..7)

apps/api/tests/architecture/test_procedure_kind_naming.py

@@ -48,15 +48,14 @@
 )
 
 # Whole-kind carve-outs, with rationale:
-#   first_light                  - whole-system milestone, no single subject
-#   {dark,flat,vibration}_baseline - capture-and-store; the trailing noun is
-#                                  the produced artifact, not the operation
+#   first_light            - whole-system milestone, no single subject
+#   {dark,flat}_baseline   - capture-and-store; the trailing noun is the
+#                            produced artifact, not the operation
 CARVE_OUT_KINDS = frozenset(
     {
         "first_light",
         "dark_baseline",
         "flat_baseline",
-        "vibration_baseline",
     }
 )
 

deployments/2-bm/beamline.yaml

@@ -558,6 +558,13 @@ detector:
       firmware_version: "1710.0.0.0"
       part_number_reported: "Oryx ORX-10G-51S5M"   # IOC-reported; catalog SKU ORX-10G-51S5M-C is the same class (10G vs 10GS = form factor only)
       replaceable: true
+      note: >-
+        This same physical camera (serial 19173710) also serves the 2-BM
+        vibration / flat-field-stability characterization: that is a high-frame-
+        rate operating mode (about 99 fps, 1000-frame HDF5 stream), not separate
+        hardware (VIB-1, #265). The February 2026 vibration study (item_070) was a
+        one-off, inconclusive investigation, so no standing vibration Procedure or
+        Caution is modeled (VIB-2..7, #267).
     - name: Camera_HighRes
       family: Camera             # camera 1 (item_020): FLIR Oryx 31 MP, the alternate detector selected by Camera_Selector
       model: flir_oryx_31mp

deployments/aps/site.yaml

@@ -50,7 +50,6 @@ practices:
   - {name: Per-objective resolution variant, method: resolution_alignment, pending: true, note: "Mitutoyo 1.1x / 2x / 10x objectives"}
   - {name: 2BM_energy_characterization_practice, method: energy_characterization, pending: true}
   - {name: 2BM_ioc_restart_practice, method: ioc_restart, pending: true}
-  - {name: 2BM_vibration_baseline_practice, method: vibration_baseline, pending: true}
   - {name: 2BM_mirror_recoat_practice, method: mirror_recoat_return, pending: true}
 
 # Access BC Actors that are conceptually facility-wide at APS. Actor display

docs/deployments/2-bm/questions.md

@@ -131,13 +131,6 @@ CORA will read proposal and user information from the APS scheduling system (the
 | SCHED-2 | `Nice-to-have` | Is the beamline staff contact (local contact) for a beamtime listed among that experiment's users in the scheduling system, or tracked separately as a beamline-side assignment? | listed as one of the beamtime's people | not yet | [2-BM index](index.md) |
 | SCHED-3 | `Nice-to-have` | Are APS badge numbers ever reused or reassigned to a different person over time, or is a badge number stable for life per person? And under APS data governance, is a badge number classified as personal data subject to deletion on request? Confirmer: APS User Office / data-management contact. | badge stable per person; classified as deletable personal data | not yet | [2-BM index](index.md) |
 
-## Vibration and beam stability
-
-The [docs2bm item_070 page](https://docs2bm.readthedocs.io/en/latest/source/ops/item_070.html) documents three characterization measurements of the beamline itself: a high-speed vibration baseline, an air-handler shutdown test, and a multi-hour flat-field stability run. CORA models these as subject-less characterization captures, the Pending [`vibration_baseline`](procedures.md) Procedure / Run / Dataset and two operator [Cautions](cautions.md); the FFT and stripe-motion analysis stays downstream. These rows confirm the real-beamline facts that turn those stubs into records. Source: the staff-authored item_070 page.
-
-| ID | Priority | Question | CORA assumes | Already done? | Resolves |
-| --- | --- | --- | --- | --- | --- |
-
 ## Not on this page
 
 Hardware CORA has deliberately not described yet (the wider sample-stage motor band, IOC-hosted devices, past high-speed cameras) raises questions here only once CORA starts describing it. The `Mirror` is the exception that proves the rule: it is a registered Asset ([Inventory](inventory.md#inventory)) and its coating-stripe sweep is now modelled (`Mirror_StripeReachX`); only the coordinated mirror-table X binding stays open (`MODE-3`), blocked on the IOC substitution fix.