Manual merge/split of derived weather events (deferred from #136) #167

New issue

Open

opened 2026-08-01 03:15:04 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-01 03:15:04 +00:00

Contributor

Why deferred

A user-override layer that survives rebuilds contradicts the "derived and rebuildable, never source of truth" constraint (#22, #135) and roughly doubles the correlation design: override storage keyed to something stable across re-derivation, conflict semantics when a rebuild produces groupings that no longer match an override, and merge/split UI.

What it would take (sketch, for when this is picked up)

An override table keyed by stable member identity (lifecycle ids), not by derived event ids — e.g. "these lifecycle ids are one event" / "split lifecycle X from Y" — applied as a post-pass after each derivation, so rebuilds re-apply overrides instead of losing them.
Conflict rule for when the underlying members age out of retention or a derivation_version bump changes the base grouping.
UI on the event detail view (#139) for merge/split, admin- or owner-gated.

Prerequisite evidence

The event view already shows why members grouped (gap distances, upgrade edges — per #136). Collect actual misgrouping examples through a convective season before designing this; the gap constant (EVENT_GAP_MINUTES=90) can also simply be retuned via rebuild, which may make many desired overrides unnecessary.

Deferred from #136 (decision recorded there, 2026-08-01): v2.0.0 ships the automatic correlation rules only; user-driven merge/split of derived events is explicitly out of scope until real usage shows where the automatic grouping misfires. ## Why deferred A user-override layer that survives rebuilds contradicts the "derived and rebuildable, never source of truth" constraint (#22, #135) and roughly doubles the correlation design: override storage keyed to something stable across re-derivation, conflict semantics when a rebuild produces groupings that no longer match an override, and merge/split UI. ## What it would take (sketch, for when this is picked up) - An override table keyed by stable member identity (lifecycle ids), not by derived event ids — e.g. "these lifecycle ids are one event" / "split lifecycle X from Y" — applied as a post-pass after each derivation, so rebuilds re-apply overrides instead of losing them. - Conflict rule for when the underlying members age out of retention or a `derivation_version` bump changes the base grouping. - UI on the event detail view (#139) for merge/split, admin- or owner-gated. ## Prerequisite evidence The event view already shows *why* members grouped (gap distances, upgrade edges — per #136). Collect actual misgrouping examples through a convective season before designing this; the gap constant (`EVENT_GAP_MINUTES=90`) can also simply be retuned via rebuild, which may make many desired overrides unnecessary.

claude-bot referenced this issue

2026-08-01 03:15:16 +00:00

Decide correlation rules for ambiguous product groupings #136

claude-bot added the

backlog

type:feature

labels

2026-08-01 03:15:22 +00:00

claude-bot referenced this issue

2026-08-01 03:16:05 +00:00

Event correlation layer (derived, rebuildable weather_events) #135

claude-bot referenced this issue