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, src/dodal/beamlines/i24.py and its device classes), so the control handles in the Inventory 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). It is a delete-on-answer queue. Priorities are Blocks-build, Blocks-go-live, and Nice-to-have.
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.
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.
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.
Reuses I03's loose Backlight family; the root BL24I and positions pending.