Today the segment ↔ identity relationship only navigates in one direction: from an identity we can list the segments it belongs to, but from a segment there is no way to inspect the set of identities that match its rules — only to search for one identifier at a time in the segment editor.
This presents an architecture design problem. Flagsmith segments are rule-based. Membership is computed by the flag engine on every read and is not currently persisted. Any "list members" capability has to work over both identity stores (core and edge) and account for rule shapes that don't reduce to simple equality (percentage splits, regex, modulo, "is not set", etc.).
Scope of this spike: decide what v1 of segment-membership inspection looks like — UX, API shape, evaluation path — and surface the architectural questions that fall out of that decision.
Definition of Done:
Today the segment ↔ identity relationship only navigates in one direction: from an identity we can list the segments it belongs to, but from a segment there is no way to inspect the set of identities that match its rules — only to search for one identifier at a time in the segment editor.
This presents an architecture design problem. Flagsmith segments are rule-based. Membership is computed by the flag engine on every read and is not currently persisted. Any "list members" capability has to work over both identity stores (core and edge) and account for rule shapes that don't reduce to simple equality (percentage splits, regex, modulo, "is not set", etc.).
Scope of this spike: decide what v1 of segment-membership inspection looks like — UX, API shape, evaluation path — and surface the architectural questions that fall out of that decision.
Definition of Done: