Why does gen_ai.provider.name replace gen_ai.system on GenAI spans?

## What changed The GenAI semantic conventions originally identified the thing you were talking to with an attribute called `gen_ai.system`. That name has been deprecated and replaced by `gen_ai.provider.name`. The values are the same kind of thing — short identifiers such as `openai`, `anthropic`, `aws.bedrock` — but the key and, more importantly, the definition were tightened. ## Why the rename happened "System" is one of the most overloaded words in this space. A prompt has a system message. A model is part of a system. Teams read `gen_ai.system` as any of: the model vendor, the product name, the hosted endpoint, or the framework in the middle. Instrumentation authors made different choices, so the attribute stopped being reliably comparable across libraries — which is the only thing a semantic convention is for. `provider.name` states the intent in the key itself: the name of the provider whose API received the request. ## Provider is the endpoint, not the model's creator This is the distinction interviewers probe. Consider a Claude model invoked through Amazon Bedrock. Anthropic built the model; Amazon served the request. The convention records `gen_ai.provider.name` as the Bedrock endpoint you actually called, while `gen_ai.request.model` carries the Claude model identifier. The same reasoning applies to any gateway-style hosting: the provider attribute answers "whose API did we hit, whose rate limits and whose availability are we exposed to", and the model attribute answers "what weights produced this text". Keeping them separate is what makes two very different operational questions answerable from the same spans: - *Blast radius*: group errors and latency by `gen_ai.provider.name` when an endpoint degrades. - *Model behaviour and cost*: group tokens and quality scores by model when you are comparing or migrating models. Collapsing them into one attribute — which is what happened when teams put the model vendor into `gen_ai.system` — makes it impossible to say that the same model behaved differently through two different endpoints, which is a real and commonly observed effect. ## The deprecation trap Deprecated does not mean deleted. The old constant is still shipped in the semantic-conventions package, so a naive check — grepping the library, or seeing the key present on last month's spans — "confirms" it. Presence proves an identifier exists; it says nothing about whether it is current. In practice that means: - Instrumentation pinned to an older release still emits `gen_ai.system`. - Newer instrumentation emits `gen_ai.provider.name`. - During a staged rollout your backend holds **both**, on different spans, and a dashboard filtering on only one silently under-counts. ## How to run the migration 1. **Inventory.** Query for spans carrying each key over a recent window, grouped by service. That tells you which services are still on old instrumentation rather than guessing from dependency files. 2. **Make queries tolerant.** For the duration, have saved views and alerts coalesce the two keys (`provider.name` if present, else `system`). This is the step teams skip, and it is why a migration produces a fake traffic cliff on a dashboard. 3. **Upgrade instrumentation service by service**, verifying on a real span that the new key appears. 4. **Cut over and delete the fallback** once no spans carry the old key. Leaving the coalesce in place forever means the next person cannot tell which spelling is authoritative. ## Related renames in the same family This is not an isolated event: the usage attributes moved from prompt/completion wording to `gen_ai.usage.input_tokens` and `gen_ai.usage.output_tokens` on similar reasoning — provider-neutral names that mean the same thing everywhere. The general lesson for an interview answer is that these conventions are still stabilising, so anything you build on top of them (dashboards, alerts, cost allocation, retention rules) needs a documented owner and a plan for rename events, not a one-off query pasted into a wiki. ## Note on other attributes Be careful not to over-generalise the deprecation. Some GenAI attributes carry notices that only say the definition moved to a different repository — that is a packaging change, not a rename, and those attribute names stay valid. `gen_ai.request.model`, `gen_ai.request.temperature` and the two usage counters are in that category. Only `gen_ai.system` was actually superseded by a new spelling.