From 06f44e65407689169bc22188b6b8aa34f3298274 Mon Sep 17 00:00:00 2001
From: Pratik Mankawde <3397372+pratikmankawde@users.noreply.github.com>
Date: Wed, 5 Aug 2026 15:59:33 +0100
Subject: [PATCH] docs(telemetry): use snake_case tuning/resource namespaces in
 getobject bucket notes

develop renamed CamelCase namespaces to snake_case (#7933): Tuning:: ->
tuning:: and Resource:: -> resource::.
---
 OpenTelemetryPlan/09-data-collection-reference.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/OpenTelemetryPlan/09-data-collection-reference.md b/OpenTelemetryPlan/09-data-collection-reference.md
index ffaa9d307d..e3b8af958b 100644
--- a/OpenTelemetryPlan/09-data-collection-reference.md
+++ b/OpenTelemetryPlan/09-data-collection-reference.md
@@ -1361,7 +1361,7 @@ macros, not as `MetricsRegistry` members: the two rejection counters in
 **Per request, not per object.** `getobject_lookup_us` times the whole fetch
 loop once, and `getobject_lookups_total` adds the batch hit and miss totals in
 two calls. Incrementing per object on a loop bounded by
-`Tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
+`tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
 information the batch totals do not already carry.
 
 **All three histograms need an explicit bucket view.** The SDK's default
@@ -1387,7 +1387,7 @@ observation in one or two buckets and make the distribution unreadable.
 `addHistogramView()` exists to take caller-supplied boundaries for exactly this
 case.
 
-- **Counts** run 1 to `Tuning::kHardMaxReplyNodes` (12288). The low end is
+- **Counts** run 1 to `tuning::kHardMaxReplyNodes` (12288). The low end is
   fine-grained because the honest sync path asks for at most 8 objects, so the
   interesting distinction is between a normal request and a large one. The upper
   bounds follow the charge size bands — `kBandSmallMax` (64) and
@@ -1395,7 +1395,7 @@ case.
   with each price change.
 - **Charges** run 0 to roughly 99k for a full-size all-miss request. Two of the
   boundaries are the resource thresholds that decide a peer's fate:
-  `Resource::kWarningThreshold` (5000) and `Resource::kDropThreshold` (25000),
+  `resource::kWarningThreshold` (5000) and `resource::kDropThreshold` (25000),
   both in `include/xrpl/resource/detail/Tuning.h`. Placing bucket edges exactly
   there lets a panel read off how close real charges run to a warning or a drop,
   rather than interpolating across an edge.