diff --git a/dev-docs/BACKLOG.md b/dev-docs/BACKLOG.md
index 786f4c06..e2b0b8c4 100644
--- a/dev-docs/BACKLOG.md
+++ b/dev-docs/BACKLOG.md
@@ -736,6 +736,43 @@ de divergentie totdat een legitieme amendement langskomt.
 
 ---
 
+### EVENT-START-END-TIME
+
+`events` table currently has `start_date`/`end_date` (date type), which
+forces day-boundary semantics in `WithinEventBounds` and similar checks.
+For festivals running past midnight or with intentionally non-24h
+operating windows, a `start_time`/`end_time` pair (or a unified
+`start_at`/`end_at` datetime) on the `events` table would let:
+
+- the timetable viewport (Session 4 frontend) honour real event hours
+  instead of always showing 00:00 → 23:59
+- boundary checks like `WithinEventBounds` reject performances that
+  run past the event's actual close time, even within the same date
+
+**Why not now:**
+- Cross-cutting schema change touching the `events` table — used by
+  30+ modules across the codebase
+- Out of scope for the Artist Timetable sprint per Charter §2 (no
+  opportunistic feature-creep)
+- Sub-events absorb the granularity in 90% of cases via Performance
+  datetimes
+
+**When:**
+- Session 4 frontend timetable viewport reveals concrete UX gaps from
+  date-only event bounds
+- OR a customer onboards with a non-day-aligned schedule (e.g. a club
+  with a 22:00 → 06:00 nightly window)
+
+**Surfaced during:** Session 2 review of
+`app/Rules/Artist/WithinEventBounds.php`, which uses
+`startOfDay()`/`endOfDay()` to bridge the date-vs-datetime gap. That
+bridge is correct given current schema; this ticket is about the
+schema, not the rule.
+
+**Prioriteit:** Middel — works today; upgrade is feature-not-bug.
+
+---
+
 ### AUTH-PERMISSIONS-MIGRATION — Migrate alle policies van hasRole() naar hasPermissionTo()
 
 **Aanleiding:** Crewli gebruikt vandaag uitsluitend Spatie *roles*; geen