Description
The scoping study that the rest of SKT-0007 is built from. Produces a per-kind verdict across all 45 catalog packages: does this thing, in the real world, emit OTLP metrics from an instrumented process or collector pipeline, or does it only ever exist as a Prometheus scrape target that Alloy or a cloud scraper converts?
This matters because the repository contract forbids inventing telemetry. Giving, say, a kube-state-metrics-derived family an OTLP-native lane would fabricate a shape no real deployment produces. Conversely an application runtime, a service mesh sidecar, or anything shipping through an OTel collector pipeline has a genuine OTLP form that synthkit currently cannot represent.
Verdicts must be evidence-backed — current vendor documentation, a live capture, or the SKT-0006 reality corpus — not inferred from the construct name. Where evidence is unavailable, the kind is recorded as unresolved with a cantfind.md PENDING rather than being guessed either way.
The output is durable: a recorded per-kind verdict plus the implementation waves that follow from it, created as sibling subtasks.
Acceptance Criteria
- #1 Every one of the catalog kinds carries a recorded verdict: has a real OTel-native metric form, is Prometheus-scrape-only, or unresolved
- #2 Each verdict cites its evidence (vendor documentation, live capture, or reality corpus entry) with a date
- #3 Unresolved kinds produce cantfind.md PENDING entries rather than a guessed verdict
- #4 The in-scope set is prioritised, with the base blueprint surface identified as the first implementation wave
- #5 Implementation waves are created as sibling subtasks under SKT-0007 reflecting that priority
- #6 The verdict record lives where a future contributor adding a construct will find it
Definition of Done
- #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
- #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
- #3 DRY_RUN=true go run ./cmd/synthkit -once -dump — inventory diffed against signals/
Implementation Notes
DELIVERED 2026-08-27 (lane L5). Verdict record: signals/otlp-native-verdicts.md, indexed in SIGNALS.md by the wiring pass.
Re-measured baseline (not trusted from the tracker): 44 packages declare core.Metrics, 18 Logs, 3 Traces, 2 RUM, and exactly ONE declares core.OTLPMetrics (web_service). core.OTLPLogs exists as a class with zero declarers.
45 verdicts: 20 OTEL-NATIVE, 24 SCRAPE-ONLY (must never gain an OTLP lane), 1 UNRESOLVED (portkey_gateway, cantfind SK-84).
The decision rule, which is the reusable part: a kind has a real OTel-native form only when a real producer emits OTLP metrics under names that are NOT the Prometheus exposition names — an instrumented process, an agent with an OTLP exporter, a proxy with an OpenTelemetry stats sink, or a collector receiver that talks to the upstream API directly. A kind is scrape-only when the only route to OTLP is prometheusreceiver wrapping a /metrics scrape, which preserves the names exactly and is a transport change rather than an OTel-native form.
THE LOAD-BEARING CONSEQUENCE, now written into the verdict file: an OTEL-NATIVE verdict is NOT permission to re-emit a construct existing promrw families over OTLP. For CloudWatch, Azure, GCP, Kubernetes and host the OTel-native form is a DIFFERENT metric namespace — 13 of the 20 are tagged “different namespace” — so a lane there means sourcing a second name catalogue with its own provenance.
Two verdicts worth remembering because they are counter-intuitive:
- ksm_ingress is the cleanest proof the study was worth doing. By name it looks like part of the k8s cluster surface, which came back OTEL-NATIVE — but k8sclusterreceiver metadata defines no ingress metric at all. A blanket port would have fabricated kube_ingress_* in an OTLP envelope no deployment on earth produces.
- dbo11y_mysql/dbo11y_postgres are SCRAPE-ONLY and will be got wrong later. postgresqlreceiver and mysqlreceiver do produce genuine OTel-native postgresql./mysql. metrics, and it is tempting to read that as “dbo11y has an OTel-native form”. It does not: those are a DIFFERENT PRODUCT SURFACE belonging in a new construct, never an OTLP lane on the Grafana-product-coined dbo11y families.
Seven follow-on waves created as SKT-0007.03 through .09, ordered so the archtest guard (.03) lands first — it makes the study binding rather than advisory, and it fails both on a scrape-only kind gaining a lane and on a newly registered kind having no verdict at all.
cantfind SK-84 through SK-90 appended (the lane proposed these IDs and they did not collide).
Final Summary
All 45 catalog kinds carry a recorded, evidence-cited verdict in signals/otlp-native-verdicts.md: 20 OTEL-NATIVE, 24 SCRAPE-ONLY that must never gain an OTLP lane, 1 UNRESOLVED with a cantfind PENDING.
The reusable output is the decision rule, not just the table: a kind has a real OTel-native form only when some real producer emits OTLP metrics under names that are NOT the Prometheus exposition names. Where the only route to OTLP is a prometheusreceiver wrapping a /metrics scrape, the names are preserved exactly — that is a transport change, not an OTel-native form.
The load-bearing consequence is written into the verdict file: an OTEL-NATIVE verdict is NOT permission to re-emit a construct existing promrw families in an OTLP envelope. For CloudWatch, Azure, GCP, Kubernetes and host the OTel form is a DIFFERENT metric namespace — 13 of the 20 are tagged so — meaning a lane there requires sourcing a second name catalogue with its own provenance.
Two verdicts worth remembering because they are counter-intuitive. ksm_ingress looks like part of the k8s surface, which came back OTEL-NATIVE, but k8sclusterreceiver defines no ingress metric at all — a blanket port would have fabricated a shape no deployment produces. And dbo11y stays SCRAPE-ONLY despite postgresqlreceiver/mysqlreceiver producing genuine OTel-native metrics: those are a different PRODUCT SURFACE belonging in a new construct, never an OTLP lane on the Grafana-product-coined families.
Seven follow-on waves created as SKT-0007.03 through .09, ordered so the archtest guard lands first — it is what makes this study binding rather than advisory, failing both on a scrape-only kind gaining a lane and on a newly registered kind having no verdict at all. cantfind SK-84 through SK-90 filed. Verified: go build ./… clean, table parses to 45 rows with the stated split, hygiene guards clean.