genai-conformance
Run, interpret, and iterate on the OpenInference GenAI conformance MVP at python/openinference-instrumentation/scripts/conformance/. Use when the user mentions GenAI conformance, OTel GenAI semantic conventions, Weaver registry live-check, the dual-write conversion (`_genai_conversion.py`, `enable_genai_semconv`), `gen_ai.*` attribute coverage, or asks to add new providers / scenarios to the conformance harness.
pinned to #3f8994bupdated 3 weeks ago
Ask your AI client: “install skills/genai-conformance”.
Requires the metahub MCP server installed in your client. Set up MCP.
mh install skills/genai-conformancemetahub onboarded this repo on the author's behalf.
If you own github.com/Arize-ai/openinference on GitHub, claim the listing to take over publishing. Your claim preserves the existing eval history and badges; only the curator label is replaced with verified-publisher on your next publish.
Stars
1,078
Last commit
3 weeks ago
Latest release
published
- #aiops
- #gemini
- #hacktoberfest
- #haystack
- #langchain
- #langraph
- #llamaindex
- #llmops
- #llms
- #mcp
- #openai
- #openai-agents
- #opentelemetry
- #pydantic-ai
- #smolagents
- #telemetry
- #tracing
- #vercel
- #vertex
About this skill
Pulled from SKILL.md at publish time.
The repo ships a self-contained conformance harness at [python/openinference-instrumentation/scripts/conformance/](../../python/openinference-instrumentation/scripts/conformance/) that exercises OpenInference instrumentors against deterministic mock provider APIs, exports OTLP traces to `weaver registry live-check`, and prints a console summary of registry attributes seen / missing / advice-level counts. It validates the **dual-write** logic in [_genai_conversion.py](../../python/openinference-instrumentation/src/openinference/instrumentation/_genai_conversion.py) that translates OpenInfere…
Evaluation report
WarningsAutomated checks the publisher passed at publish time — structure, docs, safety, and whether the artifact behaves as claimed.3f8994b· 3 weeks ago
Kind-specific
31Skill: SKILL.md present
found at .claude/skills/genai-conformance/SKILL.md · frontmatter source: SKILL.md
Skill: body content present
1,290 words · 10,977 chars · 7 sections · 2 code blocks
Skill: triggers declaredwarn
No `trigger` phrases in SKILL.md frontmatter
Add `trigger:` lines so Claude knows when to activate this skill — e.g. `when building MCP servers` or `for diagram creation`.
Skill: allowed-tools scope
no allowed-tools restriction (Claude may use anything)
Release history
1- releasecurrent3f8994bwarn3 weeks ago
Contents
The repo ships a self-contained conformance harness at python/openinference-instrumentation/scripts/conformance/ that exercises OpenInference instrumentors against deterministic mock provider APIs, exports OTLP traces to weaver registry live-check, and prints a console summary of registry attributes seen / missing / advice-level counts. It validates the dual-write logic in _genai_conversion.py that translates OpenInference's native attributes (llm.*, input.*, output.*, openinference.*) into the OTel GenAI semantic conventions (gen_ai.*).
When to Use
- User asks to run the conformance harness, "test conformance", or "run weaver".
- User asks to maximize / improve
gen_ai.*registry coverage. - User wants to extend the dual-write conversion in
_genai_conversion.py. - User wants to add a new provider, a new test scenario, or a new mock endpoint.
- User mentions specific
gen_ai.*attributes (response.id, system_instructions, tool.call., retrieval., etc.) and whether they're being emitted.
Layout
scripts/conformance/
├── run.py # orchestrator (PEP 723, stdlib only)
├── mock_server.py # Flask mock with all providers' endpoints
├── anthropic_conformance.py # PEP 723 + editable [tool.uv.sources]
├── openai_conformance.py # PEP 723 + editable [tool.uv.sources]
├── google_genai_conformance.py # PEP 723 + editable [tool.uv.sources]
├── README.md
└── results/ # gitignored Weaver output
Each provider script declares its deps as PEP 723 inline metadata and pins the local OpenInference packages via [tool.uv.sources.<pkg>] blocks (multi-section dotted-key form — single-line inline tables exceed ruff's 100-char limit). run.py invokes everything via uv run. Filenames avoid the bare provider name (openai.py, anthropic.py) because that would shadow the SDK package on sys.path[0].
run.py lives in PROVIDER_SCRIPTS — a tuple iterated for both prewarm and execution. To add a provider, append to PROVIDER_SCRIPTS and add the corresponding <provider>_conformance.py and any new mock endpoints.
Running
uv run python/openinference-instrumentation/scripts/conformance/run.py
First run downloads pinned weaver v0.22.1 and semantic-conventions v1.40.0 to ~/.cache/oi-conformance/; subsequent runs are fast. uv caches each provider script's env by PEP 723 metadata hash.
Interpreting the summary
- Registry attributes seen —
gen_ai.*(and a fewservice.*/telemetry.sdk.*) attrs the run emitted, with sample counts. - Non-registry attributes seen — OpenInference's native vocabulary. These show up as Weaver
missing_attributeviolations by design — they aren't (and shouldn't be) in the OTel registry. - Missing registry attributes (
gen_ai.*) — registry attrs the run did not emit. Categorize each one:- Real dual-write gap — provider API has the data, instrumentor captures it as an OI attr, but
_genai_conversion.pydoesn't map it. Fixable in conversion. - Test scenario gap — conversion handles it, but the test doesn't exercise the relevant scenario (e.g.
gen_ai.tool.call.*need a TOOL span;gen_ai.embeddings.*need an EMBEDDING span). Fixable in<provider>_conformance.py. - Mock data gap — instrumentor would capture it if the response included it (e.g.
gen_ai.usage.cache_read.input_tokensrequirescache_read_input_tokensin the mock's usage block). Fixable in mock_server.py. - Provider doesn't support it — e.g. Anthropic has no
frequency_penalty. Document and skip. - Application-level / not auto-emittable —
gen_ai.agent.*,gen_ai.evaluation.*,gen_ai.prompt.name,gen_ai.data_source.id. Require explicit user attribution; out of scope for SDK instrumentation. - Metric-only —
gen_ai.token.typelives ongen_ai.client.token.usagemetric, not spans.
- Real dual-write gap — provider API has the data, instrumentor captures it as an OI attr, but
- Advice levels —
violationcounts are predominantlymissing_attributefor the OI native vocab (expected);improvementcounts arenot_stablewarnings for development-stagegen_ai.*attrs (also expected). The dual-write itself is well-formed — Weaver does not flag type/shape/value errors on the emittedgen_ai.*attrs.
Iterating to maximize coverage
For category 1 (dual-write gap):
- Inspect
results/live_check.jsonto see exactly what OI attributes the instrumentor emitted (look for the relevant span'sattributesarray). - Decide where to extend
_genai_conversion.py(get_genai_request_attributes,get_genai_response_attributes, etc.). - Always add a unit test in test_genai.py for the new path. The existing tests cover the major span kinds; mirror that style.
- Re-run the conformance harness. Verify the missing list shrinks and no existing
gen_ai.*attribute regressed.
For category 2 (test scenario gap):
- Use
OITracer(trace.get_tracer(__name__), TraceConfig(enable_genai_semconv=True))to manually emit non-LLM spans (TOOL, RETRIEVER, EMBEDDING, AGENT) inside a provider script. The Anthropic script already does this for TOOL / RETRIEVER / EMBEDDING — copy the pattern.
For category 3 (mock data gap):
- Mock responses are simple dicts at the top of
mock_server.py. The Anthropic mock already returnscache_creation_input_tokens/cache_read_input_tokens; the OpenAI mock returnsprompt_tokens_details.cached_tokens. Add fields the SDK will surface and the OI instrumentor will turn intoLLM_TOKEN_COUNT_PROMPT_DETAILS_CACHE_*.
Bumping the semconv version
The harness pins SEMCONV_VERSION (currently v1.41.1) and WEAVER_VERSION (currently v0.23.0) in run.py. When OTel cuts a new semconv release, walk this checklist:
- Check for a newer Weaver release too — always run
gh release list --repo open-telemetry/weaver --limit 5alongside the semconv check. Weaver and the registry version independently; the harness depends on both. BumpWEAVER_VERSIONwhenever a newer release exists, and skim its notes forlive-check-relevant fixes. - Bump the constants in run.py:
SEMCONV_VERSIONandWEAVER_VERSIONto the latest releases. - Run the harness once (
uv run python/openinference-instrumentation/scripts/conformance/run.py) so it downloads the new registry into~/.cache/oi-conformance/semconv/<new-version>/. - Refresh the vendored JSON schemas at tests/fixtures/genai_schemas/ from
~/.cache/oi-conformance/semconv/<new-version>/docs/gen-ai/gen-ai-{input,output}-messages.json. - Run unit tests (
pytest tests/test_genai.py). The_load_json_attributevalidator runs the new schemas against every emitted message payload — any breaking shape change surfaces here. - Skim the semconv changelog for these specific risks (each one usually requires a code change in
_genai_conversion.py):- New required fields on
ChatMessage/OutputMessageparts (TextPart,ToolCallRequestPart, etc.) → builder functions need to populate them. - New
Roleenum values →_normalize_message_rolemay need a mapping. - New
FinishReasonenum values →_normalize_finish_reasonmay need a mapping. - Added
gen_ai.*registry attrs → opportunity for new dual-write mappings; re-run the harness and look at the "Missing registry attributes" summary. - Removed / renamed
gen_ai.*attrs → drop from_genai_attributes.pyand stop emitting in_genai_conversion.py.
- New required fields on
- Refresh inline version refs: the semconv-version mentions in test_genai.py (schema-source comment), README.md (caveats section, includes Weaver version too), and _genai_conversion.py (the encoding comment inside
get_genai_message_attributes). - Re-run the conformance harness end-to-end; verify no
gen_ai.*attribute regressed and no genuine shape errors appear inresults/live_check.json(advice withid != "missing_attribute").
Gotchas
- PEP 723 inline-table line length:
[tool.uv.sources.<pkg>] { path = "...", editable = true }on one line easily exceeds 100 chars and trips ruff E501. Use the multi-section form ([tool.uv.sources.<pkg>]\npath = "..."\neditable = true). - The conformance dir is excluded from package-level checks:
pyproject.tomlexcludesscripts/*from mypy andscriptsfrom pytest'snorecursedirs. ruff still lints it. Don't add Python imports that mypy/pytest can't resolve in the lint env (e.g. provider SDKs) outside this directory. - Weaver inactivity timeout is 90s. First-run uv installs of OpenTelemetry/OpenAI/Google SDKs can take a while —
run.pyprewarms each provider env via--prewarmearly-exit before starting Weaver. If you add a new provider script, give it a--prewarmearly-exit too. - Single mock server for all providers: one Flask app handles
/v1/messages(Anthropic),/v1/chat/completions+/v1/embeddings+/v1/responses(OpenAI), and/v1beta/models/<path:model>(Google). Each endpoint discriminates between text and tool variants by checkingbody.get("tools"). - Editable installs are mandatory: PyPI versions of
openinference-instrumentationand the per-provider packages won't have in-progress dual-write changes. The[tool.uv.sources]blocks in each<provider>_conformance.pypin the local repo paths. - System messages stay in
gen_ai.input.messages. The dual-write does not emitgen_ai.system_instructions; system instructions are assumed to flow through as a system-role entry inLLM_INPUT_MESSAGES. Thegen_ai.input.messagesJSON schema explicitly admits"system"as a valid role. tool_call(singular) finish_reason — the conversion normalizes bothtool_calls(OpenAI plural) andfunction_call(legacy) to"tool_call". The OTel registry doesn't constrain values forgen_ai.response.finish_reasons, but OTel's conventional value is pluraltool_calls. If you change the normalization target, update the asserting tests intest_genai.pytoo.- Don't conflate violations with shape errors: the headline "violation: N" counts
missing_attributeadvice on OI native attrs (expected) plus any genuine shape mismatches ongen_ai.*attrs (real bugs). To find genuine shape errors, parseresults/live_check.jsonand look at advice withid != "missing_attribute".
Reviews
No reviews yet. Be the first.
Related
Gpt Researcher
An autonomous agent that conducts deep research on any data using any LLM providers
Verification Before Completion
Evidence before assertions, always
Writing Plans
Turn specs into phased implementation plans
mh install skills/genai-conformance