J. Kissel, for Lots of People

I heard mention of a big corner station seismic platform trip this morning, so I wanted to follow up and make sure it (a) got in the aLOG, and (b) we had a rough understanding of what happened.
Our conclusion (though it is still a "yeah, that's probably what happened") is that while the EE team was yanking around cables in the beer garden (removing old obsolete iLIGO cabling; aLOG pending), they jostled the STS2 on the ground. 
Now that we're feeding one STS to all platforms in the corner station via the common mode sensor correction, and "hit" to that one seismometer means that it's gunna make all the platforms angry. This appears to have been a kick primarily in the Y direction, and thus -- because we feed X Y from this STS to ALL ISI platforms, with Z going directly to the HAM ISIs but fed to HEPI for the BSCs -- only the ISIs tripped.

I attach corroborating evidence:
(1) Time series trend of ground STS signals in X, Y, and Z. The timeseries should be in units of [nm/s]. One can see Y DOF goes bonkers at 2019-10-18_1612 UTC.
(2) Time series detail of when each ISI platform tripped. 0 is good, 1 is tripped.
(3) Time series detail of all HPI watchdogs. 0 is good, 1 is tripped, and this is just to confirm that no HEPIs tripped.
(4-6) Time series trend of the input to the MATCH filter bank for X Y and Z for all chambers (to the appropriate stage, be it HEPI or ISI). This is the last filter bank (which is just a "passthrough," empty filter bank with a gain of 1.0) before the sensor correction signal is added to each platform's displacement sensors (aka the CPS). Clearly, the Y direction gets it the worst (where the calibration should now be in [nm], since it's about to get subtracted from the CPS), and this is what sends the then sensor "corrected" CPS signal in the blend with feedback inertial sensors, and drives the feedback loop error signal in to the weeds, and thus a trip.

Lesson learned:
As we're now in that stage of every commissioning period where we're both trying to use the interferometer "at night" (or during various parts of the day, for activity like e.g. LHO aLOG 52528) -- or running tests of new sensor correction techniques, e.g. LHO aLOG 52560 -- AND we're also still trying to do heavy lifting / craning / electrical work in-and-around the beer garden (e.g. today's work that we believe caused the event), we need to be extra conscious of turning ON and OFF sensor correction, and whom needs the sensor correction in what state. 
Typically, the commissioning team wants sensor correction ON (and currently, due to state of construction, that's in a convoluted custom state created by the seismic team), and typically, when there is heavy activity in the LVEA, it's good practice to turn the sensor correction OFF.

As far as I can tell, today, the state we want the site wide sensor correction in 
 - when we need to use the IFO: TEST_SWARM.
 - when there will be heavy activity near the beer garden STS: SC_OFF_NOBRSXY