An observatory for computer vision, calibrated against the sky.

What this company is for

Astronomy is, at heart, a computer vision problem with the volume turned all the way down. Every pixel that lands on a CCD or CMOS focal plane has, on average, a handful of photoelectrons of signal sitting on top of dark current, read noise, cosmic rays, satellite glints, scattered moonlight and the systematic fingerprints of the optical train. The job of an instrument scientist is to subtract all of that. The job of a vision model — at least the kind we build at Solstice Pro AI — is to decide what is still worth looking at after that subtraction is done.

The company exists because that decision is becoming the bottleneck. Modern survey telescopes — the Vera C. Rubin Observatory’s LSST, the Zwicky Transient Facility, BlackGEM, GOTO — produce alert streams measured in millions of candidates per night. Solar observatories like GST, GREGOR and the recently commissioned DKIST produce data cubes at rates that exceed any human duty cycle by four orders of magnitude. Space weather services need lead time on flares, not retrospective certainty. None of these consumers have any use for a vision system that is right on average; they need one that is honest about its uncertainty on every single frame.

So that is what we build. Not generic image classifiers, not glossy demos, but the specific, narrow, instrument-aware pipelines that take raw pixels from a particular optical system and emit a calibrated decision: this is a real source, this is an artefact, this is a flare ribbon entering eruption, this transient is worth a follow-up telescope’s time tonight.

Three missions, one focal plane

Solstice Pro AI runs three engineering missions in parallel. Each was chosen because it pushes a specific corner of computer vision past where the consumer-image research community has reason to go. We do not pretend to compete with the foundation-model laboratories on captioning house cats. We do compete, on equal footing, with the instrumentation groups at major observatories on detecting a 19th-magnitude transient before it fades below the noise floor.

Method, in the observatory sense

A century ago, an observatory was a place where the same instrument was pointed at the same patch of sky on enough successive nights that systematics could be characterised by comparison rather than by simulation. We retain that discipline. Every model we ship is benchmarked against a held-out instrument night — a complete observing session, weather and all, that the model has never seen during training. Performance reported against synthetic data is performance not yet earned.

We work with three classes of training data. The first is calibration data taken on the instrument itself: bias frames, flats, darks, twilight skies, standard-star sequences. The second is archival science data — nights of observation already reduced and accompanied by human judgement on what was real. The third, used sparingly, is synthetic data generated by injecting known sources into real backgrounds; this is essential for rare-class augmentation (kilonovae, fast radio burst counterparts) but never sufficient on its own.

Inference, in turn, has to live within the timing budget of the instrument. A 30-second exposure followed by a 5-second readout means that any decision the pipeline makes about that frame has to be made before the next exposure has fully clocked off the sensor — or the alert is no longer actionable. We treat latency the way an aircraft avionics team treats latency: as a hard real-time constraint that bounds model complexity, not as an optimisation target to be approached asymptotically.

Selected deployments and benchmarks

These are not blue-sky research numbers; each is a specific, reproducible benchmark on an instrument we (or our collaborators) operate. The full evaluation protocol is published with each release on the Dispatches page.

Who reads our outputs

Solstice Pro AI’s downstream users sit in three rooms. The first is the space-weather operations room, where forecasters need a flare probability that they can act on — schedule a satellite into safe mode, warn a polar airline route, recompute an ionospheric correction. The second is the survey alert broker, where a real-bogus classifier sits between the telescope and the community and decides which alerts justify a follow-up trigger. The third is the instrument scientist’s laptop, where a denoiser or cosmic-ray segmenter sits inside the nightly reduction pipeline and saves the team a half-day of by-hand cleanup.

We are deliberately not selling a platform. We are selling specific models, packaged as Docker containers with deterministic CUDA builds, accompanied by the validation notebook used to generate the headline number. Where a client prefers to host on their own cluster — which most observatories do, for archival and provenance reasons — we ship the artefact and walk through the integration.