Page Comparison

...

All of these views operate on the most recent timestamps for all events. Building schedules that rely on a mutable event changing, and triggering a new timeline of sessions to perform, will not work with these adherence APIs. That would be events like “session type X has been completed.” OTOH, it will show compliance with the most recent time stream, and that might be all that matters. Past time streams are no longer actionable.

...

SessionOnDate Report

This is a date-range list API that returns a set of SessionsOnDate objects.

...

This is a flat report that lists all sessions that have a startDate/endDate that overlaps with the date of the record (remember that a session really exists for each window in each session in a schedule). In the database, this is a set of records that will be grouped. For this reason, the date range is low: 1-7 days only. The database SessionOnDate table would look something like this:

CREATE TABLE `SessionOnDate` (
  `appId`,
  `studyId`,
  `userId`,
  `sessionInstanceGuid`,
  `timeWindowGuid`,
  `startDate`,
  `endDate`,
  `state`,
  `label`,
  `symbol`,
  PRIMARY KEY (`studyId`, `userId`, `sessionInstanceGuid`, `date`),
  CONSTRAINT `SessionsOnDate-Study-Constraint` FOREIGN KEY (`appId`, `studyId`) REFERENCES `Substudies` (`id`, `studyId`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Here is a visual design for this feature…this is all I got on requirements at this point:

...