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 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.