“Standardized naming schemes and attribute definitions for telemetry data across services, languages, and platforms.”A semantic convention is an agreement about what to call things. Without conventions, every team invents their own attribute names — one calls it
prompt, another input.text, another messages[0].content — and tools that try to read all of those have to maintain mappings for every variant.
OpenInference defines the canonical attribute names for AI/LLM telemetry. Arize AX uses these conventions to render spans in the UI, and any OTel-compatible backend that understands OpenInference can do the same.
Why Semantic Conventions Matter
Three concrete benefits, all of which compound as your stack grows:
Two examples of OpenInference attribute names:
llm.input_messages on a span, Arize AX knows it’s the chat history. So does any other OpenInference-aware backend. So does anyone reading your trace export six months from now.
OpenInference vs GenAI
The GenAI observability space currently has two semantic convention standards. They overlap in what they describe but differ in maturity and governance.
Both conventions are first-class in Arize AX. If you are deciding what to instrument with, OpenInference still offers the richest fidelity, the strongest stability guarantees, and the widest auto-instrumentor coverage. But if your framework emits native OTel GenAI spans (for example, Microsoft Agent Framework or CrewAI Studio), you no longer need a client-side processor to reshape them before export. Arize AX handles the normalization on ingestion, as the next section describes.
Over time the two conventions are expected to converge as the GenAI spec stabilizes. When that happens, the OpenInference auto-instrumentors will pick up the change so your application code does not have to.
How Arize AX ingests GenAI spans
When a span reaches Arize AX carrying any attribute prefixed withgen_ai., the ingestion pipeline normalizes it into the equivalent OpenInference attributes before the span is stored. The result is that spans instrumented purely with the OTel GenAI conventions render in the UI with the correct span kind, messages, token counts, tool inputs and outputs, and retrieved documents — the same treatment OpenInference spans receive.
No client-side reshape processor is required. Frameworks that emit native OTel GenAI spans, such as Microsoft Agent Framework and CrewAI Studio, are ingested and rendered directly.
Three rules govern the normalization:
- Raw
gen_ai.*attributes are preserved. Normalization adds OpenInference attributes; it never removes the original GenAI ones, so your raw telemetry stays intact on the span. - Explicit OpenInference attributes always win. If a span already carries an OpenInference attribute (for example, your instrumentation set both
gen_ai.request.modelandllm.model_name), the existing OpenInference value is kept and the GenAI-derived value is discarded. - Unrecognized operations stay unclassified. The span kind is inferred from
gen_ai.operation.name. An operation name that Arize AX does not recognize leaves the span kind unset rather than guessing.
gen_ai.operation.name and translates the payload — messages, tool calls and results, token usage, retrieved documents, and provider identity — onto the corresponding OpenInference attributes. For the complete span-kind classification and the full gen_ai.* → OpenInference attribute mapping, see GenAI semantic convention mapping on the Span Kinds reference page.
The Authoritative Source
OpenInference is open-source. The canonical attribute lists, span kind enums, MIME type values, and LLM provider/system enums live in the OpenInference repository — language-specific implementations track these definitions exactly.Python Semantic Conventions
TS Semantic Conventions
What’s Covered in OpenInference
The conventions cover four broad categories:
The next page walks through the span-kind catalog in detail.