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, 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). It is a delete-on-answer queue. Priorities are Blocks-build, Blocks-go-live, and Nice-to-have.
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.