We need to tie down the requirements for managing the state and history of alarms, for example providing:
* an API to allow users define and modify alarm rules
* an API to query current alarm state and modify this state for testing purposes
* a period for which alarm history is retained and is accessible to the alarm owner (likely to have less stringent data retention requirements than regular metering data)
* an administrative API to support across-the-board querying of state transitions for a particular period (useful when assessing the impact of operational issues in the metric pipeline)