List of microscopes

[vredchenko]

Encode the list of microscope as a hardcode in smartem_backend initially, to be updated by hand, then look at better ways of doing it. This may be useful for authenticating smartem_agents (do we recognise this microscope) and potentially for /admin route in the f/e

This is the list:

• Krios 1 - m02
• Krios 2 - m03
• Talos - m04
• Scios - m05
• Krios 3 - m06
• Krios 4 - m07
• Krios 5 - m08
• Glacios 1 - m10
• Aquilos - m11
• Glacios 2 - m12
• Leica cryoCLEM - m14

the true source of truth is UAS which we don’t have programmatic access to. it’s the user administration system. it’s how users apply for beam time and see what is scheduled. uas.diamond.ac.uk. it’s separated from other systems so a bunch of the information in there ends up being mirrored in ISPyB (https://github.com/DiamondLightSource/ispyb-database) which is what we use as the source of truth for sessions and what instrument they’re booked on. Guilherme de Freitas may have ideas on how to get this list programatically.

[vredchenko]

Current reality check (2026-05-29)

Backend (smartem-decisions)

No instruments endpoint and no hardcoded list. src/smartem_backend/http_api/ has no router exposing instruments/microscopes, and there is no module defining the canonical list. The only mentions of instruments in the backend are the instrument_model: str | null and instrument_id: str | null fields on AcquisitionResponse / AcquisitionCreateRequest / AcquisitionUpdateRequest — i.e. free-form strings supplied by callers, not validated against any known list.

Frontend (smartem-frontend)

The list is hardcoded directly on the SPA, in apps/smartem/src/data/mock-dashboard.ts:54-139 — 13 entries built for the dashboard mock-up:

Krios I-IV, Glacios I-III, Talos I-II, Titan I-III

The legacy app (apps/legacy/src/) has no equivalent — it never modelled an instruments list.

Drift between the mocked list and the real DLS fleet

The hardcoded SPA list and the list in this issue's description don't agree:

In this issue	In the SPA mock
Krios 1–5 (m02, m03, m06, m07, m08)	Krios I–IV
Talos (m04)	Talos I–II
Scios (m05)	—
Glacios 1–2 (m10, m12)	Glacios I–III
Aquilos (m11)	—
Leica cryoCLEM (m14)	—
—	Titan I–III

So we currently have an inaccurate fake list in the SPA and no real source of truth anywhere in the system.

Implication for the SPA refactor

The dashboard at / is being moved off mock data. Until a backend endpoint exists, the dashboard's "Instruments" panel has nowhere to read from. Two stopgaps available:

1. Add the issue's list as a Python constant in smartem_backend and expose it via GET /instruments — small, unblocks the SPA, matches what this issue scopes for v1.
2. Leave the SPA's instruments panel empty (or behind VITE_ENABLE_MOCKS) until UAS/ISPyB integration is scoped.

If we go with (1), this issue captures the scope — needs a Pydantic model (InstrumentResponse with at minimum id, name, model), a small router (http_api/routes/instruments.py), the seed list itself, and an OpenAPI/Orval regen on the SPA side. Happy to draft a PR against smartem-decisions on request.

[vredchenko]

We go with Option 1 but:

• in addition to a hardcoded list in the b/e (API endpoint reads from a local microscope list config - json/yaml/toml)
• we also want (behind a feature flag for smartem_decisions b/e possibly because this is experimental and brittle) an external lookup against the source of truth as per "mirrored in ISPyB (https://github.com/DiamondLightSource/ispyb-database) which is what we use as the source of truth for sessions and what instrument they’re booked on". This lookup should be implemented in a portable way so that it may be invoked from SmartEM b/e FastAPI context (either when /instruments endpoint triggers+cache OR on API init but then multiple API instances could get out of sync behind a load balancer and in long-running API instances this data could become stale... need further discussion) AS WELL AS from a CI/CD runner context if we choose to bake it in on release.. need further discussion there too.

This lookup functionality should be optional and is out of immediate scope, with a fallback to hardcoded list. Further complications: how to sync list of instruments with data in DB that might reference it? What to do about historic acquisitions performed on instruments that no longer exist? SmartEM b/e prod running on-prem may not be able to reach source of truth. How to do we detect and react to changes in external source of truth schema, location, availability? In short - this may be overengineering and introducing brittleness and complexity when the "proper" solution would be to integrate and sync SmartEM with whatever source of truth system explicitly by way of cross-system contract from both sides.