Why follow the OpenTelemetry GenAI semantic conventions when tracing LLM calls?

## The problem the conventions solve Every team that instruments LLM calls invents attribute names on day one: `model`, `model_name`, `llm.model`, `openai.model`. Individually all fine. Collectively they mean that a dashboard built for one service is useless for the next, a query for 'all calls to the expensive model across the estate' has to enumerate spellings, and switching observability backends means touching every service. Semantic conventions are the fix: a published vocabulary, so that instrumentation written by different people — and by library authors who have never seen your system — produces spans that mean the same thing. ## What the GenAI conventions cover The part you use daily is the model-call span. Conventionally it is named after the operation and the model, and carries: - `gen_ai.operation.name` — what kind of call this is (for example chat or embeddings). - `gen_ai.system` — which provider or system served it. - `gen_ai.request.model` — the model you asked for, and `gen_ai.response.model` — the model that actually answered. These differ more often than people expect, when a provider serves an alias or a pinned snapshot. - Request settings such as `gen_ai.request.temperature` and `gen_ai.request.max_tokens`. - `gen_ai.response.finish_reasons` — why generation stopped, which is the single most useful attribute for diagnosing truncated output. - `gen_ai.usage.*` — input and output token counters. There are also conventions for tool and agent operations, and a separate, more contested area: where the prompt and completion *content* goes. Content has moved between span attributes, span events and log records across revisions, which is precisely the kind of churn you have to plan for. ## The stability picture as of mid-2026 This matters more than the attribute list. The `gen_ai.*` conventions are **not stable**. In June 2026 they were split out of the main semantic-conventions repository into a dedicated one at v1.42.0, and there is still no 1.0 and no committed stabilisation date. Concretely: an attribute you emit today may be renamed in a release six months out, and instrumentation libraries will adopt the rename at different times, so a single trace can contain both spellings. Mature teams handle this with four habits: 1. **Pin and record the convention version.** Treat it as a dependency, not a background fact, and put the version on the span or resource so you can tell later which spelling to expect. 2. **Use dual emission during a rename.** The ecosystem's mechanism is the `OTEL_SEMCONV_STABILITY_OPT_IN` environment variable, which lets instrumentation emit old names, new names, or both for a migration window. Both means dashboards keep working while you cut over. 3. **Normalise in the pipeline, not in the services.** A collector-side transform that maps yesterday's names onto today's is one change instead of forty, and it can be removed once every service has moved. 4. **Namespace your own attributes.** Anything you invent — feature name, tenant, prompt version, verdict — goes under a prefix you own. Never squat inside `gen_ai.*`, because a future convention release may define your name with different semantics. ## What you still have to decide yourself The conventions are a naming contract, not an instrumentation design. They do not tell you how to nest agent, tool and retrieval spans, what your correlation ids should be, or how much payload to capture. They also cannot make a badly shaped trace useful: perfectly named attributes on a single span per turn are still a single span per turn. Treat conventions as the interoperability layer beneath your own span taxonomy. ## When to deviate Deviating is sometimes right, and should be a decision rather than an accident. If a convention has no attribute for something you genuinely need, add it in your own namespace and move on. If your provider exposes a concept the conventions have not modelled, do the same. What you should not do is rename convention-covered concepts to something you prefer, because you are then paying the cost of a standard — learning it — while getting none of the benefit. ## The interview point The strong answer has two halves. First, why standardising names pays: portability across tools, languages and providers, and dashboards that outlive any one vendor choice. Second, an honest account of the state of these particular conventions in 2026 — pre-stable, actively moving, with a documented dual-emission escape hatch — and the migration discipline that follows from it. Candidates who only recite attribute names miss the half that actually bites in production.