Four schemas, ~90% the same problem

Design philosophy

OpenInference defines a strict span-kind taxonomy via the required openinference.span.kind attribute. The schema is opinionated: every span declares whether it's an LLM, EMBEDDING, RETRIEVER, TOOL, AGENT, CHAIN, RERANKER, GUARDRAIL, or EVALUATOR. This makes downstream evaluation and dashboard rendering deterministic, but it requires instrumentation to care about which kind a span is.

Attribute style

Dot-namespaced with indexed flattening: llm.input_messages.0.message.role, llm.input_messages.1.message.content, etc. Every list-valued attribute is exploded this way (as opposed to OTel v1.41's JSON-on-attribute approach).

Where it shines

RAG and retrieval: retrieval.documents.{i}.document.{id,content,score,metadata} is the cleanest schema for retrieval traces among the four. Phoenix / Arize AX render these directly into evaluation pipelines.

Example span (LLM kind)

openinference.span.kind:           "LLM"
llm.model_name:                    "gpt-4o"
llm.provider:                      "openai"
llm.input_messages.0.message.role: "system"
llm.input_messages.0.message.content: "You are…"
llm.input_messages.1.message.role: "user"
llm.input_messages.1.message.content: "Tell me…"
llm.output_messages.0.message.role: "assistant"
llm.token_count.prompt:            412
llm.token_count.completion:        128
llm.token_count.prompt_details.cache_read: 300
llm.invocation_parameters:         '{"temperature":0.7}'

Design philosophy

OpenLLMetry is the pragmatic upstream contributor. Traceloop (acquired by ServiceNow on March 2, 2026) ships drop-in instrumentations for 30+ LLM providers, frameworks (LangChain, LlamaIndex, Haystack, CrewAI), and vector DBs (Pinecone, Qdrant, Weaviate, Chroma, Milvus, …) — many of which are fed back into OTel SemConv. When OTel adopts a convention, OpenLLMetry deprecates its own and aliases.

Where it differs from raw OTel

• traceloop.workflow.name / traceloop.task.name for orchestration nesting (a workflow is a sequence of tasks)
• traceloop.entity.name / traceloop.entity.path for dotted-path call hierarchy
• traceloop.association.properties.* for attaching user/session/custom IDs
• Vector DB instrumentations expose db.vector.query.top_k, db.vector.namespace, etc.

Migration trajectory

Older versions emitted gen_ai.prompt / gen_ai.completion; the project is migrating to OTel's gen_ai.input.messages / gen_ai.output.messages. Issue #3515 tracks this transition.

Example span (orchestrated workflow)

// span name
"openai.chat"

gen_ai.system:                "openai"
gen_ai.operation.name:        "chat"
gen_ai.request.model:         "gpt-4o"
gen_ai.usage.input_tokens:    412
gen_ai.usage.output_tokens:   128
traceloop.workflow.name:      "customer_qa"
traceloop.entity.name:        "answer_step"
traceloop.entity.path:        "customer_qa.retrieve.answer_step"
traceloop.association.properties.user_id: "u-42"

Design philosophy

Langfuse models traces as a tree of Observations, with three core types: SPAN (generic unit of work), GENERATION (LLM call with prompt/output/usage), and EVENT (point-in-time log). Extended types (Agent, Tool, Chain, Retriever, Evaluator, Embedding, Guardrail) layer semantic meaning onto SPAN. Trace-level attributes (user_id, session_id, tags, metadata) are propagated to every observation for single-table queries.

OTel mapping

Langfuse accepts OTLP and maps incoming OTel attributes onto its data model:

• spans with gen_ai.operation.name=chat → GENERATION observation
• gen_ai.usage.input_tokens → usage.input
• gen_ai.request.model → model (and matched against Langfuse's price catalog)
• session.id → trace-level session_id
• user.id / OpenInference / OpenLLMetry equivalents are recognized

Example observation (GENERATION)

{
  "id": "obs_abc",
  "trace_id": "trc_xyz",
  "type": "GENERATION",
  "name": "answer_step",
  "model": "gpt-4o",
  "model_parameters": { "temperature": 0.7 },
  "input": [{"role":"user", "content":"…"}],
  "output": { "role":"assistant", "content":"…" },
  "usage": { "input":412, "output":128, "total":540 },
  "user_id": "u-42",         // propagated
  "session_id": "s-7",
  "level": "DEFAULT"
}

Strengths beyond the schema

Cost catalog (auto-prices by model), prompt management, evaluators, datasets, sessions UI. The schema decisions reflect product priorities — they're easier to query at the UI level than to interop with externally.