Feature usage observability matrix - wave 1 evidence, 2026-09-23

This matrix answers the field question by separating availability, configuration, production and use by people. L1 = available or entitled, L2 = configured objects, L3 = producing data, L4 = human query or open activity. Each ceiling below is the best signal reachable through the named source, not a claim that the current collector publishes it. The estate is discovered live. A row marked unverified must not be presented as measured coverage. Routes are read-only candidates only; this document grants no new action or scope.

Live method: the root enumerated grafanacloud_* names through the write-stack grafanacloud-usage datasource in two orgs (310 customer-side names, 171 development names, 325-name union), queried usage-insights with an exact instance_id guard on 50 customer and five development stacks, and checked existing stack-local GET routes on six customer and three development stacks. The stack sample was chosen from larger dashboard estates with working readers. It is not a random or estate-wide completeness claim. stack_id is present on 224 of the 310 customer metric names and 168 of the 171 development names. The exact name roster and classification are appended below. A metric’s presence proves it exists on the write datasource, not that every stack has a nonzero value.

What is trackable

• Today: per-stack and estate aggregate query surfaces where source is discriminating; dashboard opens; configured Grafana dashboards, public shares, alert rules and datasources; ingest and billing-side signals with a stated window; existing Assistant, Fleet and adaptive collector outputs. The current wave implements the bounded surface breakdown separately under GCI-0032.01 (Break down Pillar J query usage by Grafana surface from the data-request source field).
• After follow-on work and a scope decision: typed Synthetic Monitoring checks, SLO objects/source, IRM inventory, k6 runs, product app object counts, and additional live metric-based producing signals. Any new metric must justify a time series. Otherwise use a point-in-time view at zero series cost.
• Not visible from available sources: per-app use inside generic scenes; app landing-page visits without a query; personal investigations or user-scoped Assistant objects from a service account; a person using a product merely from its ingestion or billing signal; complete source code or sourcemap inventory without reading sensitive material.

Scope and cost decision

No reader role, policy, token or service account was changed. The product-plugin pairs listed in the rows above are candidates for one explicit decision task. New scopes reach customer configuration and sometimes identities, endpoints or secrets. Any change must keep basic role None, preserve datasources:query pins, use per-product action/scope pairs and independently verify output minimization. The initial follow-on ranking favours point-in-time views (zero emitted series) and panels over the existing usage datasource (zero collector series); a per-stack enum metric costs live stacks x enum size and needs a real trend or alert use case.

Primary route references

The route and role candidates above are grounded in current official product documentation. An undocumented plugin resources/* path remains a candidate even when a related role appears in the role catalogue.

• Grafana Cloud app plugin roles and app-plugin RBAC - named plugin readers and the difference between plugin access and product actions.
• SLO API and SLO RBAC - the documented GET and SLO reader permissions.
• Synthetic Monitoring API and Synthetic Monitoring roles - separate backend/token and checks-reader contract.
• k6 Cloud REST API, projects, test runs and k6 RBAC - projects/runs candidates and separate reader role.
• OnCall integrations API, IRM permissions and Incident API - inventory GET and Incident read-RPC distinctions.
• Kubernetes Monitoring access, Frontend Observability RBAC, Fleet API - product role and collector read boundaries.
• Library Element API, Reporting API, Git Sync - core configuration candidates.

Metric-name appendix

Each row below is one live-enumerated name from the union of the two write-stack datasources. C and D mean it appeared in the customer and development write datasource respectively; they are not per-stack nonzero evidence. stack_id records label presence in that datasource. Product and cue come from the name, not a vendor metric contract. rate is supported by explicit per-second or recorded-rate syntax. billing quantity has an unverified window except for the k6 VUh series noted above. counter candidate, gauge candidate and unknown explicitly require a metric-specific contract before use in a collector calculation.

Loop3 metric-semantics correction and re-enumeration, 2026-09-30

This section supersedes the older shape annotations above where they disagree. Historical customer measurements are historical only; this loop queried the staff development write datasource with fresh live inventory, explicit 24h range reads and an additional calendar-month diagnostic read. Five live staff stacks had samples; this is one org datasource, not five independent datasource probes. The fresh roster adds two names to the old 325-name union, making 327 entries. 26 have exact or partial vendor contracts; 309 still have unresolved normalization. Unknowns remain unknown. No AC1 completion is claimed.

The vendor OnCall table says: alert_groups_total | Gauge | Total count of alert groups for each integration by state (firing, acknowledged, resolved, silenced). It also defines response and resolution histograms over the last seven days. Source: https://grafana.com/docs/grafana-cloud/observe-and-act/respond-to-incidents/measure-and-improve/alert-group-insights/ . An increasing observed level does not turn this gauge into a cumulative counter. The existing collector reads its level; do not derive rate/increase or current-period activity from this evidence.

Resource-quota usage is a current dashboard/folder count, not monthly billable usage (https://grafana.com/docs/grafana-cloud/platform/pricing-and-usage/usage-limits/). Cost Management’s month-to-date hourly-refreshed gauge model does not establish every similarly named metric’s recording contract (https://grafana.com/docs/grafana-cloud/platform/pricing-and-usage/metrics/). Trace completeness/root-span ratios are 0-1; creation dates are milliseconds. Live metadata returned success with an empty data object, so it supplied no HELP/TYPE contracts. Absent staff billing data cannot validate monthly resets or prove zero customer use.

The remaining acceptance blocker is an authoritative vendor catalogue of HELP/TYPE, recording expressions/cadence, producer windows and billing-period/reset definitions for unresolved entries. Another unchanged name search or an instant query is not a discriminating next attempt. No role, scope or access policy was changed by this mapping.

Revised per-name semantics roster

Consumer diagnostic window: 24h, five-minute evaluation steps for every row. Producer window is separate. Semantic gauge inferences are labelled, not claimed as wire TYPE. Rows with unknowns were checked against current vendor product/usage/pricing docs, exact-name mentions, empty metadata, fresh names, explicit range data and the selected month window.

loop3 bounded frontend and IRM permission outcomes (2026-09-30)

A genuine Logs Drilldown 2.6.0 Chrome UI control, authenticated as an existing Admin service account, made 40 backend query POSTs and emitted 43 actual data-request events with generic source app. Exact-stack guarded usage-insights readback confirmed all 43, with no app-specific plugin or URL field and empty dashboard UIDs. Known app identity comes from the controlled frontend page, never datasource type. This proves frontend analytics transport, not human adoption or a working per-app discriminator. Generic app/scenes aggregation remains; no new per-app series. Backend-only source tags and the first browser run that blocked analytics are not a frontend before/after discriminator trial. Per-app use inside generic app/scenes remains unestablished by the tested schemas, not universally impossible. Shipped limits and pinned source are in docs/traps.md.

IRM integration counters work under exact plugin-access plus integrations:read pairs on a disposable basic-role-None identity and matched the Admin visible population (25). Alert-group stats remained denied. Safe counter projection is not safe permission breadth: captured archived backend grants list/retrieve/counters the same read action and serializes ingress URLs, while installed UI masking is cosmetic. Hosted backend redaction or usable ingress credentials under the read grant are unproven. No narrower permission is proven. All new IRM grants and collector implementation remain deferred; no known secret-bearing list or Incident read POST is approved. Disposable objects were removed by recorded IDs with GET404 verification.

Loop12 Agent reporting contract and exact-volume gap (2026-10-05 UTC)

GCI-0092.02 (org Assistant users and verified Agent Observability reporting) uses the existing write-stack grafanacloud-usage GET boundary: /api/datasources/proxy/uid/grafanacloud-usage/api/v1/query, with the existing exact datasource query pair. No wider datasource, product write or customer grant follows.

grafanacloud_agent_observability_instance_generation_items_per_second supports positive reported generation-rate observations over an explicit 30-day window, deduplicated by stack_id and left-joined to fresh live inventory. The collector’s maximum aggregate rate is not a cumulative generation count, licence/entitlement, sustained activity or present-time use. Missing members and empty/unavailable observations remain unknown, never zero. Empty inventory withholds the per-stack view rather than replacing the last good table with an empty estate.

Exact cumulative generation volume is unobservable from this verified rate family alone. The blocking contract at this route is the lack of a verified cumulative counter with reset/window semantics or an exact product aggregate GET read. Maximum rates must not be integrated using an assumed sample cadence. Keep cumulative volume absent until one of those read contracts is independently verified and approved.

The bounded staff-org witness queried this source on robk. Two positive reporting rows matched fresh Grafana Cloud inventory IDs in memory; this is not a claim of two distinct stacks. A robk-specific positive selector returned no series, which is not proof of zero activity. No sample or label values were retained. Evidence: /Users/rob/repos/grafana-cloud-org-insights/codex/loop12-evidence/R-agent-identity/result.json and /Users/rob/repos/grafana-cloud-org-insights/codex/loop12-evidence/R-agent-control/result.json.

Assistant org users use the deduplicated org billing-period gauge, separately labelled beside the sum of per-stack plugin rolling-30-day users. These populations and periods are not comparable: never subtract or divide the figures. An empty org gauge remains unavailable, not zero or evidence of metric nonexistence. The combined summary keeps its mechanically derived two-input dependency and last-good withholding; the Agent view publishes independently of Assistant when its own inputs are satisfied.

Loop12 feature-footprint boundaries (2026-10-05 UTC)

The historical matrix and metric appendix above are retained as dated discovery evidence, not present-tense proof of product use. The accepted view consumers distinguish configured objects, reported observations, unknown coverage and human adoption. No new collector product metric was added for these footprint rows.

Mobile Observability

An L2 configured-mobile-app footprint is observable through the optional/default-off Faro count source. Its exact read is GET /api/plugin-proxy/grafana-kowalski-app/api-proxy/api/v1/app, requiring HTTP 200 and the approved pairs grafana-kowalski-app.apps:read with empty scope and plugins.app:access@plugins:id:grafana-kowalski-app. The parser retains only total counts and the closed appType classes web, mobile and unknown, not app details. A configured mobile app does not establish mobile sessions, active mobile users, human adoption or traffic.

Mobile session/use remains unobservable under the established reader contracts: no separate Mobile-specific usage route or independently verified mobile session metric is approved here. Do not relabel aggregate Frontend Observability sessions as mobile or infer usage from plugin availability. Any further route must establish exact scope/method and output minimization before implementation; this document grants neither a new reader pair nor customer enablement. Source: /Users/rob/repos/grafana-cloud-org-insights/collector/sources/faro_apps.py.

Database, Adaptive and Application Observability

The exact staff usage-query observations for grafanacloud_instance_active_dbo11y_instance_count, grafanacloud_instance_active_dbo11y_series and grafanacloud_instance_active_dbo11y_stats were positive over 24 hours and their stack_id labels mapped to fresh inventory. Earlier discovery omitted the dbo11y abbreviation; metric nonexistence was not established. Provider metadata returned no HELP/type/unit definition. These are observable reporting markers, but a per-stack product-adoption/unit contract, configured database total, user activity and entitlement remain unverified. The adoption row is explicitly unknown, not zero. The blocking boundary is semantic qualification at the existing grafanacloud-usage query/metadata GET routes, not a grant to inspect database configuration or credentials. Evidence: /Users/rob/repos/grafana-cloud-org-insights/codex/loop12-evidence/R-db-marker/observations.json.

Adaptive Metrics and Logs rows measure qualified current configuration, not achieved savings or people. Segmented/unknown Adaptive Metrics discovery cannot establish whole-stack absence or savings; unknown inputs are excluded rather than coerced to zero. Adaptive Traces and Application Observability rows state their measured reporting populations and 24-hour windows: maximum received-byte reporting and maximum service-entity observations respectively are not policy enablement, saved currency, sustained traffic or human adoption. The cost summary keeps an unknown estate applied-rule total distinct from its qualified measured subset.

Current catalogue classification and reader boundaries

Enterprise datasource classification follows explicit current public catalogue status from GET https://grafana.com/api/plugins/{validated-plugin-id}: enterprise is classified positively, active negatively, and unavailable, missing or unqualified metadata remains unknown. Signature and publisher/name lists are not Enterprise classification. Current catalogue status is not proof of the installed version’s licensing or a deployment’s entitlement. Per-plugin configured-instance and stack rollups disclose measured inventory and classification coverage; unknown coverage does not become a healthy empty estate or an unqualified total.

Library panels are configured-object counts, not panel execution or views. The positive staff-only research witness established basic-None coverage using exact library.panels:read@folders:* plus baseline folders:read@folders:*, with a non-General-folder control and recorded-ID teardown. The default-off source checks those effective pairs through the same reader before counting exact-200, reconciled pages. Publication integration is a separate guarded acceptance; research, code or this matrix supplies no customer grant.

The preceding Agent section records the remaining exact cumulative-generation-volume gap. Assistant org billing-period figures remain separately labelled from rolling-30-day per-stack sums; the staff org query was empty at instant and explicit 30 days, meaning unavailable rather than zero or metric nonexistence. Its actual service-default lookback duration was not observed. No arithmetic comparison between those different populations/periods is supported.

Host counts and host-hour gap

Application service-entity observations are not a host count or host hours. Kubernetes/Infra producing telemetry, Fleet registrations and installed plugins likewise do not establish billable or active host hours. The historical grafanacloud_app_observability_* and grafanacloud_infra_observability_* names remain discovery evidence; an exact host-count/host-hour family with verified units, accumulation/window semantics and per-stack population was not established by the accepted sibling work. This part of the footprint request remains unobservable at the required fidelity, not zero. The current read boundary is the existing write-stack grafanacloud-usage query/metadata GET with datasources:query@datasources:uid:grafanacloud-usage; further semantic qualification and an authorised control are required before converting any reporting observation into host hours. Application/Kubernetes plugin resource paths and their exact reader pairs remain unverified and are not granted as an alternative.

The named robk Agent positive-generation control was not observed. Other positive 30-day generation-family rows matched fresh authorised staff inventory IDs, establishing observed reporting but not that named control or activity on robk. No zero-activity or complete-absence assertion follows; the exact-volume and named-control limitations remain open.

Billing-source contract reconciliation (2026-10-13)

The following updates reflect versioned source review retained in local evidence. They do not establish the deployed producer version, positive data availability, final datasource label schema or customer-specific pricing. Historical unknown entries remain a record of their original observation date; these qualified conclusions supersede the corresponding source-contract unknowns only.

Per-instance overage families can use different identifier domains before datasource processing. A field with a common name does not prove a common stack identity. Every showback line needs a witnessed mapping before a stack join. Missing attribution stays unavailable; only an explicit source zero is zero. Retained source research reduces semantic unknowns but does not complete live-enumeration acceptance or authorize any new scope, query surface or customer enablement.

Scope decisions after the historical route probes

The loop3 IRM paragraph above records its 2026-09-30 decision, not the current disposition. GCI-0041 (product read-scope decisions) subsequently approved the narrowly count-only IRM integration-counter route while accepting its documented permission breadth; GCI-0074 (configured IRM integration counters) and GCI-0087 (exact-200 IRM counter acceptance) are complete. This does not approve integration configuration lists, schedules, alert-group lists or an Incident POST route. The default-off IRM alert-group stats source has its separate bounded count contract; API-default-window and lower-bound counts must not be described as lifetime activity.

Default-off optional readers now include accepted configured-object sources for Faro apps, ML jobs, cloud accounts, PDC networks, reports, playlists and library panels. Their precise routes, reader pairs, exact-response conditions and privacy limits remain those in the repository instructions and capability document. Implementation or release is not customer enablement. GCI-0132 (customer library-panel and retention-policy rollout) still depends on accepted dev proof. These dispositions update the historical decision status only; they are not a fresh live visibility witness or a wider grant.

Customer feature-signal refresh (2026-10-14 UTC)

Read-only reads of the customer write stack’s existing shared usage datasource returned 325 grafanacloud_* names. Compared mechanically with the 327 distinct exact names in this document’s historical tables, 12 were new to those tables and 14 historical names were not rediscovered. The Agent Observability generation-rate name was already described in this document’s narrative, so 11 names are new to the document as a whole. These are dated roster differences across a customer lookup and a historical two-org union, not proof that a metric was created or removed. Empty or absent observations remain unknown.

Customer /api/v1/metadata returned status=success with empty data. No new HELP, TYPE, unit, reset or producer-window contract was obtained. The new Agent Observability generations_instance_usage and monetary-looking overage names do not by themselves prove cumulative generation volume, billing units, current-month semantics, additivity or currency. Do not integrate rates, use counter deltas or price these quantities without that contract.

Twelve separate metric queries took the maximum returned per-stack observation in a 24-hour lookback and were left-joined to a freshly fetched 316-stack control-plane inventory. All observed stack IDs matched that inventory. The maxima establish a positive reporting observation somewhere in the stated window, not continuous activity, a configured-object census, current-time use, human adoption or a producer-defined billing window. No customer identifiers or metric values were persisted from the per-stack query responses; only counts and response hashes were retained.

New-to-table names, each retaining unverified producer semantics:

• grafanacloud_agent_observability_generations_instance_overage
• grafanacloud_agent_observability_generations_instance_usage
• grafanacloud_agent_observability_instance_generation_items_per_second
• grafanacloud_grafana_pdc_datasource_request_duration_seconds_rate5m_p90
• grafanacloud_instance_query_equivalent_samples_read_per_second
• grafanacloud_org_agent_o11y_generations_overage
• grafanacloud_org_agent_o11y_generations_usage
• grafanacloud_org_agent_observability_generations_included_usage
• grafanacloud_org_ai_tokens_included_system_account_tokens
• grafanacloud_traces_instance_spans_more_than_30m_in_future_percent
• grafanacloud_traces_instance_spans_more_than_5m_in_future_percent
• grafanacloud_traces_instance_spans_more_than_60m_in_future_percent

The research changed no reader, scope, policy, datasource, credential or product object. PromQL sample selectors all carried __ignore_usage__=""; metadata-route tracking remains unproved. The current customer query paths are the already-established shared usage metadata/name/query GET surfaces. No new collector series, read-route family or customer enablement follows. The original exhaustive metric-normalization and exact plugin route/pair criteria remain unproved; this bounded refresh improves discovery and deployed availability evidence without claiming those criteria complete.