Semantic Conventions 2026 Roadmap

[lmolkova]

Warning

This is work in progress, not a final roadmap
We're looking for input from all semconv sub-SIGs!

Principles

stability, decentralization

Ideas:

• Federated Semconv - V2 Schema, Dependencies + Publishing
  • Finish OTEP: Federated SemConv and Schema v2 opentelemetry-specification#4815
  • Onboard at least on OTel repo to define federated conventions
  • Onboard at least on contrib repo to weaver live checks and automated testing @open-telemetry/weaver-approvers
  • Introduce span identity
• Core
  • Finish first cut of all "How To Write Semantic Conventions" Guides
  • Create a backlog of "de-facto stable, but alpha" semantic convention areas in a "grab bag" list for SIG forming
  • Declarative configuration for instrumentations as part of semconv @open-telemetry/configuration-approvers
• [Confirmed plans] Stabilize conventions:
  • rpc @open-telemetry/semconv-rpc-approvers
  • system and process @open-telemetry/semconv-system-approvers
  • K8s @open-telemetry/semconv-k8s-approvers
  • error/exception @open-telemetry/specs-logs-approvers
    • Deprecate span events
• [Unconfirmed] Stabilize conventions:
  • Feature-flags? Stabilize feature-flag semantic conventions #3409 @open-telemetry/semconv-feature-flag-approvers
  • GenAI (core set)
  • Start messaging stabilization @open-telemetry/semconv-messaging-approvers
  • service? @open-telemetry/semconv-service-and-deployment-approvers
• New conventions / features / etc
  • @open-telemetry/browser-approvers
  • @open-telemetry/semconv-genai-approvers
  • @open-telemetry/semconv-security-approvers
  • Semantic Conventions 2026 Roadmap #3330 (comment) @open-telemetry/sig-mainframe-approvers
  • @open-telemetry/profiling-approvers
  • @open-telemetry/semconv-dotnet-approver
  • @open-telemetry/semconv-oracle-cloud-approvers
  • @open-telemetry/semconv-cicd-approvers
  • @open-telemetry/semconv-client-approvers
  • @open-telemetry/semconv-sdk-health-approvers

Things we're not getting to

TBD

(from the above list and beyond)

Please share your input

Could you please discuss it within the sub-SIG and come up with a few bullet points for these questions

• What do you expect to ship in 2026?
• Are there areas you're ready to stabilize in 2026?
• Are there things you need from other parts of the semconv community?

[ChrsMark]

K8s SIG is already focusing on stabilising a group of K8s and Container attributes: #3304.

This is in alignment with the Collector stability efforts: open-telemetry/opentelemetry-collector-contrib#44586

The wider stability plan is highlighted at #3119 but stabilising metrics will come probably after attributes are released as stable.

If/When the group has the time to focus on metrics too I see the following as the first items to tackle:

• [k8s stability] Evaluate k8s cpu utilization metrics #2768
• [k8s stability] Evaluate k8s memory utilization metrics #2777
• [k8s stability] Improve k8s memory metrics' descriptions #2853
• Ensure container.* metrics are populated in a unified way #2418
• [k8s] Stabilise k8s.pod.cpu.time, k8s.node.cpu.time, container.cpu.time metrics #3001

The above will open the path for stabilising some/all/most of the K8s metrics that are already defined.

/cc @open-telemetry/semconv-k8s-approvers

[jack-berg]

Declarative configuration for instrumentations as part of semconv @open-telemetry/configuration-approvers

This would be awesome. I would be happy to collaborate on this!

[osullivandonal]

DRAFT:

Systems SIG would like to work towards stabilizing the System namespace.

The stability plan can be found #1804, some progress is already being made.

Also the stability plan for the process namespace is underway, this can be found at #3041.

This aligns with the collector stability efforts: open-telemetry/opentelemetry-collector-contrib#44552

There is also an initative in collector-contrib to make the hostmetrics semconv compliant: open-telemetry/opentelemetry-collector-contrib#35325

/cc @open-telemetry/semconv-system-approvers

[luigiw]

Hello, is there a plan to stablize gen-ai semantic conventions in 2026?

[rrschulze]

As SIG OpenTelemetry on Mainframes, we plan to contribute to the definition of Semantic Conventions in the following areas:

• mainframe specific entities and related metrics (curated list) for transactions, job processing, databases, messaging and API
• infrastructure related entities and metrics for virtualization and Z HMC API
• server spans for z/OS systems software (MQ, CICS, IMS, Db2)

We'd like to ask for support from the SemConv community for representing virtualization concepts and from Entity SIG for the definition of relationships (in support of virtualization).

[ChrsMark]

@lmolkova moved #3330 (comment) out of draft since we (@open-telemetry/semconv-k8s-approvers group) confirmed that plan. Thank’s!

[adrielp]

The @open-telemetry/semconv-cicd-approvers are working on the following things in 2026 as part of Phase 2 that relate to Semantic Conventions:

1. Enhanced Signal Attribute Conventions: Establish additional attribute conventions for CI/CD-specific trace, metrics, and logs telemetry for the following namespaces and domains:

• build
• deployment
• issues
• incidents
• test
• pipeline

2. A prototype of semantic's around events that could be used to generate spans for long running traces

3. Adding a release candidate for CICD Semantics.

4. Unified nomenclature around workflows, pipelines, tasks, and jobs.

See our phase 2 list and project board for additional information.

[overbalance]

@open-telemetry/browser-maintainers are focusing on 4 main areas this year:

1. URLs We need clear, stable semantics around page URL vs. request URL, particularly disambiguation of url.full in fetch contexts and settled guidance on url.path, url.query, and url.template.
2. Sessions Considering maximum timeout, minimum length, and start/end timing
3. Timing Navigation Timing and Resource Timing are fully implemented across browsers and are among the most critical performance metrics we can surface
4. Logs-first browser telemetry We want to formally establish browser instrumentation as primarily Logs-based rather than Spans-based. Browser events (clicks, navigations, errors, performance entries) map much more naturally to the Log data model. Our goal is to publish semconv guidance that reflects this and aligns browser attributes under that model

[dyladan]

[Unconfirmed] Stabilize conventions:

• Feature-flags? Stabilize feature-flag semantic conventions #3409 @open-telemetry/semconv-feature-flag-approvers

Confirmed. Feature flags would like to stabilize this year