[Pattern proposal] Notification roll-up for pages with multiple concurrent callouts

### Problem

EUI has no pattern for a page that needs to surface **multiple concurrent page-level notifications.** Each callout is well-designed in isolation, but there's no guidance for what happens when several are present at once — so teams stack them.

Real example: the Detection rules (SIEM) page in Elastic Security currently renders 5 stacked callouts/banners above the page content:

This results in:

- **No ordering logic —** severity doesn't determine position
- **Inconsistent CTAs —** each callout invents its own action anatomy
- **No placement logic —** notifications, announcements, and upgrade prompts all compete for the same space
- **Content pushed below the fold —** the page's actual purpose loses primacy

### On "cutting callouts"

The obvious fix — cut some callouts — doesn't always work. We reviewed each notification on this page with the owning team, and they're individually legitimate: things users genuinely need to know about, act on once, and then never see again. The problem isn't that any single team made a bad call; it's that each notification is added independently, and no one owns the aggregate experience. Every individual decision is reasonable; the sum is not.

That's exactly the kind of problem a design system should solve, because:

**1. The condition is inevitable.** Any long-lived page accrues feature announcements, deprecation warnings, migration prompts, and error states. Security hit 5 first; other solutions will follow.
**2. Without a shared pattern, we fragment.** If EUI stays silent, each team will invent its own mitigation, and we end up with N inconsistent roll-up behaviors instead of N stacked callouts — arguably worse.
**3. Adjacent efforts don't cover it.** The platform "future notifications" work was initially scoped to Elasticsearch and doesn't address solution pages.

### Proposal: notification roll-up

Collapse all page-level notifications into a single collapsible container that sits where the stack sits today. The reasoning behind the key behaviors:

- **One container, individually actionable items.** Users get back their page real estate without losing any notification. Each item keeps its own actions and its own dismiss, so "roll up" never means "hide away."
- **The contents signal severity.** When the roll-up holds multiple types of callouts, it uses a neutral gray background with per-type pills showing what's inside (e.g. 2 errors, 1 warning, 3 info) — a collapsed roll-up can still answer "is anything in here urgent?" at a glance without the container itself shouting. Only when a single type remains does the container adopt that type's styling.
- **It degrades gracefully into what already exists.** Dismiss down to a single notification and it renders as a standard EUI dismissible callout; dismiss the last one and it disappears. The pattern composes with the existing callout component rather than replacing it — no migration cliff for consumers.

Examples:

### Announcements are a different thing — shown with and without

Some pages also carry a product announcement (a tour, a new-feature promo). These are promotional rather than severity-based, and mixing them into the roll-up muddies its "worst remaining severity" logic — we prototyped that and rejected it. The proposal keeps announcements as a separate, independently dismissible banner above the page header. Screenshots show the pattern both with and without one; **the roll-up is the core of this proposal and works identically either way.**

### Alternatives explored

- One roll-up per severity type — viable, but on mixed pages it multiplies containers and partially recreates the stacking problem
- Paged single banner and summary strip + flyout — prototyped and set aside

I have prototyped these interactions in Claude design. Happy to share and walk through them. Vid here:

https://github.com/user-attachments/assets/a5b5a703-2633-4fc5-96a4-3243c6ab038b

### Open questions for the EUI/design discussion

- Component vs. documented pattern? (Consumers need a way to register/dismiss notifications)
- Dismissal persistence — per user, per space, per deployment?
- A11y: focus management on collapse/expand, announcing newly added notifications
- Ordering within the roll-up (severity, then recency?)
- Does the announcement banner also become a shared pattern, or stay app-owned?

___

**Context:** raised in #all-product-design ([thread](https://elastic.slack.com/archives/C096R3YKG0K/p1784576705291219)); the Security team has confirmed these notifications are individually necessary and is aligned on the roll-up direction, with the explicit ask that the pattern be validated by EUI + design so it scales to all consumers.