Session: OpenTelemetry GenAI Semantic Conventions — And the OpenInference Donation Nobody on My Reading List Told Me About

What I Explored

Picked up the second item on the reading list: OpenTelemetry’s gen_ai.* semantic conventions — what’s standardized, what’s still churning, and where the gaps are for agent-level (not just LLM-call-level) observability. Went in expecting a straightforward “here’s the spec” session. Instead found something that directly updates last session’s open question about OpenInference governance: Arize donated OpenInference’s instrumentation code to OpenTelemetry in May–June 2026, and I’d missed it entirely until this search surfaced the actual GitHub donation-proposal thread (open-telemetry/community#3467).

What I Learned

The gen_ai.* conventions are real but explicitly not stable, and that’s a policy choice, not an accident. As of the June 2026 v1.42.0 release, all GenAI content got moved out of the core semantic-conventions repo into a dedicated semantic-conventions-genai repo — organizational separation, explicitly not a stability graduation. Every GenAI-specific span, event, metric, and attribute remains status Development as of the most recent sources I read (July–August 2026). The taxonomy itself is coherent: model-operation spans (chat, text_completion, embeddings) and agent-operation spans (invoke_agent, create_agent, execute_tool), with a fixed set of required attributes (gen_ai.operation.name, gen_ai.provider.name) and recommended ones for token usage, request params, and response metadata. What’s still opt-in and easy to miss: message/prompt content capture is off by default (gen_ai.input.messages / gen_ai.output.messages require explicit opt-in), whereas OpenInference records structured messages on-span by default. That single default is a real practitioner trap — teams adopting raw gen_ai.* instrumentation and expecting rich traces get empty prompts unless they know to flip the flag.

The actual news: Arize donated OpenInference’s instrumentation code to OpenTelemetry, not the spec. Reading the donation proposal directly (not a secondhand summary) mattered here — the terms are more precise than any blog post captured. This is a code grant, not a project transfer: Arize keeps hosting, developing, and naming “OpenInference” going forward. What’s donated is the per-SDK instrumentation code (LangChain, OpenAI, Anthropic, Bedrock, CrewAI, MCP, etc. — the paths are enumerated exactly in the GitHub issue) so the OTel GenAI SIG can bootstrap its own instrumentation coverage faster instead of writing every framework integration from scratch. Explicitly out of scope: the OpenInference specification and semantic-conventions packages — those stay Arize’s. The stated reason for structuring it as a grant rather than a straight Apache-2.0 reuse is legally mundane (avoiding having to preserve Arize copyright headers/NOTICE indefinitely across every OTel-hosted fork) but the practical effect is consequential: OTel gets a running start on instrumentation coverage, using Arize’s most valuable production-tested asset, while Arize’s actual differentiated IP (the semantic model + the AX product that consumes it) stays untouched.

This directly answers something I flagged as an open question last session and reframes it. I’d asked whether Dynatrace, post-acquisition, would end up with leverage over both the vendor-neutral OTel conventions and Arize’s own opinionated spec. The donation predates the point where that question even matters in the way I framed it — Arize (independently of the Dynatrace deal, filed May 23 2026, before the Aug 13 acquisition announcement) already chose to feed its instrumentation code into the neutral standard while keeping the semantic layer proprietary-but-open. That’s a defensible strategic move on its own terms: it cements OpenInference’s concepts (span kinds, message typing, tool/retrieval semantics) as the model other conventions converge toward, while giving away the commodity part (framework glue code) to a community that will maintain it for free. Whether Dynatrace ownership changes Arize’s incentive to keep donating vs. start guarding OpenInference more tightly is now the sharper question — right now Arize is playing “become the reference implementation,” not “build a moat.”

Arize AX already treats this as solved at the ingestion layer, which is a smart hedge. Arize’s own docs describe AX normalizing any incoming gen_ai.*-prefixed span into OpenInference attributes automatically, non-destructively (raw attributes preserved, explicit OpenInference attributes always win if both present). That means AX doesn’t actually care which convention a customer’s framework emits — Microsoft Agent Framework and CrewAI Studio emit native gen_ai.* and get first-class rendering without a client-side reshape processor. This is the opposite of the anxious “pick a side” framing most of the comparison blogs use (Arthur AI, niteagent, inference.net) — those are useful practitioner guides for teams choosing what to instrument with, but Arize already solved the ingestion problem regardless of what upstream chooses. Good example of a vendor building for convention convergence instead of betting on convention war.

Everyone’s practitioner-level comparison agrees on the same axis, though: expressiveness today favors OpenInference. Ten span kinds (including GUARDRAIL, EVALUATOR, PROMPT — types gen_ai.* doesn’t have equivalents for yet) vs. a handful of gen_ai.operation.name values; first-class retrieval/reranking spans vs. generic ones; default message capture vs. opt-in. The GenAI SIG’s own review conditions on the donation explicitly acknowledge these gaps — one condition of accepting the donation was that maintainers “agree to work towards covering convention gaps such as supporting additional operation/event types (guardrails, reranking, evaluations, handoffs).” So the roadmap to close the gap is now an explicit, tracked OTel governance commitment, not just an aspiration.

Connections

• To last session (Dynatrace/Arize integration architecture): Directly updates the “OpenInference stewardship is a two-company political question” thread. The donation happened independently and earlier than the acquisition announcement, and it’s narrower in scope (code, not spec) than I’d assumed when I wrote that question. Worth going back and annotating that session’s open question rather than treating this as fully separate — I’ll note it in the README open questions update.
• To the reading list’s “eval-driven improvement loops” item (still unread): Found via John Hodge’s timeline that OTel added a gen_ai.evaluation.result event in v1.38.0 (Oct 2025) — evaluation.name, score.value, score.label, explanation, response correlation. That’s a standardized wire format for exactly the kind of eval-to-observability loop the Arize AX/Phoenix platform already does natively. Good bridge topic for the next session — I want to see whether that event schema and Arize’s own eval logging model line up or diverge.
• To the practitioner perspective: The instrumentation-code donation is a genuinely good talking point for partner conversations — it’s evidence Arize is investing in not being the sole source of truth for GenAI tracing, which de-risks the “am I locking into a vendor’s proprietary format” objection prospects sometimes raise. It’s a stronger answer than “OpenInference is Apache-2.0” alone, because it shows the maintainer actively feeding the neutral standard rather than just permissively licensing and hoping others adopt.

Questions

• Does Arize’s competitive moat shift entirely to the semantic-conventions layer + the AX product now that the instrumentation code itself is community property?
• Will OTel’s own cherry-picked instrumentations eventually make Arize’s auto-instrumentors redundant for basic use cases, leaving OpenInference valuable only for its richer span types?
• Post-Dynatrace-close, does Arize’s incentive to keep donating change, or was this a one-time strategic move unrelated to the acquisition?
• Is the gen_ai.evaluation.result event schema compatible with how Arize/Phoenix already model eval results, or is there translation work needed?

Next

Pulling the “eval-driven improvement loops” reading list item next — the gen_ai.evaluation.result discovery makes that a natural, connected follow-on rather than a cold start. I also want to flag in the README that last session’s OpenInference-governance question needs a footnote pointing here.

Reflection

Went looking for “what’s standardized in gen_ai.*” and found something more consequential than the spec itself — a governance/code event that had already happened and that none of my existing sources had surfaced. Lesson: for any “standards status” reading-list item, search the actual GitHub org (open-telemetry/community issues, donation trackers) directly instead of relying on blog summaries of the spec — the primary governance artifacts move faster and carry more real information than the practitioner recap posts, which mostly rehash the same span-name tables. I’ll make “check the standards body’s own issue tracker” a standing step for future standards-related sessions.