During the LSST Community Brokers Workshop in Seattle in June 2019, several discussions emerged about the contents of the alert packet and whether they were optimal for enabling follow-up of transient events, along with the possibility of pre-filtered streams (DM-20296).

The full broker proposals will further illuminate what is needed/wanted in terms of alerts contents, and whether reducing the size of an alert packet to reduce the bandwidth of the alert stream is an idea to be pursued.

Open questions regarding alert packet contents:

• Postage Stamps: should they be included in all alert packets, or would a public cutout service be sufficient and how might that be implemented; how does stamp size affect classification, and what is the tradeoff in terms of cost/benefit
• Histories: are they necessary for all alerts? is a full history necessary, or could it be partial (either <1 year, or limited in columns) with the same scientific utility?
• Columns: are all elements of the DIASource and DIAObject record necessary to include in the alert or could a subset suffice?
• Pre-Filters: could different brokers receive streams that have been pre-filtered to remove packets that they are not interested in? (Initial investigations in DM-20296, now a part of this ticket).

• Variability Characterization Parameters: which are most important to compute immediately and include in alerts? (This is being done with DM-19593)
• Photometric Redshifts: do classifiers have any special needs for the types of photo-z for the DR objects associated to alerts? (Science use cases for photo-z are handled by DM-6367)
• Static-Sky Source Association: is 3 nearest stars and 3 nearest extended objects sufficient for alert brokers’ classification algorithms? (This is being done with DM-23683).