Three versions of Thursday
In this invented example, Cedar Studio schedules a workshop for Thursday at ten. The organizer moves it to Friday. A calendar export creates a second row, an integration retries the notification, and a dashboard announces that Cedar has run three workshops.
On Friday morning, the workshop is cancelled. The dashboard still looks productive. Its count is accurate only if the business sells database rows rather than workshops.
What is the event supposed to identify?
The first question is whether a record describes a planned occasion, an actual occurrence, or a message reporting a change. Each can legitimately have an identifier and a timestamp, but they are different things.
In an illustrative workshop model, a stable event identifier could survive rescheduling. A schedule revision describes the changed plan. A notification records that a message was sent. Cancellation describes the planned occasion's status; it need not erase the fact that the occasion was once scheduled.
Those distinctions let a question such as “How many workshops happened?” exclude plans that never became occurrences. “How many were scheduled?” can still include them.
A date cannot carry every clock
Date means a calendar day without a time of day. It is suitable for a day-level fact, not a complete description of a workshop beginning at ten. A planned instant needs enough context to interpret the clock, and an actual start may differ from the plan.
The due today story explores why local dates and instants answer different questions. A country is not a single time zone. An online workshop may have one start instant and several local calendar dates for its participants.
An all-day occasion raises a different issue: converting a date through a midnight timestamp can shift the displayed day. Precision should come from meaning, not from whichever storage type happens to be available.
The organizer is not the attendee
Cedar organizes the workshop, Leah hosts it, a customer purchases places, and several people attend. These relationships should not collapse into one generic contactId merely because somebody must receive a confirmation email.
Organization provides a meaning for the organizing group. The person story separates each individual from their role, while the contact story separates identity from the route used to reach them.
A booking may also connect to an order. From order to invoice explains why a commitment to supply and a payment request remain different records even when both mention the same workshop.
A retry is not another occurrence
The repeated notification in our example describes the same schedule change. Counting it as a second change, let alone a second workshop, confuses communication with the thing communicated.
An illustrative integration can preserve an event identity and a change identity across retries. It can also record separately when something happened and when the system learned about it. A late report then belongs to the original occurrence instead of quietly moving that occurrence into today's totals.
Once these meanings are explicit, the dashboard becomes less spectacular and more useful: one workshop planned, rescheduled, then cancelled; two notification attempts; no workshop delivered. Thursday has not duplicated itself. The model has simply stopped asking a timestamp to tell the entire story.
