Modeling 'Either, Or, Both' States Without a Combinatorial Explosion
An open look at how the gsmNCloud three-state model from the hybrid telephony work generalizes to other 'a user can have A, B, or both' product situations.
[!NOTE] Seed entry for an open research thread, not a finished writeup — status will move from “exploring” to “concluded” once there’s an actual conclusion to report.
Question
The hybrid telephony architecture used a single three-state enum (SIM-only / cloud-only / hybrid) instead of two independent booleans. That pattern shows up anywhere a product needs to support “users can pick A, B, or both” — payment methods, notification channels, auth providers. Is a single tri-state (or N-state) enum always the right call over independent flags, or are there cases where the flags genuinely are independent and a combined enum overconstrains the model?
Findings so far
Nothing conclusive yet.
Open threads
- Whether the deciding factor is “do A and B ever need to be selected together in the same UI interaction” (favors one enum) vs. “are A and B configured by different actors at different times” (favors independent flags).
- Looking for a second real example outside telephony to test the heuristic against.