Michael Beemer

It would be useful to also know the expected return type and the value. This becomes a bit tricky when dealing with JSON. In that case, we could either omit...

> `feature_flag.flag_id` or `feature_flag.flag_name` would be less ambiguous, IMHO. (rather than `feature_flag.id`) @moredip, that makes sense. Unfortunately, there doesn't seem to be a clear term used by the industry. A...

Thanks @justinabrahms, I've updated the proposal based on your suggestions. I'm wondering if having the variant name would reduce or eliminate the need for the evaluation value itself. For now,...

@justinabrahms, I agree that the variant name would be best in situations where the result is not a boolean value. However, in those situations, the variant name could simply be...

Thanks @dyladan, that was left over from when we had `feature_flag.evaluated.variant` and `feature_flag.evaluated.value`. I'll update it!

I've put together a quick flowchart to document how we could variants could be generated from values. ```mermaid flowchart TD A[Start] --> B{Has Variant Name} B -->|Yes| C[Use It] C...

This is a theoretical issue at this point which is why it hasn't been a priority. However, in the future, library authors may want to include OpenFeature support in their...

relates to #65

@oleg-nenashev does this need to be open?

Closing in favor of the [OFEP](https://github.com/open-feature/research/pull/30).