@@ -274,6 +274,8 @@ https://mermaid.js.org/config/directives.html
 
 - Add a "Preview Special" item to our Download CTA that lets the user know the Deep Dive content can be previewed in HTML format, and offer a switch to it.
 
+- How can we handle footnotes in List components? src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/pdf.mdx line 80
+
 ### This file was badly mangled during refactoring, need to compare against original:
 
 src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx
 
@@ -294,9 +294,7 @@ The core visualizations:
 
 <Diagram
   title="Consumer migration status breakdown for deprecation tracking"
-  description={
-    `Pie chart showing the migration status of consumers using a deprecated API. The largest slice is Migrated at 45 percent, indicating that nearly half of consumers have fully moved to the new version. The next largest slice is In Progress at 25 percent, representing consumers actively using both the old and new APIs during migration. Not Started accounts for 20 percent, showing a significant minority still using only the deprecated API. The smallest slice is Blocked at 10 percent, representing consumers who have not migrated because they need additional support, approvals, or technical help. Overall, the chart shows that most consumers have either completed migration or started it, but 30 percent still require intervention before deprecation can be completed safely.`
-  }
+  description="Pie chart showing the migration status of consumers using a deprecated API. The largest slice is Migrated at 45 percent, indicating that nearly half of consumers have fully moved to the new version. The next largest slice is In Progress at 25 percent, representing consumers actively using both the old and new APIs during migration. Not Started accounts for 20 percent, showing a significant minority still using only the deprecated API. The smallest slice is Blocked at 10 percent, representing consumers who have not migrated because they need additional support, approvals, or technical help. Overall, the chart shows that most consumers have either completed migration or started it, but 30 percent still require intervention before deprecation can be completed safely."
 >
 ```mermaid
 pie
 
@@ -50,9 +50,7 @@ The fundamental difference is scope: every request passes through the gateway. W
 <Diagram
   src={apiGatewayDiagram}
   title="API gateway as the central observation point for all traffic"
-  description={
-    `Flowchart showing the API gateway positioned between a consumer and multiple downstream components. A Consumer sends requests to the API Gateway. From the gateway, traffic can go to an Auth Service, a Rate Limiter, Backend A, and Backend B. A grouped region labeled Gateway Boundary contains the API Gateway, Auth Service, and Rate Limiter, emphasizing that these components sit at the control point through which all requests pass. The diagram shows why the gateway is a unique observation point: it sees every request before it reaches the backend services and can record both control-plane decisions, such as authentication and rate limiting, and routing decisions to different backends.`
-  }
+  description="Flowchart showing the API gateway positioned between a consumer and multiple downstream components. A Consumer sends requests to the API Gateway. From the gateway, traffic can go to an Auth Service, a Rate Limiter, Backend A, and Backend B. A grouped region labeled Gateway Boundary contains the API Gateway, Auth Service, and Rate Limiter, emphasizing that these components sit at the control point through which all requests pass. The diagram shows why the gateway is a unique observation point: it sees every request before it reaches the backend services and can record both control-plane decisions, such as authentication and rate limiting, and routing decisions to different backends."
 />
 
 The gateway also adds its own latency that frequently gets blamed on backends. Authentication checks, rate limit lookups, request transformation, response transformation, TLS termination — these all take time. When users complain about slow APIs, the default assumption is that backends are slow, but I have seen gateway overhead account for 200ms+ on requests where the backend responded in 50ms.
@@ -169,9 +167,7 @@ The single most useful gateway metric is not total request duration — it is th
 <Diagram
   src={requestLifecycleDiagram}
   title="Request lifecycle showing gateway vs. backend latency components"
-  description={
-  `Flowchart showing a request moving left to right through ten stages. The sequence begins with Request Received, then passes through TLS Handshake, Request Parse, Auth Check, Rate Limit Check, Route Match, Upstream Request, Backend Processing, Response Transform, and Response Sent. Two grouped regions separate where time is spent. A Gateway Time group contains TLS Handshake, Request Parse, Auth Check, Rate Limit Check, Route Match, Upstream Request, Response Transform, and Response Sent, representing work performed or coordinated by the gateway. A separate Backend Time group contains only Backend Processing, representing the actual time spent inside the upstream service. The diagram emphasizes that total latency is a combination of gateway-side work and backend execution, and that debugging requires measuring those components separately.`
-  }
+  description="Flowchart showing a request moving left to right through ten stages. The sequence begins with Request Received, then passes through TLS Handshake, Request Parse, Auth Check, Rate Limit Check, Route Match, Upstream Request, Backend Processing, Response Transform, and Response Sent. Two grouped regions separate where time is spent. A Gateway Time group contains TLS Handshake, Request Parse, Auth Check, Rate Limit Check, Route Match, Upstream Request, Response Transform, and Response Sent, representing work performed or coordinated by the gateway. A separate Backend Time group contains only Backend Processing, representing the actual time spent inside the upstream service. The diagram emphasizes that total latency is a combination of gateway-side work and backend execution, and that debugging requires measuring those components separately."
 />
 
 At minimum, instrument these separately:
@@ -357,9 +353,7 @@ The gateway creates its own span as a child of the incoming span, then creates n
 <Diagram
   src={traceContextDiagram}
   title="Trace context propagation creating connected spans across gateway boundary"
-  description={
-    `Sequence diagram showing how a single distributed trace continues across a client, gateway, auth service, and backend. The client sends a request to the gateway with a traceparent header containing trace ID abc and span ID 123. The gateway creates its own span as a child of that incoming request. The gateway then calls the auth service with the same trace ID but a new span ID 456, receives the auth response, and forwards the request to the backend with the same trace ID and another new span ID 789. The backend returns a response to the gateway, which then responds to the client. A note across the full diagram states that all spans share the same trace ID abc, emphasizing that the trace remains connected even though each hop creates a new span.`
-  }
+  description="Sequence diagram showing how a single distributed trace continues across a client, gateway, auth service, and backend. The client sends a request to the gateway with a traceparent header containing trace ID abc and span ID 123. The gateway creates its own span as a child of that incoming request. The gateway then calls the auth service with the same trace ID but a new span ID 456, receives the auth response, and forwards the request to the backend with the same trace ID and another new span ID 789. The backend returns a response to the gateway, which then responds to the client. A note across the full diagram states that all spans share the same trace ID abc, emphasizing that the trace remains connected even though each hop creates a new span."
 />
 
 Common propagation failures I have seen:
@@ -774,9 +768,7 @@ The layout matters. Arrange panels so that related information is grouped and th
 <Diagram
   src={gatewayDashboardDiagram}
   title="Gateway dashboard layout with logical panel grouping"
-  description={
-  `Top-to-bottom flowchart showing a dashboard organized into four rows. The first row, labeled Row 1 Health Overview, contains Request Rate, Error Rate, and P99 Latency panels for immediate high-level status. The second row, labeled Row 2 Upstream Status, contains Upstream Health Map and Circuit Breaker States panels to show backend health. The third row, labeled Row 3 Traffic Breakdown, contains Top Routes, Top Consumers, and Error Distribution panels for traffic analysis. The fourth row, labeled Row 4 Latency Analysis, contains Gateway vs Backend Latency, Latency by Route, and Slow Request Percent panels for performance investigation. Arrows connect row 1 to row 2, row 2 to row 3, and row 3 to row 4, showing an intended reading order from broad health signals to detailed diagnostic panels.`
-  }
+  description="Top-to-bottom flowchart showing a dashboard organized into four rows. The first row, labeled Row 1 Health Overview, contains Request Rate, Error Rate, and P99 Latency panels for immediate high-level status. The second row, labeled Row 2 Upstream Status, contains Upstream Health Map and Circuit Breaker States panels to show backend health. The third row, labeled Row 3 Traffic Breakdown, contains Top Routes, Top Consumers, and Error Distribution panels for traffic analysis. The fourth row, labeled Row 4 Latency Analysis, contains Gateway vs Backend Latency, Latency by Route, and Slow Request Percent panels for performance investigation. Arrows connect row 1 to row 2, row 2 to row 3, and row 3 to row 4, showing an intended reading order from broad health signals to detailed diagnostic panels."
 />
 
 Row 1 gives you immediate health status — if everything is green, you can stop looking. Row 2 shows backend status, helping you quickly identify if a problem is gateway-side or upstream-side. Rows 3 and 4 provide the detail needed to narrow down issues to specific routes or consumers.
 
@@ -87,9 +87,7 @@ For storage-backed APIs (document processing, media transcoding, backup systems)
 <Diagram
   src={meteringDataDiagram}
   title="Metering data flow from API request to billing and enforcement systems"
-  description={
-    `Flowchart showing how an API request becomes billing and quota data. An API Request enters a decision point labeled Metering Points. From there, the request is measured across five dimensions: Request Count, Request Size, Response Size, Compute Duration, and Storage Delta. All five measurements feed into a single Usage Record. That usage record then flows into an Aggregation Pipeline, which distributes the aggregated data to three downstream systems: Billing System, Analytics, and Quota Enforcement. The diagram emphasizes that the same metering event supports cost reporting, product analysis, and quota control.`
-  }
+  description="Flowchart showing how an API request becomes billing and quota data. An API Request enters a decision point labeled Metering Points. From there, the request is measured across five dimensions: Request Count, Request Size, Response Size, Compute Duration, and Storage Delta. All five measurements feed into a single Usage Record. That usage record then flows into an Aggregation Pipeline, which distributes the aggregated data to three downstream systems: Billing System, Analytics, and Quota Enforcement. The diagram emphasizes that the same metering event supports cost reporting, product analysis, and quota control."
 />
 
 ### Metering Architecture Patterns
@@ -294,9 +292,7 @@ Token buckets are elegant for smoothing usage. Instead of "1 million requests pe
 <Diagram
   src={quotaEnforcementDiagram}
   title="Quota enforcement decision flow with soft limits and burst allowance"
-  description={
-    `Flowchart showing how each request is checked against quota rules. A Request enters a decision point labeled Check Quota. If the request is under the limit, it is allowed and the main counter is decremented. If it reaches the soft limit, it is still allowed but also triggers an alert before the main counter is decremented. If it reaches the hard limit, a second decision checks whether burst capacity is available. If burst capacity exists, the request is allowed from the burst pool and the burst counter is decremented. If no burst capacity remains, the request is rejected with HTTP 429. The diagram shows how soft limits provide warning, hard limits enforce plan boundaries, and burst allowances absorb short traffic spikes.`
-  }
+  description="Flowchart showing how each request is checked against quota rules. A Request enters a decision point labeled Check Quota. If the request is under the limit, it is allowed and the main counter is decremented. If it reaches the soft limit, it is still allowed but also triggers an alert before the main counter is decremented. If it reaches the hard limit, a second decision checks whether burst capacity is available. If burst capacity exists, the request is allowed from the burst pool and the burst counter is decremented. If no burst capacity remains, the request is rejected with HTTP 429. The diagram shows how soft limits provide warning, hard limits enforce plan boundaries, and burst allowances absorb short traffic spikes."
 />
 
 ### Rate Limiting vs. Quota Enforcement
@@ -514,9 +510,7 @@ Three common approaches:
 <Diagram
   src={costAttributionDiagram}
   title="Cost attribution flow from infrastructure costs to consumer invoices"
-  description={
-    `Flowchart showing how infrastructure spending becomes charges for consumers. Infrastructure Costs feed into a Cost Pool. That pool enters a decision point labeled Allocation Method, which branches into three pricing strategies: Direct Attribution, Proportional Allocation, and Tiered Pricing. Direct Attribution leads to Per-Request Cost, Proportional Allocation leads to Percent of Total Usage, and Tiered Pricing leads to Volume Discounts. All three calculated paths feed into a final Consumer Invoice. The diagram highlights that the same underlying operating cost can be turned into invoices through different allocation strategies depending on pricing goals, fairness, and customer behavior.`
-  }
+  description="Flowchart showing how infrastructure spending becomes charges for consumers. Infrastructure Costs feed into a Cost Pool. That pool enters a decision point labeled Allocation Method, which branches into three pricing strategies: Direct Attribution, Proportional Allocation, and Tiered Pricing. Direct Attribution leads to Per-Request Cost, Proportional Allocation leads to Percent of Total Usage, and Tiered Pricing leads to Volume Discounts. All three calculated paths feed into a final Consumer Invoice. The diagram highlights that the same underlying operating cost can be turned into invoices through different allocation strategies depending on pricing goals, fairness, and customer behavior."
 />
 
 Most internal APIs start with direct attribution (simple to explain) then move to proportional allocation once they realize different usage patterns have different costs. External APIs almost always use tiered pricing because it creates better business incentives.
@@ -704,9 +698,7 @@ The flow is consistent regardless of the destination:
 <Diagram
   src={endToEndBillingDiagram}
   title="End-to-end billing flow from API usage to payment processing"
-  description={
-    `Sequence diagram showing how API usage becomes a bill and then updates quota state. The API sends a Usage Event to Metering. Metering deduplicates the event and forwards Buffered Events to Aggregation. A note marks Aggregation as an hourly rollup job. Aggregation calculates costs and sends a Period Summary to Billing. Another note marks Billing as operating at the end of the billing period. Billing generates an invoice, charges the customer through Payment, receives a confirmation, and then updates quota limits back in the API system. The diagram emphasizes that usage collection, aggregation, invoicing, payment processing, and quota management form one connected lifecycle.`
-  }
+  description="Sequence diagram showing how API usage becomes a bill and then updates quota state. The API sends a Usage Event to Metering. Metering deduplicates the event and forwards Buffered Events to Aggregation. A note marks Aggregation as an hourly rollup job. Aggregation calculates costs and sends a Period Summary to Billing. Another note marks Billing as operating at the end of the billing period. Billing generates an invoice, charges the customer through Payment, receives a confirmation, and then updates quota limits back in the API system. The diagram emphasizes that usage collection, aggregation, invoicing, payment processing, and quota management form one connected lifecycle."
 />
 
 The key decision point is timing. Do you report usage continuously (every hour, every day) or only at the end of the billing period? Continuous reporting gives consumers real-time visibility into costs but requires more API calls to the billing platform. End-of-period reporting is simpler but consumers don't see costs until the bill arrives.
@@ -873,9 +865,7 @@ The layout matters. Put the most important information at the top — current us
 <Diagram
   src={consumerUsageDiagram}
   title="Consumer usage dashboard layout with logical panel grouping"
-  description={
-  `Left-to-right dashboard layout organized into four grouped sections. Row 1 Overview contains Monthly Usage Gauge showing 4.5 million of 10 million requests, Projected Cost showing a 450 dollar estimate, and Days Remaining showing 15 days left. Row 2 Trends contains Daily Usage Time Series for the last 30 days and Usage versus Previous Month showing a 15 percent increase. Row 3 Breakdown contains Usage by Endpoint for the top 10 routes, Usage by Region for geographic split, and Cost by Dimension for requests, compute, and egress. Row 4 Alerts contains Quota Alerts showing no alerts and Anomaly Detection showing a usage spike detected. The layout moves from current status to trends, then breakdowns, then alerting.`
-  }
+  description="Left-to-right dashboard layout organized into four grouped sections. Row 1 Overview contains Monthly Usage Gauge showing 4.5 million of 10 million requests, Projected Cost showing a 450 dollar estimate, and Days Remaining showing 15 days left. Row 2 Trends contains Daily Usage Time Series for the last 30 days and Usage versus Previous Month showing a 15 percent increase. Row 3 Breakdown contains Usage by Endpoint for the top 10 routes, Usage by Region for geographic split, and Cost by Dimension for requests, compute, and egress. Row 4 Alerts contains Quota Alerts showing no alerts and Anomaly Detection showing a usage spike detected. The layout moves from current status to trends, then breakdowns, then alerting."
 />
 
 Projected month-end usage is critical. If a consumer is at 50% of their quota with 25% of the month remaining, they're on track to use 200% of their quota. Show them this projection so they can optimize before hitting limits.