@@ -288,7 +288,7 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
 
 <Diagram
   magnifyButtonPosition="bottom-right"
-  size="2xl"
+  size="full"
 />
 
 [&>span]:
@@ -301,6 +301,7 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
 />
 
 <Table
+  fullWidth={false}
   classes={{
     figure: "sm:ml-8 sm:mr-12 mb-6",
   }}
 
@@ -0,0 +1,42 @@
+---
+export type Props = {
+  color: string
+  classes?: string
+  size: number
+  accessible: boolean
+  focusable: boolean
+  isListMarker?: boolean
+  id?: string
+}
+
+const { color, classes, size, accessible, focusable, isListMarker, id } = Astro.props
+---
+
+<svg
+  id={id}
+  xmlns="http://www.w3.org/2000/svg"
+  class:list={["shrink-0", `w-${size} h-${size}`, `text-${color}`, classes, isListMarker ? "mt-0.5" : ""]}
+  fill="currentColor"
+  stroke="none"
+  viewBox="0 0 24 24"
+  aria-hidden={accessible ? "false" : "true"}
+  focusable={focusable ? "true" : "false"}
+>
+  {accessible && <title>Availability Icon</title>}
+  <path
+    stroke-width="0.08"
+    d="m 13.819602,13.80294 c 0,-0.0571 0.0028,-0.113611 0.0043,-0.170407 H 2.9158474 C 1.3080416,13.632533 0,14.940577 0,16.548382 c 0,1.607806 1.3080416,2.915847 2.9158474,2.915847 H 18.024709 C 15.594483,18.729208 13.819602,16.469843 13.819602,13.80294 Z M 6.1725083,17.305744 H 3.521738 c -0.41761,0 -0.7573632,-0.339753 -0.7573632,-0.757362 0,-0.417611 0.3397532,-0.757364 0.7573632,-0.757364 h 2.6507703 c 0.4176101,0 0.757363,0.339753 0.757363,0.757364 0,0.417609 -0.3397529,0.757362 -0.757363,0.757362 z"
+  />
+  <path
+    stroke-width="0.08"
+    d="M 2.9158474,12.647961 H 13.933661 c 0.538789,-2.7098429 2.934251,-4.7590405 5.799962,-4.7590405 0.722524,0 1.414906,0.1307894 2.055407,0.3689862 C 21.281824,7.3961797 20.345042,6.8162678 19.274888,6.8162678 H 2.9158474 C 1.3080416,6.8162678 0,8.1243083 0,9.7321144 0,11.339921 1.3080416,12.647961 2.9158474,12.647961 Z M 3.521738,8.9747507 h 2.6507703 c 0.4176101,0 0.757363,0.339753 0.757363,0.7573637 0,0.4176106 -0.3397529,0.7573636 -0.757363,0.7573636 H 3.521738 c -0.41761,0 -0.7573632,-0.339753 -0.7573632,-0.7573636 0,-0.4176107 0.3397532,-0.7573637 0.7573632,-0.7573637 z"
+  />
+  <path
+    stroke-width="0.08"
+    d="M 2.9158474,5.8316952 H 19.274888 c 1.607729,0 2.915848,-1.3080427 2.915848,-2.9158486 C 22.190736,1.3080407 20.882617,0 19.274888,0 H 2.9158474 C 1.3080416,0 0,1.3080407 0,2.9158466 0,4.5236525 1.3080416,5.8316952 2.9158474,5.8316952 Z M 17.987371,1.9502106 c 0.532426,0 0.965638,0.43321 0.965638,0.965636 0,0.5324281 -0.433212,0.9656381 -0.965638,0.9656381 -0.532426,0 -0.965638,-0.43321 -0.965638,-0.9656381 0,-0.532426 0.433212,-0.965636 0.965638,-0.965636 z M 3.521738,2.1584846 h 2.6507703 c 0.4176101,0 0.757363,0.3397534 0.757363,0.757362 0,0.4176107 -0.3397529,0.757364 -0.757363,0.757364 H 3.521738 c -0.41761,0 -0.7573632,-0.3397533 -0.7573632,-0.757364 0,-0.4176086 0.3397532,-0.757362 0.7573632,-0.757362 z"
+  />
+  <path
+    stroke-width="0.08"
+    d="m 19.733623,9.5364876 c -2.356308,0 -4.266453,1.9101444 -4.266453,4.2664524 0,2.356309 1.910145,4.266454 4.266453,4.266454 C 22.089931,18.069394 24,16.159249 24,13.80294 24,11.446632 22.089931,9.5364876 19.733623,9.5364876 Z m 2.27936,3.3626164 -2.700303,2.700226 c -0.0571,0.05719 -0.133219,0.08876 -0.214182,0.08876 -0.08096,0 -0.157076,-0.03151 -0.214258,-0.08876 l -1.354164,-1.354165 c -0.05726,-0.05718 -0.08876,-0.133307 -0.08876,-0.214183 0,-0.08089 0.03151,-0.156996 0.08876,-0.214258 l 0.267727,-0.267727 c 0.0571,-0.05718 0.13322,-0.08876 0.214183,-0.08876 0.08088,0 0.157,0.03151 0.214182,0.08869 l 0.87233,0.872256 2.218392,-2.218241 c 0.0571,-0.05718 0.133225,-0.08876 0.214183,-0.08876 0.08095,0 0.157078,0.03159 0.214256,0.08876 l 0.267729,0.267727 c 0.05719,0.0571 0.08876,0.133225 0.08876,0.214183 -7.5e-5,0.08095 -0.03159,0.157078 -0.08884,0.214258 z"
+  />
+</svg>
@@ -26,10 +26,11 @@ This article covers what chaos engineering actually is (hint: it's not random de
 
 The term "chaos engineering" sounds destructive, which leads to a common misconception: that it's about randomly breaking things to see what happens. That's not chaos engineering — that's just chaos.
 
-Real chaos engineering follows the scientific method. You form a hypothesis about how your system should behave under specific failure conditions, you design a controlled experiment to test that hypothesis, and you observe whether reality matches your expectations. The goal isn't to cause outages; it's to build confidence that your system handles failures gracefully — or to learn exactly how it doesn't.
+<Highlighter>Real chaos engineering follows the scientific method.</Highlighter> You form a hypothesis about how your system should behave under specific failure conditions, you design a controlled experiment to test that hypothesis, and you observe whether reality matches your expectations. The goal isn't to cause outages; it's to build confidence that your system handles failures gracefully — or to learn exactly how it doesn't.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "The distinction that separates chaos engineering from breaking things.",
     thead: {
@@ -69,15 +70,27 @@ The simplest and most valuable first experiment is killing a pod. If you've neve
 **Prerequisites:**
 
 <List
-  variant="check-icons-list"
+  variant="three-column-icon-list"
+  classes={{
+    text: "!text-base",
+  }}
   items={[
     {
+      icon: "database",
+      color: "page-inverse",
+      bgColor: "note-inverse",
       text: "Your deployment has replicas > 1 (so traffic continues on surviving pods during recovery)",
     },
     {
+      icon: "availability",
+      color: "page-inverse",
+      bgColor: "note-inverse",
       text: "Health checks (liveness and readiness probes) are configured",
     },
     {
+      icon: "observability-and-telemetry",
+      color: "page-inverse",
+      bgColor: "note-inverse",
       text: "You have monitoring in place to observe the experiment",
     },
   ]}
@@ -107,6 +120,9 @@ The simplest and most valuable first experiment is killing a pod. If you've neve
 
 <List
   variant="check-icons-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       text: "New pod running within 60 seconds",
@@ -139,24 +155,26 @@ Code: Simple pod termination experiment with recovery observation.
 **What teams commonly discover from this experiment:**
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-18 mb-6",
+  }}
   items={[
     {
-      lead: "Slow container startup delays recovery.",
+      lead: "Slow container startup delays recovery",
       text: "If your container takes 45 seconds to start, that's 45 seconds of degraded capacity. Optimize image size, add startup probes, or adjust replica counts.",
     },
     {
-      lead: "Missing readiness probes cause traffic to unhealthy pods.",
+      lead: "Missing readiness probes cause traffic to unhealthy pods",
       text: "Without a readiness probe, Kubernetes sends traffic to pods that aren't ready to handle it, causing errors during startup.",
     },
     {
-      lead: "No alerts fired despite degradation.",
+      lead: "No alerts fired despite degradation",
       text: "This is the \"aha\" moment — your monitoring gap was invisible until you tested it.",
     },
   ]}
 />
 
-
 These findings alone justify the experiment. And you can run it in staging today, with no budget approval, no platform purchase, and no dedicated chaos team.
 
 <Newsletter />
 
@@ -47,7 +47,8 @@ The term "chaos engineering" sounds destructive, which leads to a common misconc
 Real chaos engineering follows the scientific method. You form a hypothesis about how your system should behave under specific failure conditions, design a controlled experiment to test that hypothesis, and observe whether reality matches your expectations. The goal isn't to cause outages; it's to build confidence that your system handles failures gracefully — or to learn exactly how it doesn't.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "The distinction that separates real chaos engineering from breaking things randomly.",
     thead: {
@@ -84,6 +85,8 @@ The scientific cycle looks like this: form a hypothesis about expected behavior,
 
 <Diagram
   src={theScientificCycleDiagram}
+  magnifyButtonPosition="bottom-left"
+  size="full"
   title="The scientific cycle of chaos engineering"
   description="Flowchart showing the chaos engineering loop: form a hypothesis, define steady state, plan the experiment, contain blast radius, run the experiment, observe behavior, and learn and improve before repeating the cycle."
 />
@@ -142,6 +145,8 @@ From there, you can progress to experiments during business hours with real traf
 
 <Diagram
   src={progressiveChaosDiagram}
+  magnifyButtonPosition="top-left"
+  size="full"
   title="Progressive chaos engineering maturity levels"
   description="Flowchart showing four maturity levels progressing from non-production experiments to low-risk production experiments, production experiments with live traffic, and finally automated chaos, with each level annotated by the kind of learning it enables."
 />
@@ -415,33 +420,33 @@ Code: LitmusChaos network latency experiment.
 The tradeoff with LitmusChaos is complexity. You need to install the LitmusChaos operator, set up service accounts with appropriate permissions, and understand the CRD-based workflow. For teams already deep in Kubernetes and GitOps, this feels natural. For teams just starting with chaos engineering, Chaos Toolkit's simpler CLI-based approach might be easier to adopt.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Comparison of free chaos engineering tools.",
     thead: {
-      th: ["Tool", "Best For", "Complexity", "Kubernetes Required"],
+      th: ["Tool", "Complexity", "Best For", "Kubernetes Required"],
     },
     tbody: {
       tr: [
         {
           th: "kubectl",
-          td: ["First experiments, simple pod/node chaos", "Low", "Yes"],
+          td: ["Low", "First experiments, simple pod/node chaos", "Yes"],
         },
         {
           th: "tc/iptables",
-          td: ["Network latency and packet loss", "Medium", "No (Linux only)"],
+          td: ["Medium", "Network latency and packet loss", "No (Linux only)"],
         },
         {
           th: "toxiproxy",
-          td: ["Surgical dependency failure injection", "Medium", "No"],
+          td: ["Medium", "Surgical dependency failure injection", "No"],
         },
         {
           th: "Chaos Toolkit",
-          td: ["Structured experiments with hypothesis validation", "Medium", "No (has K8s extension)"],
+          td: ["Medium", "Structured experiments with hypothesis validation", "No (has K8s extension)"],
         },
         {
           th: "LitmusChaos",
-          td: ["GitOps-managed, Kubernetes-native chaos", "High", "Yes"],
+          td: ["High", "GitOps-managed, Kubernetes-native chaos", "Yes"],
         },
       ],
     },
@@ -464,6 +469,7 @@ Impact limits define what customer-facing consequences you're willing to accept.
 
 <Diagram
   src={threeDimensionsDiagram}
+  magnifyButtonPosition="top-left"
   title="Three dimensions of blast radius control"
   description="Flowchart showing blast radius control divided into scope limiting, time limiting, and impact limiting, with examples such as targeting a single pod, setting maximum duration and automatic aborts, and starting with low-traffic non-critical paths."
 />
@@ -654,24 +660,23 @@ Watch for the new pod scheduling, the health check passing, and traffic resuming
 What teams commonly discover from this experiment:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
-      lead: "_Slow container startup delays recovery._",
+      lead: "Slow container startup delays recovery.",
       text: "If your container takes 45 seconds to start, that's 45 seconds of degraded capacity. Consider optimizing image size, adding startup probes, or adjusting replica counts.",
     },
     {
-      lead: "_Missing readiness probes cause traffic to unhealthy pods._",
+      lead: "Missing readiness probes cause traffic to unhealthy pods.",
       text: "Without a readiness probe, Kubernetes sends traffic to pods that aren't ready, causing errors during startup.",
     },
     {
-      lead: "_No alerts fired despite degradation._",
+      lead: "No alerts fired despite degradation.",
       text: "This is the \"aha\" moment — your monitoring gap was invisible until you tested it.",
     },
   ]}
 />
 
-
 ### Experiment 2: Dependency Latency
 
 Most production incidents aren't clean crashes — they're slowdowns. A database that responds in 500ms instead of 10ms is technically "up," but your service might as well be down if it can't handle the latency gracefully. This experiment reveals whether your timeouts, circuit breakers, and connection pools are configured correctly.
@@ -708,7 +713,7 @@ Success looks like: service remains responsive (P99 under 3 seconds), no cascadi
 What teams commonly discover:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Missing timeouts cause request pileup.",
@@ -764,18 +769,18 @@ Success criteria: service continues responding (even if slowly), fallback to dat
 What teams commonly discover:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
-      lead: "_Hard dependency on cache, no fallback._",
+      lead: "Hard dependency on cache, no fallback.",
       text: "The code assumes cache is always available and throws exceptions on connection failure instead of falling back.",
     },
     {
-      lead: "_Timeouts too long, requests queue._",
+      lead: "Timeouts too long, requests queue.",
       text: "Connection timeouts of 30 seconds mean requests pile up waiting for a cache that will never respond.",
     },
     {
-      lead: "_Cache reconnection logic is buggy._",
+      lead: "Cache reconnection logic is buggy.",
       text: "After the partition heals, the service doesn't reconnect properly and continues failing.",
     },
   ]}
@@ -821,18 +826,18 @@ Success looks like: no OOM kills, graceful degradation where the service sheds e
 What teams commonly discover:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
-      lead: "_No memory limits set._",
+      lead: "No memory limits set.",
       text: "Without limits, one pod's memory pressure affects the entire node — the classic noisy neighbor problem.",
     },
     {
-      lead: "_OOM kill with no graceful handling._",
+      lead: "OOM kill with no graceful handling.",
       text: "The application gets killed abruptly with no opportunity to drain connections or save state.",
     },
     {
-      lead: "_Memory leaks exposed under pressure._",
+      lead: "Memory leaks exposed under pressure.",
       text: "Baseline memory usage creeps up over time, and the stress test just accelerates the inevitable OOM.",
     },
   ]}
@@ -850,6 +855,7 @@ A mature chaos practice looks different. Experiments run on a regular cadence
 
 <Diagram
   src={evolutionDiagram}
+  magnifyButtonPosition="top-left"
   title="Evolution from ad-hoc experiments to mature chaos practice"
   description="Flowchart showing a progression from ad-hoc experiments to regular experiments, then game days, and finally automated chaos, with each stage annotated by the learning or organizational capability it adds."
 />
@@ -859,42 +865,42 @@ The progression takes time — typically a year or more to go from first experim
 Here's a realistic four-quarter roadmap for building a chaos engineering practice from scratch:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Four-quarter roadmap for building a chaos engineering practice.",
     thead: {
-      th: ["Quarter", "Focus", "Activities", "Success Criteria"],
+      th: ["Focus", "Quarter", "Activities", "Success Criteria"],
     },
     tbody: {
       tr: [
         {
-          th: "Q1",
+          th: "Establish basics",
           td: [
-            "Establish basics",
+            "Q1",
             "Run first pod-kill experiments, document and fix findings, train team on experiment design (hypothesis, abort conditions, stakeholder communication)",
             "3+ experiments completed, 5+ bugs fixed",
           ],
         },
         {
-          th: "Q2",
+          th: "Expand coverage",
           td: [
-            "Expand coverage",
+            "Q2",
             "Move to latency injection and network partitions, create reusable experiment library, test all critical services",
             "Comprehensive critical path coverage, updated runbooks",
           ],
         },
         {
-          th: "Q3",
+          th: "Build team capability",
           td: [
-            "Build team capability",
+            "Q3",
             "Host first game day, enable multiple teams to run experiments independently, share learnings org-wide",
             "Successful game day, 3+ teams practicing chaos",
           ],
         },
         {
-          th: "Q4",
+          th: "Automate foundations",
           td: [
-            "Automate foundations",
+            "Q4",
             "Integrate chaos into CI/CD for staging deployments, automate steady-state verification, schedule recurring experiments",
             "Weekly automated experiments without manual intervention",
           ],
@@ -960,7 +966,8 @@ Game days build team muscle memory for incident response. The goal isn't to find
 How do you know if your chaos practice is working? You need metrics that measure both activity (are you actually running experiments?) and impact (are you finding and fixing problems?).
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Metrics for measuring chaos engineering practice effectiveness.",
     thead: {
@@ -1029,10 +1036,10 @@ Chaos engineering doesn't require expensive platforms or dedicated teams. You ca
 
 The principles are simple: form a hypothesis before you break anything, define abort conditions so experiments don't become incidents, control the blast radius so you're learning rather than causing outages, and follow through on findings by actually fixing them.
 
-Once you've mastered the four experiments in this guide, the path forward opens up. You can explore zone and region failures to test geographic redundancy. You can inject clock skew to find time-sensitive bugs. You can simulate certificate expiration, DNS failures, or cloud provider API throttling. Each new experiment type reveals a different class of bugs — and each one can be done with free tools.
-
-The barrier to starting isn't tooling or budget. It's deciding to run that first experiment. Pick a service. Form a hypothesis. Open your monitoring dashboard. Kill a pod. Watch what happens.
-
 <Callout type="success">
 You don't need an enterprise chaos platform to start chaos engineering. You need a hypothesis, a safe experiment, monitoring to observe the results, and the discipline to fix what you find. Start small, learn, and expand.
 </Callout>
+
+Once you've mastered the four experiments in this guide, the path forward opens up. You can explore zone and region failures to test geographic redundancy. You can inject clock skew to find time-sensitive bugs. You can simulate certificate expiration, DNS failures, or cloud provider API throttling. Each new experiment type reveals a different class of bugs — and each one can be done with free tools.
+
+The barrier to starting isn't tooling or budget. It's deciding to run that first experiment. Pick a service. Form a hypothesis. Open your monitoring dashboard. Kill a pod. Watch what happens.