We must have a TTL on start events, otherwise we do not know when to stop believe that the event is active in the event of never receiving a stop (device is destroyed, etc.).

When a stop event comes in that shorts out the start event, we could just store the stop separately from the start, but then every read access of the data requires recombining these datums that will never change again.  So, it is more efficient to update the initial start to be "correct" and never have to futz with it again.  Also, having separate events can lead to races where overlaps and gaps can inadvertently occur.

Fwiw, you can logically think of the above model as an "atomic" start and stop event.  I.e. we are bundling the "stop" event into the "previous" field and having the rest of the fields define the "start" event.

And actually, I just realized that we are talking about bolus events, not basals.  So, tuck what I said above away as the argument for the model that basals follow, and read the following for boluses:

This is exactly a start/stop model.  It's possible that a bolus gets cut short, resulting in not all of the bolus being actually delivered (this is the difference between programmed and delivered from carelink, for example).  We need the initial bolus event event so that we can properly correlate the events.  The choices are

1. We auto-generate meaningful ids for events and require the previous event from a device in order to correlate the stop action with the start
2. We require the device to generate a meaningful id for an event and provide that same id as a join key when they send the stop action.

I decided that it was easier and safer for us to auto-generate ids, than to require all devices to come up with a meaningful id generation scheme.