In this article
GenAI conventions evolve. Keep instrumentation versions and definitions with data so renaming is not mistaken for changed service behavior.
Instrumentation updates can rename metrics or attributes without changing the model or API process. A dashboard loses series, an alert becomes quiet, and old queries still expect former labels. Providers should treat this as measurement-contract migration, preserving convention versions, checking actual exported payloads and moving analytics explicitly rather than merely updating a dependency.
Identify the current source
At the review date, OpenTelemetry GenAI conventions live in a separate official repository. The client-inference document describes caller-side spans and metrics with Development status. A current-main link is not an immutable specification; reproducible decisions need a revision or recorded version.
Record documents used and which elements the library actually implements. Documentation may describe a new form while an installed SDK exports an older one. Example names must not become claims about working telemetry without inspecting output.
Separate observation scopes
The GenAI span document relates spans to caller-observed logical operations and their completion. Server handling and client calls observe different boundaries. Do not substitute their durations simply because both concern the same model and use similar names.
When an operation includes retries, its span definition must reflect that semantics. Attempts can be observed separately, but their count should not silently change logical-outcome meaning. Preserve relationships before building dashboards so period comparisons remain explainable.
Verify names and units
The GenAI metrics document separately describes server duration, TTFT and TPOT. Check each element’s status, unit and attributes. Development status does not make it useless; it requires managed change rather than assuming every name is permanent.
Build a small fixture with a short operation, completion and failure. Save exported instrument names, units, scope and attributes. This checks instrumentation rather than inference performance. Real prompts and secret headers are unnecessary for structure validation.
Produce a migration diff
Compare old and new payloads using explicit categories: removed, renamed, changed unit or added. Identify changes requiring query, recording-rule or alert updates. Successful export does not establish that an old dashboard still measures the intended quantity.
Do not preserve continuity by emitting identically named series with different meanings. If both versions coexist temporarily, prevent double counting. Record transition duration and removal criteria so migration code does not become permanent ambiguity.
Bound conclusions to versions
A passed fixture establishes the chosen SDK and configuration, not every engine’s support for all conventions. Repeat it at the next update. Latency and usage comparisons require confirming unchanged meanings and event populations.
Related guides cover reproducible stacks and monitoring design. The deliverable is a versioned measurement contract rather than an eternal invented standard or a claim of an existing observability system. Keep the raw exported sample with the diff so reviewers can distinguish documented intentions from values actually emitted by the installed instrumentation.