Define the OBI v1 telemetry contract

[MrAlias]

As part of v1.0, OBI needs an explicit decision about which emitted telemetry is stable.

Today, telemetry behavior exists in code, tests, and docs, but the v1 release needs a clear contract for what users can rely on across future releases.

Goal

Define and document the emitted telemetry surface that is part of the OBI v1 compatibility contract.

Scope

This should cover at least:

• which spans and metrics are part of the stable v1 surface
• which names, attributes, and units are stable
• what telemetry remains experimental or outside the v1 contract
• known caveats or limitations that must be documented for v1

This issue is broader than telemetry schema adoption alone.

Tasks

• Define which emitted telemetry is stable at v1
• Define which names, attributes, units, and semantics are part of the v1 contract
• Identify telemetry that remains experimental or outside the v1 contract
• Document known telemetry limitations that are acceptable for v1
• Align or explicitly relate this work to telemetry schema work
• Publish the resulting telemetry contract in the appropriate user-facing location(s)
• Link the published contract from the v1.0 release epic

Related

• Adopt [telemety schemas](https://opentelemetry.io/docs/specs/otel/schemas/) #1148

Acceptance Criteria

• The emitted telemetry that is stable at v1 is explicitly documented
• Experimental or out-of-contract telemetry is clearly distinguished
• Known telemetry caveats for v1 are documented
• Maintainers agree this defines the telemetry compatibility baseline for v1.0

[NimrodAvni78]

@MrAlias I think i had a couple of questions about this in the Weaver integration PR i did.

wanted to ask about this:

1. Do we need to redeclare the telemetry we expose if it is already defined as part of the semconv schema, or should we just export the semconv schema version we export?
2. As for custom data (internal metrics, span metrics, service graph metrics, netolly / statsolly) we probably need to define custom a schema of our own right?
3. Not sure if there is a better way to validate this then using integration tests with weaver, since we try to test all outputed telemetry with integration tests, maybe we need other dedicated tests for it not sure