# Expected Lasair ssObjectId behaviour

**URL:** <https://www.rubin.community/t/expected-lasair-ssobjectid-behaviour/11534>\
**Category:** Lasair\
**Created:** [February 4, 2026, 3:14pm UTC](https://www.rubin.community/t/expected-lasair-ssobjectid-behaviour/11534 "2026-02-04T15:14:55Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jrob93](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jrob93/32/4102_2.png) [@jrob93](https://www.rubin.community/u/jrob93)\
**Post date:** [February 4, 2026, 3:14pm UTC](https://www.rubin.community/t/expected-lasair-ssobjectid-behaviour/11534/1 "2026-02-04T15:14:55Z")

</div>

Hi all, I have a couple questions related to how we can expect Lasair to handle moving solar system objects (SSOs), i.e. alerts with an `ssObjectId`:

- Is the Lasair-LSST alert schema available? Or is it just the [official LSST schema](https://sdm-schemas.lsst.io/apdb.html)? I’m interested to see what fields are possible to write queries for, e.g. `ssObjectId`.
- Currently with Lasair-ZTF queries can be written on `objects.ssnamenr` (i.e. moving object identifier), however the ZTF alerts available from Lasair all have `objects.ssnamenr=NULL`. Will this behaviour be the same for LSST alerts, i.e. filtering out NOT NULL `ssObjectId` alerts before queries?
- There has been talk that alerts will move to a nearest SSO system, i.e. alerts not explicitly matched to an SSO. Quoting a recent update from Mario Juric “New scheme: we will add SSSource/SSObject records to all alerts that have an SSO nearby”. This implies to me that Lasair will have to keep ALL alerts, as having a nearby SSO does not preclude the source being a static transient? Therefore it might be possible to write a query on `ssObjectId`?

---

<div class="post-metadata">

**Author:** ![roy](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/roy/32/1254_2.png) [@roy](https://www.rubin.community/u/roy)\
**Post date:** [February 5, 2026, 11:20am UTC](https://www.rubin.community/t/expected-lasair-ssobjectid-behaviour/11534/2 "2026-02-05T11:20:18Z")

</div>

- So far, Lasair has not built any sort of infrastructure concerning Solar System data except for ingesting it and storing it in the database.
- We have not seen any ssObject records at all in the last few months of commissioning
- Lasair tries to capture the SS data as it comes. The Cassandra table schema is an automated copy of the Rubin schema: [mpc\_orbits](https://github.com/lsst-uk/lasair-lsst/blob/main/common/schema/10_0/mpc_orbits.py), [ssSources](https://github.com/lsst-uk/lasair-lsst/blob/main/common/schema/10_0/ssSources.py), and [ssObjects](https://github.com/lsst-uk/lasair-lsst/blob/main/common/schema/10_0/ssObjects.py).
- The Lasair-ZTF system does not handle SS objects
- Lasair-LSST is keeping all the SSSource/SSObject/mpc\_orbit records that arrive