The Observatory at 37 Crescent Rise.

How the company began

Solstice Pro AI was incorporated in late June 2025 with the explicit narrow brief of computer vision for solar and astronomical data intelligence. The founding decision — the one we have not regretted — was to stay narrow. There is no shortage of consultancies offering vision models as a horizontal service; there is a real shortage of teams who can be handed an instrument-specific dataset and produce a model that survives the first night of real sky.

The choice of registered office in N22 was practical rather than symbolic. North London sits inside the academic gravity well of UCL, Imperial, Royal Holloway and the Mullard Space Science Laboratory; it is a 90-minute train ride to Cambridge and a 4-hour flight to almost every European partner facility. The 37 Crescent Rise address is our company-of-record correspondence; engineering work is done remotely against client telescopes and observatory data centres.

From the first month we ran on a simple operating principle: write less code, validate it harder. A model that solves 80% of an observatory’s problem and is honest about the remaining 20% is more useful than a model that claims 99% on a benchmark that does not match the instrument. Our first three months were spent not training, but building the validation harness — the reproducible night-replay test fixtures that we still use today.

What "computer vision for astronomical data" means here

The phrase has been worn smooth by use, so we will define it ourselves. Astronomical computer vision, as we practise it, has four distinguishing properties.

• Photon statistics dominate. Read noise is sub-electron on modern sensors; signal can be a single photoelectron per pixel per exposure. Gaussian-likelihood losses are wrong; Poisson, Skellam or anscombe-transformed L2 are right.
• Backgrounds are structured. Cosmic rays, satellite trails, moonlight gradients, scattered city light and atmospheric airglow all leave characteristic signatures. A model that has only seen ImageNet has no priors for any of these.
• Class imbalance is extreme. A real supernova candidate appears once per 10⁴ to 10⁵ pixel-level detections. False positives are not a nuisance — they are the entire engineering problem.
• Time is part of the signal. A single image rarely decides anything; the change between two images often decides everything. Difference imaging and light-curve analysis are not optional add-ons.

Each Solstice mission is, in effect, a different decomposition of these four properties. Helios leans hardest on the time dimension; Photon on the photon-statistics dimension; Sky on the class-imbalance dimension. There is overlap, and the code base is shared, but the architectures and the loss functions differ.

How we run an engagement

Phase A — instrument intake

We start every engagement by ingesting a week of typical instrument data — not the cherry-picked nights, but a representative week. We characterise the dark current, the read noise distribution, the PSF stability, the cosmic-ray rate, the flat-field uniformity. We write a one-page instrument summary that we share back with the client; in nine cases out of ten this exposes at least one calibration assumption the team was not aware they were making.

Phase B — baseline replay

Before we train anything, we replay the existing pipeline against the same week of data and record its outputs. This is our floor. Any model we ship has to clear that floor on the same data, by the same metric, before we even discuss deployment.

Phase C — model construction

Architecture choice is governed by inference latency, not by what is fashionable. For Helios we use a temporal U-Net over magnetogram patches; for Photon a self-supervised noise-to-noise plus blind-spot variant; for Sky a real-bogus convolutional classifier with a calibration head. None of these are novel in the abstract sense; the novelty lives in the data conditioning and the loss design.

Phase D — replay validation

The held-out night replays back through the new pipeline. If the model improves the headline metric without inflating the failure modes the client cares about most, it proceeds to integration. If not, we publish the negative result internally and revise.

Phase E — deployment and watch

We hand over a containerised model with a deterministic build manifest, a calibration script, and a monitoring dashboard. We watch the first two weeks of live performance with the client and tune the operating point against their false-alarm budget.

Operating values

"The first night that a model meets real sky is the only benchmark that matters. Everything before that is rehearsal." — Internal note, Helios replay log, October 2025

That sentence is on the wall of our reduction room, such as it is, and it is the closest we have to a corporate slogan. Below it is a more practical companion principle: we report every metric with its 95% confidence interval, and we never report a single number for a single seed. Where a result depends on the choice of train/test split, we report all reasonable splits and the variance across them. Where a result depends on the instrument’s calibration state, we say so.

We also keep a written register of failed approaches. As of this writing it contains 41 entries — architectures we tried, losses that looked promising on simulation and collapsed on real data, augmentation schemes that introduced their own biases. The register is shared with clients on request; we would rather they know what we already ruled out than relearn it themselves.

Where we sit in the wider community

Solstice Pro AI is too small to be a survey project and too narrow to be a general-purpose laboratory. We sit deliberately in the gap between the two. We are not bidding for headline survey contracts, and we are not chasing the latest foundation-model headline. We provide instrument-specific vision components — a denoiser, a real-bogus model, a flare-onset classifier — that integrate into pipelines run by larger teams.

That position has consequences. It means we are a poor fit for clients who want a single vendor for an entire data system; we have no ambition to be that vendor. It is an excellent fit for observatory groups, space-weather centres and survey brokers who have a competent internal team and a specific vision-shaped hole in their pipeline. If that describes your situation, the rest of this site is for you.