Summary of the Issue

DMTN-102 (Alerts Key Numbers), Section 4, makes the following statement:
"It is a requirement that all alerts be stored in an archival database and be available for retrieval".

That statement cites OSS-REQ-0185, the wording of which is very ambiguous and out-of-date:
"OSS-REQ-0185 Specification: All published transient alerts, as well as all reprocessed historical alerts generated as part of a Data Release, shall be available for query."

OSS-REQ-0185 could be interpreted as one or both of the following:
(A) "All distributed alerts shall be available for query."
(B) "All DIASources, whether from Prompt or Data Release processing, shall be available for query."

DMTN-102 interpreted OSS-REQ-0185 as A, but there are two pieces of evidence for B:
(I) The discussion of OSS-REQ-0185 states that its purpose is to "allow users to perform statistical analyses on alerts", which is functionality of the PPDB and DR catalogs, not an alerts archive.
(II) OSS-REQ-0185 flows down to DMS-REQ-0312 which is also clearly a requirement for the PPDB, albeit with similarly out-of-date language: "DMS-REQ-0312 Specification: The DMS shall maintain a ”live” Level 1 Database for query by science users, updated as a result of Alert Production processing."

Additionally, there don't appear to be any requirements related to (or even mentions of) an alerts archive in the DPDD or the LSR.

All of the above leads to two conclusions:
(1) There is no requirement that alerts be stored in a queryable archive.
(2) OSS-REQ-0185 and DMS-REQ-0312 need their language updated.

Since change requests for the OSS and DMSR are discouraged, instead we can ensure accurate interpretation of the requirements by updating the discussions of the related LVVs.

Proposed Updates to the Relevant LVV

LVV-1456 for OSS-REQ-0185 (assignee Chuck Claver), in the Description, replace
"demonstrate this capability during commissioning"
with
"This specification has out-of-date wording and should be interpreted as 'The results of Difference Image Analysis (DIA) run during Prompt processing as a part of Alert Production (i.e., the Prompt Processing Database, PPDB), and the results of DIA run during Data Release processing, shall be available for query'. This capability can be demonstrated during commissioning with queryable catalogs."

LVV-143 for DMS-REQ-0312 (assignee Eric Bellm), in the Description, add
"The term ”live” Level 1 Database refers to the Prompt Products Database, and while it is updated as a result of Alert Production it does not contain copies of the alert packets."

Requested Feedback

Is there really no requirement that alert packets be stored in a queryable database or am I just missing it?

Do the proposed updates to the relevant LVV seem useful and appropriate?

My reading is that the key DM-level requirement is DMS-REQ-0094:

The DMS shall preserve and keep in an accessible state an alert archive with all issued alerts for a historical record and for false alert analysis.

My understanding of OSS-REQ-0185 was that it was intending to require an actual copy of issued alerts for reference and archival purposes, as well as for statistical analysis, which might be around alert generation/issuance/selection/timing and related systematics rather than directly astrophysical.  If we can reliably reproduce the content of the alerts, including timings, without storing the actual bits, that is likely sufficient.

Ah HA! Somehow my search of DMSR missed 0094    But I'm glad there's an easy solution here. I will update DMTN-102 to cite DMS-REQ-0094 for the alerts archive (requested Leanne Guy review PR), thank you John Swinbank! 

In light of this, remaining open question: should the LVV descriptions still be updated? 

Re LVV-1456 — I tend to believe that OSS-REQ-0185 really is expecting to query alert packets, not simply the PPDB. I think this re-wording of LVV-1456 moves away from that interpretation, and I don't think that's justified without going through a change control process.

Re LVV-143 — I think it is useful to clarify that the “L1 database” referred to is, indeed, the PPDB. The extra text about it not containing copies of alert packets is not necessary, but does no harm. (Tangentially, I find the use of the term “live” here quite confusing. I would interpret “Demonstrate that an end-user can see the L1 database being updated live” as meaning that the user can see the database being updated in real-time, but that would be in conflict with L1PublicTMin.)

I agree with Kian-Tat Lim and John Swinbank above, and I have high confidence that the intent of "All published transient alerts ... shall be available for query." was as stated by them, i.e., option A above.  We have always maintained a distinction between "as-published" alerts and the PPDB.  

(Note also that the combined effect of OSS-REQ-0128 and OSS-REQ-0130 makes clear that "alerts" and the "catalogs" of "Difference Sources" and "Difference Objects" are distinct Level 1 Data Products.

It's been stated in a variety of ways that the database of alerts that this implies may not be - in fact is likely not to be - a conventional "catalog" relational database.  I'd like to defer to Kian-Tat Lim for an authoritative reference on this.

I think the phrase "all reprocessed historical alerts generated as part of a Data Release" is regrettable, as we don't actually distribute "alerts" as part of the reprocessing of image difference analysis in a DR.  I am not quite sure how to deal with this in test-writing.  In hindsight I would prefer to have written the requirements to more carefully distinguish the two cases and make clear that the "reprocessed historical 'alerts'" are in fact the Data Release versions of the DIAObject and DIASource tables.  

A long-standing grey area (to me) has been the exact conditional logic that leads from a new DIASource to the issuance of an alert.  For instance, if (as DMS-REQ-0270 suggests) some prescaled fraction of transients below the normal transSNR significance threshold is preserved in the DIASource catalog, but not publicly issued as alerts, and if no physical archive of actual "alerts" is maintained, the exact conditional will need to be available to be "replayed" in queries against the DIASource catalog (live or DR-reprocessed) that have the intent of precisely reproducing the alert stream content.  I wonder if a Boolean "publishable_as_alert" flag should be preserved in the DIASource database?

OK, sounds like Kian-Tat Lim, John Swinbank, and Gregory Dubois-Felsmann all agree that the intent of OSS-REQ-0185 is that (A) "All distributed alerts shall be available for query". Moving forward with this, do we think the following clarifications to the associated LVV are accurate and necessary?

LVV-1456 for OSS-REQ-0185 (assignee Chuck Claver), in the Description, replace
"demonstrate this capability during commissioning"
with
"This specification has out-of-date wording and should be interpreted as 'All distributed alerts shall be available for query'. This capability can be demonstrated during commissioning with queryable alerts archive."

LVV-143 for DMS-REQ-0312 (assignee Eric Bellm), in the Description, add
"The term ”live” Level 1 Database refers to the Prompt Products Database being updated within L1PublicT, and while it is updated as a result of Alert Production it does not contain copies of the alert packets, which are stored elsewhere (LVV-1456)."

Gregory Dubois-Felsmann, your question about a DIASource flag for "published as an alert", or perhaps a DIASource element that is the published alert ID if and when it exists (not currently in Table 1 of the DPDD) – maybe a new ticket?

I'm fine with these suggested updates to the LVVs.

I'm fine with these suggested updates to the LVVs.

+1.

LVVs are updated. I'll close this ticket once the PR on DMTN-102 is merged. Thanks all.