broadnot evaluated at main-2026-07-21legacy evidence: v0.23.0evidence: source code
Coverage
Metric identity coverage anchored by the complete v0.23.0 Prometheus inventory, with multi-version history where an admitted scope has tracked a metric across releases.
Strong across the complete v0.23.0 fixed-name inventory; version-local coverage outside v0.23.0 is limited to metrics with admitted history records and must be shown as partial rather than inferred for the remaining inventory.
Generated slice, not hand-authored: every claim here is produced by scripts/generate_metric_identity_claims.py from registration call sites in the pinned v0.23.0 snapshots, and is reproducible by re-running it. Instrument-kind coverage is complete over the closed inventory (45 of 45); label and bucket coverage is partial by construction, and the shortfalls are declared below rather than inferred. Seven instrument-kind claims predate the generator, are hand-authored, and are checked against the extraction rather than overwritten by it.
Coverage at vLLM main-2026-07-21
Schema has not evaluated this topic at the selected version.
0 claims0 history facts0/45 entities
Claims in this topic (0)
No claims at this version scope.
Known gaps
The corpus records no unit of measure for any v0.23.0 metric. vLLM's registration code has no structured unit field — `unit=` appears zero times in the pinned snapshots — so the only in-code signal is prose inside the `documentation=` argument, which states a unit for a minority of metrics and would require inference for the rest.
Schema.ai can state a metric's Prometheus instrument kind but cannot answer "what unit is this measured in" from structured corpus data. Where a registration docstring states a unit, it may appear in a claim statement as source-faithful prose, but it is not a queryable field.
Check: Admit a has_unit predicate only together with a rule for what grounds a unit — registration prose, the metrics design doc, or neither. Inferring from name suffixes such as `_seconds` is explicitly not grounded enough.
Five histogram metrics declare bucket boundaries computed at runtime via `build_1_2_5_buckets(max_model_len)` rather than as literal values; the corpus records no boundaries for them. Thirteen of the eighteen bucket declarations are literal and are recorded.
Schema.ai can list bucket boundaries for the thirteen histograms that declare them literally and must decline for the five computed ones. Asserting fixed boundaries for a set derived from a deployment's max_model_len would be false.
Check: Admit computed_from, or an equivalent way to state a derivation and its inputs, before recording any bucket fact for these five metrics.
Nine metrics build their label set at runtime rather than declaring it statically — from a constructor parameter, from `metrics_info.keys()`, or from instance attributes — so the corpus records no label names for them. Thirty-six of the forty-five have statically resolvable label sets.
Schema.ai can list label names for thirty-six metrics and must decline for the other nine, rather than guessing a label set from the common `model_name`/`engine` pattern.
Check: Resolving these requires reading construction sites outside the registration call. Decide whether cross-call-site resolution is in scope before recording labels for them.
Schema.ai