Thanks for taking the time. Some context on where I'm coming from:
I've standardized on OpenTelemetry. My stack is Java/Quarkus + LangChain4j, and Quarkus LangChain4j already emits `gen_ai.*` spans natively. Everything flows through an OTel Collector, and I want the backend to be a choice, not a re-instrumentation decision. So my core question is: **what would I lose if I only ever emitted OTel GenAI conventions and pointed them at Phoenix/AX?** A concrete list would be the most useful answer.
More specific questions:
1. Coexistence contract
If a span carries both `gen_ai.*` and OpenInference attributes, which is authoritative, in Phoenix and in AX? (The AX docs say OpenInference wins. Is that the same in Phoenix OSS?)
Is dual emission a supported, documented pattern, or a transitional hack?
Which OpenInference fields does Phoenix actually *require* for full rendering, evals, and datasets, versus optional enrichment?
2. Phoenix `gen_ai.*` ingestion fidelity
The 15.10 conversion table maps `gen_ai.usage.*` to prompt/completion counts only. Are cache read/write, reasoning, and per-modality tokens mapped?
It keys provider off `gen_ai.system`. Is `gen_ai.provider.name` handled? (`gen_ai.system` is deprecated upstream.)
Does Phoenix infer span kind from `gen_ai.operation.name` like AX does, including `retrieval`, `execute_tool`, `invoke_agent`, `invoke_workflow`, and `plan`? The table shows operation name landing in `llm.invocation_parameters`.
Are `gen_ai.evaluation.result` events ingested as annotations?
How do you track spec churn? For example, the `cache_creation` vs `cache_write` naming drift in the current GenAI docs.
3. Emitting `gen_ai.*` from OpenInference (#2817, #2983)
What's the status and timeline for the bidirectional layer / "emit GenAI format" switch?
Will it cover Java? If I use `openinference-instrumentation-langchain4j`, can I get conformant `gen_ai.*` out of it?
Would you consider adding OpenInference Java instrumentors to the OTel GenAI conformance dashboard (Weaver live-check)? Today only Python and JS appear.
4. Java specifics
Quarkus LangChain4j already creates spans for AI service methods, chat model calls, tools, and guardrails. Does the OpenInference LangChain4j instrumentor create *additional* spans alongside those, or can it enrich the existing ones? What's the recommended setup to avoid duplicates?
Which Maven coordinates are canonical, `com.arize:*` (0.1.x) or `io.openinference:*` (1.0.0)? The docs show both.
The LangChain4j instrumentor is 0.1.x. How does that square with "stable conventions"? Is the stability guarantee about the spec, the SDKs, or both?
5. Gaps where you're ahead of OTel, and upstreaming
RAG: OTel retrieval docs carry only id + score, with no reranker operation. Are you proposing `document.content`/`metadata` and a reranker operation upstream, or keeping those OpenInference-only?
Are `CHAIN`, `GUARDRAIL`, `PROMPT`, and `EVALUATOR` span kinds, the `llm.cost.*` tree, and the reasoning-replay fields (signatures, encrypted content) being proposed to the GenAI SIG? Is anyone from Arize active there?
If OTel GenAI goes stable with different shapes for these, what's the migration story for existing OpenInference data and dashboards?
6. Privacy defaults
OpenInference captures content unless `OPENINFERENCE_HIDE_*` is set; OTel GenAI makes content opt-in. Would you consider an opt-in default, or a mode that follows OTel's content-capture guidance, including the external-storage pattern?
7. Governance
How are spec changes proposed and decided, and is there a versioned changelog for the spec itself, separate from the SDKs?
Beyond Phoenix and AX, which backends consume OpenInference natively? Dynatrace, for example, documents converting OpenInference *to* `gen_ai.*`.
Happy to help test any of this against Quarkus LangChain4j.
