How should Appendix D stay aligned with OTel semconv releases? #449

Context

Appendix D maps OpenFeature telemetry onto OTel feature flag event records. Those
conventions are still moving: repeated renames between v1.32 and v1.34, and v1.40.0
deprecated error.message in favour of feature_flag.error.message (release notes).

Appendix D is currently behind on that last one — it still maps errors to
error.message (Conditionally Required), and its History table stops at v1.34.0, so
the deprecation and its replacement are both unrecorded.

The rename itself is mechanical and uncontroversial. What's unclear is the policy:
nothing in the repo says which OTel version Appendix D targets, so a reader can't tell
whether that's a deliberate pin or just drift.

Question

How do we want to keep Appendix D aligned?

1. Which version do we target? Latest tagged semconv release, main, or a
   deliberate pin we state explicitly?
2. How do we notice drift? Manual catch-up, as today (last done in #306 / #324), or something automated against the semconv registry?
3. What counts as "aligned"? Attribute names only, or requirement levels too? The
   error.message case is a good test: OTel marks feature_flag.error.message as
   Recommended with the condition "and error.type does not sufficiently describe
   the error", while Appendix D says Conditionally Required. The name is easy to
   agree on; the level is a judgement call, and Appendix D being more prescriptive
   than OTel may well be intentional.

Why it matters now

Whatever we pick sets the expectation for SDK authors, who currently have to choose
between Appendix D and upstream when the two disagree — js-sdk, go-sdk and
ruby-sdk emit error.message, while dotnet-sdk core defines both keys.

Related: #373 proposes a cross-SDK OTel contract harness, which is the SDK-side version of this question.

Happy to raise the rename as a separate PR once we've settled on a policy.

Written in collaboration with AI — Xirp Agent (deepseek-v4-1-flash).