"Feature flags with OpenTelemetry" actually covers two separate integrations that get talked about as one thing. One of them rollfuse ships today. The other one, like most guardrail platforms, it doesn't, natively, and it's worth being clear about which is which.
What's real: trace propagation on every evaluation call
Every SDK-originated call to rollfuse's evaluation API (sdk-js, sdk-browser, and sdk-react's server-mediated proxy) carries W3C trace-context propagation. If the integrating application has @opentelemetry/api installed as an optional peer dependency, with an active span at the moment of the call, that span's context is injected into the outbound request via propagation.inject. The flag evaluation shows up as a child of whatever trace was already in flight, instead of arriving as an orphaned call with no relationship to the request that triggered it.
If there's no OTel API installed, or nothing active, the SDK generates a self-issued, spec-valid traceparent instead. So the call still originates a linkable trace either way, degrading gracefully rather than requiring OTel to be present at all. This is a genuinely useful thing to have working end to end: when you're debugging why a request behaved a certain way, being able to see "this request evaluated checkout-v2 and got variation B" as a span in the same trace as the request itself, rather than in a separate flag-evaluation log you have to correlate by hand, is the actual payoff.
What's not (yet) built: OTel metrics driving a guardrail
The other half of "feature flags with OpenTelemetry," using an OTel-collected metric to automatically pause or roll back a rollout, is a different mechanism, and it isn't a native integration today. rollfuse's guardrails evaluate a metric definition on a schedule; getting an OTel-collected metric's value into that pipeline means either pushing it as an observation on a cadence matching the guardrail's evaluation window, or pulling it via a Connector configured against wherever that metric ends up queryable (an OTLP-receiving backend's own query API, for instance). It's the same shape as bridging a Prometheus metric in, not a built-in OTLP receiver on rollfuse's side.
Why the distinction is worth keeping straight
Tracing and metrics solve different problems even inside OpenTelemetry itself: one explains what happened on a specific request, the other aggregates what happened across many. A platform's OTel story being real for one doesn't imply it's built for the other, and conflating them is how a team ends up assuming a rollout will auto-abort on an OTel metric because "we already have OpenTelemetry working," when what's actually working is the trace propagation, a genuinely separate piece.