Facet Search improvements

[ARWNightingale]

Problem Statement

Our current Facet Search is a molecule (simple filter groups + counts). It’s great for light filtering but doesn’t scale for complex, multi-entity discovery (e.g., rules library, exceptions, assets, findings). We lack: multi-select logic (AND/OR/NOT), saved filter sets, pinned/global filters, range/date facets, dynamic facet suggestions, responsive/mobile behaviour, and a consistent API that syncs with KQL / query bar. Teams are re-implementing variations, causing inconsistency and duplicated effort.

Proposed Solution

Promote the Facet Search to an organism with a standardized API and UI, built from EUI primitives, that includes:
1. Facet primitives
• Term facets (checkbox list with counts, virtualized; “show more/less”).
• Range facets (numeric slider + min/max input).
• Date facets (relative/absolute; histogram preview optional).
• Hierarchical facets (e.g., Category → Subcategory).
• Boolean facets (toggle).
• Search-within-facet (typeahead when > 20 items).
2. Query logic & chips
• AND / OR / NOT per facet group.
• Include / exclude (chip shows “NOT tag: linux”).
• Removable chips with keyboard navigation; bulk clear.
• Sync with KQL/query bar and URL state.

Use Case

• Security → Rules library: filter by rule type, severity, MITRE tactic/technique, tags, last updated, owner/package, enabled status.
• Exceptions library: filter by list type, tags, rule linkage, last edited, creator.
• Assets / Findings: filter by cloud provider, account, region, posture status, benchmark, resource type.
• Investigations / Alerts: filter by timeframe, status, rule id, risk score bands, host/user/ip tags.

Value / Impact

• End users: Faster discovery, fewer dead ends, reusable saved views (“My triage view”), clearer mental model via chips + logic.
• Library consumers (product teams): One organism reduces bespoke implementations; consistent UX across apps; faster feature delivery.
• Business: Increases adoption of libraries (rules/findings), improves time-to-value in trials, reduces support for “can’t find X”.

Why widely useful: Faceted filtering is a core pattern across Security, Observability, Search; improvements benefit multiple solutions.

Urgency

9.4 release

Do alternatives or workarounds exist?

Not really

Designs or Specs (Optional)

https://www.figma.com/design/PGis5mLnVM8A6NXxVMwHJJ/Rules-Lifecycle--UI-Library?node-id=2054-12144&t=d3H82qXjUzlSbdwQ-1

[JasonStoltz]

@ARWNightingale Request received. I've flagged this with design (@ryankeairns) and product (@alexmarhaba) to consider it for prioritization.

[ryankeairns]

@JasonStoltz let's also use this one as an opportunity to test the atoms + patterns mindset

[acstll]

@ARWNightingale I was checking the designs and I got some questions 🙂 (things I'm omitting from the list above are more or less clear)

• how would these would look like (I don't need a polished design, fat marker sketch* will do)?
  • Date facets (relative/absolute; histogram preview optional)
  • Hierarchical facets (e.g., Category → Subcategory)
• how are "Boolean facets (toggle)" different from "Term facets (checkbox list with counts)"?
• how are "AND / OR / NOT per facet group" created? (also fat marker sketch will do)
• (not a question) "Sync with KQL/query bar and URL state" I'm unsure this would be part of such pattern

*or screenshot from example, works as well

[ryankeairns]

@acstll we are syncing on Wednesday; added you as optional if it works for your time

[JasonStoltz]

Howdy 👋 Just dropping some notes I took from our conversation today for future context.

There are at least 2 cases in Alex's functional area where a similar faceted search experience is being designed. It would be ideal to align those two designs and establish a pattern for future use cases as well.

For Alex's request, it is not immediately urgent, as they are just in the early phases of design. However, it would be helpful to prioritize some work on the EUI side to help building some early alignment.

From the EUI side -- Our initial proposal is to assign someone from the EUI team to spend a week or two working on a proof-of-concept that illustrates how to achieve the functionality Alex is looking for using what EUI provides today.

The proof-of-concept would:

• Be outside of Kibana, likely in a CodeSandbox or Storybook
• Account for EUI best practices and accessibility standards as closely as possible.
• Attempt to match Alex's requirements as closely as possible, but potentially proposing alternatives that are more technically feasible.

The goals would be to:

• Identify any gaps in EUI primitives for building an advanced faceted search.
• Establish a pattern (or "recipe") for other folks building similar experiences.

The initial goal would not be to build this as a fully formed high level component in EUI. However, in the future, this could be solidified into one, and this would serve as the foundation.