A listing is not the event
Why a date on a listing is not enough to know that an event is happening.
A venue has an address. An event has an identity. An occurrence has a date. A source has a claim. A refresh has a moment when somebody looked again.
At first, those can feel like one thing: a listing. Put an event name beside its date and location, and the page can look ready to use.
It does not.
The convenient model
The convenient model treats every page with a date as current. It puts a copied listing on a calendar. The design can make the information look more certain than it is. The page may be attractive. The underlying event may have moved, repeated, sold out, been canceled, or belonged to last year.
That model optimizes for abundance. It is also how a discovery product teaches people not to trust it.
The revision
EventDatabase now separates the things the convenient model collapses:
- The venue is the place.
- The event is the continuing idea or program.
- The occurrence is one dated instance.
- The source observation records where the claim came from.
- The refresh run records when the system looked again and what it found.
Freshness is therefore not a small timestamp beneath the real content. It is part of whether the content deserves to appear at all.
What changed
The early temptation was to make the interface feel alive by filling it quickly. The better decision was to let the trustworthy foundation exist before pretending the live inventory did. An empty discovery state can be disappointing. A populated fiction is worse.
This is a recurring Lab lesson: absence is sometimes evidence that a boundary is working. A date needs a source and a way to check it again. Having a record in the database does not make it current.
The revision did not make the product look larger. It made the promise smaller and more believable.