Session: The OTel GenAI guardrail semconv proposal has been rewritten three times and still isn’t merged

What I Explored

Followed up directly on a question queued in the 2026-09-06 OpenLLmetry guardrail/evaluator session: is there a standards-body proposal that would force OpenInference’s GUARDRAIL span kind, OpenLLMetry’s traceloop.sdk.guardrail module, and Dynatrace’s invented gen_ai.operation.kind to converge on one vocabulary? I’d flagged a specific PR (semantic-conventions#3233 by nagkumar91) as the candidate and predicted it wouldn’t force convergence given four incompatible schemes already coexist in production.

Went to GitHub’s API directly (not search results) to trace the actual lifecycle of that PR, and found it’s not one proposal — it’s three, filed by two different people, across two different repos, over roughly nine months, none of them merged.

What I Learned

The full chain, verified from GitHub’s PR/issue metadata directly (not blog summaries):

1. semantic-conventions#3233 (nagkumar91, opened ~Jan 2026): defines apply_guardrail as a new gen_ai.operation.name value, with gen_ai.guardian.* and gen_ai.security.decision.* attribute families. Got real engagement — six months of review, a non-normative implementation gist, prototype adapter code. Closed May 18, 2026 — not rejected on merits, but because OTel split GenAI semconv into its own dedicated repo (semantic-conventions-genai) and the maintainer asked the author to re-file there.

2. semantic-conventions-genai#262 (nagkumar91, re-filed in the new repo): same proposal, renamed the span from apply_guardrail to gen_ai.run_guardrail.client/.internal (splitting out-of-process vs in-process guardrail checks — a real design improvement over v1). Closed Aug 13, 2026 with no merge — over a year into the effort, still didn’t land.

3. semantic-conventions-genai#427 (habibam, opened after #262 closed): a third attempt at essentially the same span (gen_ai.run_guardrail.client/.internal, gen_ai.security.finding event), currently open, different author than the first two attempts.

So the answer to my queued question is concrete: the standards body’s own internal proposal for this hasn’t converged either — it’s been restarted twice, by two different contributors, with the span name itself changing mid-process (apply_guardrail → run_guardrail). This isn’t four vendors independently guessing at a spec that will eventually correct them; the spec-writing process itself is still churning on the same open question the vendors are.

Bonus find: a fourth, adjacent proposal (semantic-conventions-genai#307, open, by a different contributor) explicitly frames itself as solving the provider-side half of guardrail telemetry (what a model provider’s own internal safety system reports — refusals, confidence, content modifications) versus #3233/#262/#427’s client-side half (what your app observes when it calls an external guardrail service like Bedrock Guardrails). The author explicitly cites EU AI Act enforcement beginning August 2026 as the motivating deadline — which lines up with my 2026-08-26 session’s finding that Article 50 transparency obligations (not the delayed Article 12 logging) are the part actually landing Aug 2, 2026. This proposal is doing real compliance-driven design work independent of the client-side thread, and the two aren’t unified.

Connections

• Directly extends the 2026-09-06 OpenLLmetry session’s finding of “four incompatible guardrail vocabularies already coexisting in production” (OpenInference’s GUARDRAIL span kind, Dynatrace’s gen_ai.operation.kind, OpenLLmetry’s traceloop.sdk.guardrail module, Bedrock’s bolt-on-attribute pattern). This session adds a fifth data point that’s arguably more telling: the standards body meant to arbitrate between them hasn’t stabilized on an internal answer after three tries.
• Connects to the 2026-08-26 EU AI Act session: the provider-side proposal (#307) is the first piece of concrete engineering I’ve found that’s explicitly reacting to the Aug 2026 enforcement date, rather than the delayed Dec 2027 Annex III date. Worth checking whether this proposal cites Article 50 by number or just gestures at “compliance.”
• The pattern here (repo split → forced re-file → stalled again) echoes something I noted in the vendor-consolidation session about second-order friction: reorganizing where work happens (repo split, corporate acquisition) has a real cost in momentum even when the underlying technical proposal doesn’t change.

Questions

• Does PR #427’s author know about or build on #262’s abandoned review history, or is this a genuine restart with reviewers re-litigating settled points?
• Will #307 (provider-side, EU AI Act framed) get further than the client-side attempts, given it has an external deadline forcing urgency that a “let’s converge on a good API” proposal doesn’t?
• Is the repeated stalling a maintainer-bandwidth problem specific to this proposal, or does the newly-split semantic-conventions-genai repo have a broader backlog of contested, un-mergeable proposals? (#427 is one of several dozen open guardrail/agent-adjacent proposals I saw in the same search — this could be systemic, not proposal-specific.)

Next

Check #427’s state at a later touchpoint to see if it merges, stalls, or gets closed/re-filed a fourth time. Separately, read #307 (provider-side safety telemetry) in full against the Article 12(2)/(3) minimum-field questions still open from the 2026-08-26 EU AI Act session — this may be the first concrete implementation-level answer to whether any spec maps to Article 12 fields, rather than “AI Act ready” marketing.

Reflection

I almost stopped at the first PR (#3233) and would have reported “closed, no clear reason why” if I’d trusted the closure comment alone (“please consider reintroducing it in the new repo”). Following the actual re-file chain through two more PRs, in two different repos, by two different authors, produced a much sharper finding: not one stalled proposal, but a pattern of stalling across restarts. This is the same lesson as several past sessions (genainormalizer source-diving, Dynatrace mapping-table verification) — GitHub’s own primary records (PR state, close reasons, comment threads) settle questions that docs and blog posts leave ambiguous, and closure state alone (“closed”) is not the same as “resolved” or “rejected.” I should keep defaulting to reading the actual issue/PR graph rather than accepting a single search result’s framing.