Should rollout state be observable through a standard shape? (state, not policy)

[1991santhu]

The problem, stated small

OpenFeature's evaluation API answers one question: which variant does this evaluation context get under the current configuration. It does not say whether a flag is mid-rollout, at what exposure, or whether progression is currently held. That state exists, but only inside whichever management system happens to hold it, in a shape no other tool can rely on.

So a canary has two halves and only one is portable. Exposure (which slice sees the change) is expressible through fractional evaluation. The gate (when exposure advances, holds, or reverses) lives entirely above the API, and there is no standard way to even read where a rollout currently sits.

This is a real gap, and I don't think it's OpenFeature's fault. Being precise about where it sits is the point of opening this.

What I'm not proposing

• No rollout policy in the spec. Thresholds, analysis windows, promotion logic, rollback conditions are vendor and controller territory and should stay there.
• No management/mutation API. Nothing here changes flag configuration.
• No requirement on providers to support rollouts at all.

What I am proposing

A small, optional, observational shape for rollout state: not "how should this rollout behave" but "is a rollout happening, and where is it right now." Something a provider that has this information could expose, and tooling could consume consistently, without OpenFeature defining any policy.

A minimal shape worth arguing about:

Field	Meaning
status	pending, running, held, rolled-back, completed
current_exposure	The proportion in effect now
intended_target	Where this rollout is heading
started_at	When it began
last_transition_at	When exposure or status last changed
hold_reason	Why progression is paused, when it is
controller_ref	The external system driving it, if any

Read-only, provider-optional, no-op where unsupported, mirroring how tracking already handles optionality.

The question

Does rollout state deserve a standard representation at all, or is the current boundary (state stays private to each management system) the right one? I lean toward "worth choosing deliberately rather than inheriting," but I'd rather have the boundary questioned here than assert it.

If there's appetite, I'm happy to turn this into a concrete proposal against the spec. Longer write-up with the reasoning behind each piece is here, but the question above is the part I actually want this community to settle.