An incident's severity is written when the incident is created and never updated as later calls arrive.
That makes it wrong for exactly the incidents that matter most: anything that escalates. A call that opens as routine and becomes a structure fire keeps the severity it was born with, so every severity-driven sort, filter and colour in the UI misrepresents it. The "Major only" filter on /incidents will omit a major incident that did not start that way.
Found during the UI design pass (UI_REDESIGN.md). It matters more under the redesign, where severity drives the worst-first ordering of the incident rail on the home screen — a stale severity would silently bury a live emergency below routine traffic.
Fix direction: re-evaluate severity on each linked call and keep the maximum, or recompute from the incident's calls when the summary is regenerated. Decide explicitly whether severity can ever go down (an incident downgraded after more information) or is monotonic — the answer changes the implementation and should be written down.
An incident's `severity` is written when the incident is created and never updated as later calls arrive.
That makes it wrong for exactly the incidents that matter most: anything that escalates. A call that opens as `routine` and becomes a structure fire keeps the severity it was born with, so every severity-driven sort, filter and colour in the UI misrepresents it. The "Major only" filter on `/incidents` will omit a major incident that did not start that way.
Found during the UI design pass (`UI_REDESIGN.md`). It matters more under the redesign, where severity drives the worst-first ordering of the incident rail on the home screen — a stale severity would silently bury a live emergency below routine traffic.
Fix direction: re-evaluate severity on each linked call and keep the maximum, or recompute from the incident's calls when the summary is regenerated. Decide explicitly whether severity can ever go *down* (an incident downgraded after more information) or is monotonic — the answer changes the implementation and should be written down.
Fixed in commit 70d63abeaa on Server main. Severity is re-evaluated in _update_incident on every call link via a new _max_severity() helper, merged as max(current, new) on the four-level ladder. Decision: monotonic — severity only ever rises, never falls, as calls attach. An incident briefly assessed major genuinely was major at that moment; status/resolved_at (see #18) are what retire it, not a later calmer-sounding call. Full rationale is in the _max_severity docstring in incident_correlator.py. New tests in tests/test_correlator_gate.py cover the escalation case (routine -> major) and confirm a later routine call does not downgrade a major incident.
Fixed in commit 70d63abeaaa24a56aa6fd3cbc6320e50e9f77b98 on Server main. Severity is re-evaluated in _update_incident on every call link via a new _max_severity() helper, merged as max(current, new) on the four-level ladder. Decision: monotonic — severity only ever rises, never falls, as calls attach. An incident briefly assessed major genuinely was major at that moment; status/resolved_at (see #18) are what retire it, not a later calmer-sounding call. Full rationale is in the _max_severity docstring in incident_correlator.py. New tests in tests/test_correlator_gate.py cover the escalation case (routine -> major) and confirm a later routine call does not downgrade a major incident.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
An incident's
severityis written when the incident is created and never updated as later calls arrive.That makes it wrong for exactly the incidents that matter most: anything that escalates. A call that opens as
routineand becomes a structure fire keeps the severity it was born with, so every severity-driven sort, filter and colour in the UI misrepresents it. The "Major only" filter on/incidentswill omit a major incident that did not start that way.Found during the UI design pass (
UI_REDESIGN.md). It matters more under the redesign, where severity drives the worst-first ordering of the incident rail on the home screen — a stale severity would silently bury a live emergency below routine traffic.Fix direction: re-evaluate severity on each linked call and keep the maximum, or recompute from the incident's calls when the summary is regenerated. Decide explicitly whether severity can ever go down (an incident downgraded after more information) or is monotonic — the answer changes the implementation and should be written down.
Fixed in commit
70d63abeaaon Server main. Severity is re-evaluated in _update_incident on every call link via a new _max_severity() helper, merged as max(current, new) on the four-level ladder. Decision: monotonic — severity only ever rises, never falls, as calls attach. An incident briefly assessed major genuinely was major at that moment; status/resolved_at (see #18) are what retire it, not a later calmer-sounding call. Full rationale is in the _max_severity docstring in incident_correlator.py. New tests in tests/test_correlator_gate.py cover the escalation case (routine -> major) and confirm a later routine call does not downgrade a major incident.