bucket.key to query and to understand how HoneyHive normalizes across ecosystems.
OTel GenAI columns are pinned to semantic conventions v1.36 (stable release). Attributes introduced in v1.37 are noted inline.
How to read this matrix
Each section covers one concept group. Columns are:
A
- in a source column means no standard attribute exists in that ecosystem for this concept. Where HoneyHive canonical also shows -, the attribute is a confirmed gap and must be set manually.
Span / Operation Kinds
Each ecosystem classifies spans by type (LLM call, tool call, agent step, chain, etc.) using a different attribute:
Why this matters for attribute routing: Tool attributes (
config.tool_name, config.tool_description, metadata.tool_call_id) are surfaced in HoneyHive’s Tool section only on spans classified as tool calls. If these attributes are missing in the UI, check that your instrumentation sets the span kind correctly.
Pure OTel v1.36 tool spans: OTel v1.36 has no gen_ai.agent.type attribute. If you’re on pure OTel v1.36, gen_ai.tool.* attributes are still captured and mapped to their canonical destinations (config.tool_name, etc.), they just won’t have a metadata.span_kind set, since there is no source attribute to derive it from. The gen_ai.agent.type attribute arriving in v1.37 will give OTel parity with OpenInference and Traceloop for span kind classification.
Token Counts
metadata.total_tokens is auto-computed by the normalizer from prompt_tokens + completion_tokens (or input_tokens + output_tokens) when not explicitly set. It is the source for the Total Tokens stat in Session Summary.Traceloop uses llm.usage.total_tokens. The llm.usage prefix (instead of gen_ai.usage) is intentional in Traceloop’s instrumentation, not a typo.Model Identity
metadata.model_name is the resolved model name shown in the HoneyHive UI. The normalizer sets it from config.model (request model) as a fallback when no response model is available. Use metadata.response_model for the exact model returned by the API.Provider / system mapping: gen_ai.system (all three ecosystems) maps to metadata.system. gen_ai.provider.name (OTel v1.37+) and llm.provider (OpenInference/Traceloop) map to config.provider.Finish Reason
OTel GenAI defines
gen_ai.response.finish_reasons as a string array. HoneyHive extracts the first element into metadata.finish_reason for single-choice filtering and also stores the full array in metadata.finish_reasons. OpenInference’s singular gen_ai.response.finish_reason maps directly to metadata.finish_reason.Agent Context
Gap: agent handoff context. None of the three ecosystems has a stable standard attribute for passing context between agents in a handoff (e.g., handoff reason, receiving agent name, continuation pointer). If you need this in HoneyHive, set it manually as arbitrary
metadata sub-keys. A naming convention such as metadata.handoff_reason and metadata.handoff_target_agent is recommended for consistency.Tool Linking
Tool call argument mapping (
gen_ai.tool.call.arguments vs OpenInference llm.tools.*) is intentionally out of scope. The attribute structures are complex and framework-specific. See your framework’s instrumentation docs for argument schema details: OTel GenAI tool span spec, OpenInference semantic conventions, Traceloop OpenLLMetry instrumentation.Session / Conversation Context
Gaps Summary
The following concepts have no stable attribute in any of the three instrumentation ecosystems:Related pages
- Semantic Convention Reference - full HoneyHive canonical schema with stability levels and UI behavior