@dx-do/cli 5.2.48 → 5.2.50

package/dist-node/27-nassql-distinct-keep.nassql-6z55dvk3.md

@@ -0,0 +1,24 @@
+# 27-nassql-distinct-keep (NASSQL)
+
+## Purpose
+
+Demonstrate `FROM_TOPOLOGY` for listing Kubernetes namespace names from the topology.
+
+## Query Construction
+
+Simple two-step pipeline:
+1. **FROM_TOPOLOGY**: Load `k8s_NAMESPACE` vertices using an ATTRIBUTE filter
+2. **KEEP**: Select only the name and type columns
+
+## API Surface Exercised
+
+- **FROM_TOPOLOGY**: With ATTRIBUTE filter targeting k8s_NAMESPACE type
+- **KEEP**: Column projection
+
+## Expected Output
+
+Up to 50 rows, each a Kubernetes namespace with name and type. Typical results include the standard Kubernetes namespaces (`kube-system`, `ingress-nginx`, `tigera-operator`, …) alongside whatever application namespaces the cluster is running (e.g. `tixchange-v1`, `tixchange-v2`, `monitoring-system`).
+
+## What the Results Tell You
+
+`FROM_TOPOLOGY` can target any TAS vertex type. Combined with `KEEP`, it provides a simple way to extract specific topology information into a tabular format. This is useful for building dropdowns or filters in a UI — e.g., "select a Kubernetes namespace" populated from live topology data.

package/dist-node/27-nassql-distinct-keep.nassql.data-store-mrx00ys5.json5

@@ -0,0 +1,52 @@
+/*
+ * Distinct-name extraction from FROM_TOPOLOGY — load entities,
+ * project to (name, type), let the natural row-per-vertex shape
+ * give you the distinct list. KEEP-only after a source op.
+ *
+ * Use this shape for "what X exist on this tenant" questions
+ * where you just want the names (e.g. "list namespaces", "list
+ * services"). Cheaper than a full TAS query if you only need
+ * a few projected columns.
+ *
+ * NOTE: there is no NASSQL `DISTINCT` op today — distinct-ness
+ * comes from the underlying topology (one vertex per entity).
+ * If the same name appears on multiple vertices (rare but
+ * possible), they appear as separate rows. For true
+ * de-duplication, GROUP by the column.
+ */
+{
+  "query": [
+    /*
+     * Standard FROM_TOPOLOGY → narrow to k8s_NAMESPACE vertices.
+     * The same shape works for any vertex type that has a
+     * `name` attribute and you want distinct values.
+     */
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["k8s_NAMESPACE"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "namespaces"
+    },
+    /*
+     * Project to just (name, type). Using `vertex.attr.name`
+     * (NOT `name` directly — name is a NASSQL keyword in some
+     * contexts and FROM_TOPOLOGY uses the `vertex.attr.<n>`
+     * column-name convention).
+     */
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.name", "vertex.attr.type"]
+    }
+  ],
+  "limit": 50
+}

package/dist-node/27-nassql-distinct-keep.nassql.data-store-tmd-0p9hy42g.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM_TOPOLOGY + KEEP: list Kubernetes namespace names from topology",
+  "tags": ["nassql", "from_topology", "keep", "distinct"]
+}

package/dist-node/28-nassql-format-time.nassql-6wraqgdk.md

@@ -0,0 +1,30 @@
+# 28-nassql-format-time (NASSQL)
+
+## Purpose
+
+Demonstrate the `FORMAT_TIME` operation, which converts epoch timestamps into human-readable date/time strings.
+
+## Query Construction
+
+Pipeline:
+1. **FROM_TOPOLOGY**: Load AGENT vertices
+2. **FORMAT_TIME**: Convert `vertex.endTime` (epoch millis) to a formatted string
+   - `column`: Input column containing the timestamp
+   - `as`: Output column name
+   - `pattern`: Java SimpleDateFormat pattern
+3. **KEEP**: Select name, type, and formatted timestamp
+
+## API Surface Exercised
+
+- **FORMAT_TIME**: Time formatting with `column`, `as`, `pattern`
+- Also supports: `duration: true` (format as duration), `timezone` (timezone name)
+
+## Expected Output
+
+Rows showing each agent name, type, and a human-readable "last seen" timestamp like `"2025-04-30 14:23:45"`.
+
+## What the Results Tell You
+
+`FORMAT_TIME` is essential for dashboard displays where raw epoch milliseconds are not meaningful. The `pattern` follows Java SimpleDateFormat conventions (e.g., `yyyy-MM-dd HH:mm:ss`, `dd/MM/yyyy`, etc.).
+
+The `vertex.endTime` column from `FROM_TOPOLOGY` indicates when a vertex was last updated in the topology, which for agents typically corresponds to their last heartbeat or data report.

package/dist-node/28-nassql-format-time.nassql.data-store-tmd-bbbqhz1x.json

@@ -0,0 +1,4 @@
+{
+  "description": "FORMAT_TIME: format vertex endTime timestamps into human-readable strings",
+  "tags": ["nassql", "format_time", "formatting"]
+}

package/dist-node/28-nassql-format-time.nassql.data-store-tvy8y2cs.json5

@@ -0,0 +1,59 @@
+/*
+ * `FORMAT_TIME` — convert an epoch-ms column into a human-readable
+ * timestamp string. Use to make timestamp columns readable in
+ * downstream output (`vertex.endTime`, `vertex.startTime`,
+ * `data.timestamp`, `time.bucket`, etc).
+ *
+ * Pattern uses Java SimpleDateFormat syntax:
+ *   yyyy-MM-dd HH:mm:ss   → 2026-05-04 14:23:01
+ *   yyyy-MM-dd'T'HH:mm:ss → ISO-ish
+ *   HH:mm                 → just hour:minute
+ *
+ * The original epoch-ms column stays in the row; the formatted
+ * value lands in the `as` column. Use KEEP to drop the original
+ * if you want only the formatted form.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["AGENT"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "agents"
+    },
+    /*
+     * FORMAT_TIME projects an epoch-ms column to a string.
+     * `column` is the source (must be numeric, ms since epoch);
+     * `as` is the new column name; `pattern` is Java
+     * SimpleDateFormat syntax.
+     *
+     * Common patterns:
+     *   "yyyy-MM-dd HH:mm:ss"       full timestamp
+     *   "yyyy-MM-dd"                date only
+     *   "EEE MMM d HH:mm"           Mon May 4 14:23
+     *
+     * Timezone defaults to UTC; pattern with `Z` includes offset.
+     */
+    {
+      "op": "FORMAT_TIME",
+      "column": "vertex.endTime",
+      "as": "last_seen",
+      "pattern": "yyyy-MM-dd HH:mm:ss"
+    },
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.name", "vertex.attr.type", "last_seen"]
+    }
+  ],
+  "limit": 20
+}

package/dist-node/29-nassql-describe-log.nassql-t9vnxeb0.md

@@ -0,0 +1,31 @@
+# 29-nassql-describe-log (NASSQL)
+
+## Purpose
+
+Demonstrate `DESCRIBE` as a debugging tool to inspect the column schema at any point in the pipeline.
+
+## Query Construction
+
+Pipeline:
+1. **FROM_TOPOLOGY**: Load HOST vertices
+2. **JOIN_METADATA**: Join with all metric metadata
+3. **DESCRIBE**: Output the column names available at this point
+
+`DESCRIBE` produces a single header row listing all available column names, with no data rows.
+
+## API Surface Exercised
+
+- **DESCRIBE**: Debug/introspection operation
+- **FROM_TOPOLOGY + JOIN_METADATA**: Cross-domain join whose column output we want to inspect
+
+## Expected Output
+
+A single row listing all available columns after the topology+metadata join. Typically includes:
+- `vertex.id`, `vertex.externalId`, `vertex.attr.*` — from topology
+- `metric.source`, `metric.path`, `metric.id` — from metadata join
+
+## What the Results Tell You
+
+`DESCRIBE` is invaluable when building complex pipelines. It shows what columns are available for subsequent `GROUP`, `FILTER`, `KEEP`, and aggregation operations. Use it when you get "Unknown required column" errors — insert `DESCRIBE` before the failing operation to see what's actually available.
+
+The companion debug operation `LOG` can be inserted mid-pipeline to output intermediate results to the server log without affecting the pipeline output.

package/dist-node/29-nassql-describe-log.nassql.data-store-tmd-q4mtczy8.json

@@ -0,0 +1,4 @@
+{
+  "description": "DESCRIBE: inspect column schema after FROM_TOPOLOGY + JOIN_METADATA to see all available fields",
+  "tags": ["nassql", "describe", "debug"]
+}

package/dist-node/29-nassql-describe-log.nassql.data-store-x16y4crx.json5

@@ -0,0 +1,51 @@
+/*
+ * `DESCRIBE` after a JOIN — introspect the post-join column shape.
+ * Same DESCRIBE op as #04, but here applied AFTER FROM_TOPOLOGY +
+ * JOIN_METADATA so it reveals the COMBINED column set (vertex.attr.*
+ * + metric.* + any other fields the join adds).
+ *
+ * Use when you've composed a multi-source pipeline and need to
+ * confirm exactly which columns are available for the next op
+ * (KEEP, GROUP, FILTER, etc). Cheaper than running the full
+ * pipeline and inspecting the data rows.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["HOST"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "hosts"
+    },
+    /*
+     * JOIN_METADATA — adds metric.* columns to each topology row.
+     * The join is implicit (DataStore knows the entity-to-metric
+     * mapping); aliases let you reference column collisions.
+     */
+    {
+      "op": "JOIN_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "host_metrics"
+    },
+    /*
+     * DESCRIBE shows the column shape after the joins. Columns
+     * include both `vertex.attr.<n>` (from FROM_TOPOLOGY) AND
+     * `metric.<n>` (from JOIN_METADATA). Useful for "what can I
+     * KEEP / GROUP / FILTER on after this join?" questions.
+     */
+    {
+      "op": "DESCRIBE"
+    }
+  ],
+  "limit": 100
+}

package/dist-node/30-nassql-map-string.nassql-f2tdknzs.md

@@ -0,0 +1,30 @@
+# 30-nassql-map-string (NASSQL)
+
+## Purpose
+
+Demonstrate the `MAP_STRING` operation, which applies regex-based string extraction/transformation to column values.
+
+## Query Construction
+
+Pipeline:
+1. **FROM_TOPOLOGY**: Load k8s_POD vertices
+2. **MAP_STRING**: Extract from `vertex.attr.name` using regex pattern `(.*)`, outputting to `pod_label`
+   - `column`: Input column
+   - `pattern`: Java regex with capture groups
+   - `as`: Array of output column names (one per capture group)
+3. **KEEP**: Select the mapped column and vertex type
+
+## API Surface Exercised
+
+- **MAP_STRING**: Regex-based string transformation with `column`, `pattern`, `as[]`
+- Also supports: `asType` (type coercion), `fillValues` (defaults), `filterNotMatching` (exclude non-matching rows)
+
+## Expected Output
+
+20 rows showing pod names (unchanged since the pattern captures everything) and their vertex type.
+
+## What the Results Tell You
+
+`MAP_STRING` is useful for extracting structured components from string fields. For example, with a source name like `SuperDomain|host|process|agent`, you could use pattern `.*\\|(.*)\\|(.*)\\|(.*)` with `as: ["host", "process", "agent"]` to split it into individual columns.
+
+The `as` field is an array because each capture group in the regex maps to a separate output column.

package/dist-node/30-nassql-map-string.nassql.data-store-t8ahcabn.json5

@@ -0,0 +1,53 @@
+/*
+ * `MAP_STRING` — regex-extract groups from a string column into
+ * one or more new columns. Powerful for parsing structured names
+ * (e.g. `app|env|version` patterns common in agent / pod naming
+ * conventions).
+ *
+ * Pattern is Java regex with capture groups. `as` is an array of
+ * names — one per capture group. The pattern shown here `(.*)`
+ * captures the whole string (a no-op trick to copy a column);
+ * realistic patterns split a name into parts.
+ *
+ * Example splitting an agent name like "EMEA|prod-01|infra-agent":
+ *   pattern: "([^|]+)\\|([^|]+)\\|([^|]+)"
+ *   as:      ["region", "host", "agent_type"]
+ */
+{
+  "query": [
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["k8s_POD"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "pods"
+    },
+    /*
+     * MAP_STRING runs `pattern` against `column`'s value per row;
+     * each capture group lands in the corresponding `as` column.
+     * Rows whose value doesn't match the pattern get null in the
+     * `as` columns (don't get dropped — use FILTER + REGEX for
+     * row-level pattern filtering).
+     */
+    {
+      "op": "MAP_STRING",
+      "column": "vertex.attr.name",
+      "pattern": "(.*)",
+      "as": ["pod_label"]
+    },
+    {
+      "op": "KEEP",
+      "columns": ["pod_label", "vertex.attr.type"]
+    }
+  ],
+  "limit": 20
+}

package/dist-node/30-nassql-map-string.nassql.data-store-tmd-a6xq0bdx.json

@@ -0,0 +1,4 @@
+{
+  "description": "MAP_STRING: format pod names into labeled strings using printf-style format",
+  "tags": ["nassql", "map_string", "formatting"]
+}

package/dist-node/31-nassql-join-data-sum.nassql-p16y3xk6.md

@@ -0,0 +1,26 @@
+# 31-nassql-join-data-sum (NASSQL)
+
+## Purpose
+
+Demonstrate `JOIN_METADATA` with a `SPEC` + `REGEX` specifier to join topology vertices with a filtered subset of metrics.
+
+## Query Construction
+
+Pipeline:
+1. **FROM_TOPOLOGY**: Load AGENT vertices
+2. **JOIN_METADATA**: Join with metrics matching `.*Responses Per Interval.*` pattern (via SPEC + attributeNameSpecifier REGEX)
+3. **GROUP + COUNT**: Count matching metrics per agent
+4. **ORDER + KEEP**: Sort and select
+
+## API Surface Exercised
+
+- **JOIN_METADATA**: With a filtered `querySpecifier` (not just ALL)
+- **SPEC + REGEX in JOIN_METADATA**: Same specifier structure as in FROM_METADATA
+
+## Expected Output
+
+Rows showing agents that have "Responses Per Interval" metrics. May return 0 rows if no agents on this tenant have that specific metric path.
+
+## What the Results Tell You
+
+`JOIN_METADATA` accepts the same `querySpecifier` types as `FROM_METADATA`. By providing a SPEC with REGEX filters, you can narrow the join to only relevant metrics. This is more efficient than joining with ALL and filtering afterward, as the metadata lookup is constrained server-side.

package/dist-node/31-nassql-join-data-sum.nassql.data-store-dje7wm6v.json5

@@ -0,0 +1,64 @@
+/*
+ * Cross-domain pipeline targeting a SPECIFIC metric pattern —
+ * agents with their "Responses Per Interval" metrics, ranked by
+ * how many such metrics each publishes. Demonstrates JOIN_METADATA
+ * with a SPEC narrowing (vs the ALL of #23).
+ *
+ * Pattern: agents (FROM_TOPOLOGY) × narrowed metrics
+ * (JOIN_METADATA + REGEX) → group → count → order. Use this shape
+ * when you want "entities × specific metric category" coverage.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        "filter": {
+          "op": "ATTRIBUTE",
+          "expressions": [
+            {
+              "name": "type",
+              "values": ["AGENT"],
+              "operator": "IN"
+            }
+          ]
+        }
+      },
+      "alias": "agents"
+    },
+    /*
+     * JOIN_METADATA with a SPEC narrowing — join only metrics
+     * matching the regex (here "Responses Per Interval"-shaped
+     * names). Server-side narrowing is far cheaper than joining
+     * ALL metrics then FILTERing downstream.
+     */
+    {
+      "op": "JOIN_METADATA",
+      "querySpecifier": {
+        "op": "SPEC",
+        "attributeNameSpecifier": {
+          "op": "REGEX",
+          "pattern": ".*Responses Per Interval.*"
+        }
+      },
+      "alias": "response_metrics"
+    },
+    {
+      "op": "GROUP",
+      "columns": ["vertex.attr.name"]
+    },
+    {
+      "op": "COUNT",
+      "as": "response_metric_count"
+    },
+    {
+      "op": "ORDER",
+      "columns": [{ "column": "response_metric_count", "sortDescending": true }]
+    },
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.name", "response_metric_count"]
+    }
+  ],
+  "limit": 20
+}

package/dist-node/31-nassql-join-data-sum.nassql.data-store-tmd-c1pyx1qw.json

@@ -0,0 +1,4 @@
+{
+  "description": "FROM_TOPOLOGY + JOIN_METADATA (REGEX): find agents with 'Responses Per Interval' metrics, count per agent",
+  "tags": ["nassql", "from_topology", "join_metadata", "regex", "group"]
+}

package/dist-node/32-nassql-bottom-aggregation.nassql-hpgfn77p.md

@@ -0,0 +1,26 @@
+# 32-nassql-bottom-aggregation (NASSQL)
+
+## Purpose
+
+Demonstrate the `BOTTOM` shaping operation — the inverse of `TOP` — to find the lowest-ranked rows.
+
+## Query Construction
+
+Pipeline: FROM_METADATA → GROUP → COUNT → BOTTOM → KEEP
+
+`BOTTOM` takes:
+- `column`: Column to rank by
+- `n`: How many lowest-value rows to return
+
+## API Surface Exercised
+
+- **BOTTOM**: Selects the bottom N rows (lowest values)
+- Counterpart to `TOP` (query 25)
+
+## Expected Output
+
+10 rows: the 10 metric sources with the fewest metrics. Rarely-reporting sources can have as few as 1–10 metrics — exact counts vary by tenant configuration.
+
+## What the Results Tell You
+
+`BOTTOM` is useful for finding outliers on the low end — agents reporting very few metrics might indicate misconfiguration, partial monitoring, or agents that are shutting down. Combined with `TOP`, you can quickly identify both the busiest and quietest parts of your monitoring infrastructure.

package/dist-node/32-nassql-bottom-aggregation.nassql.data-store-tmd-p0ssj1vc.json

@@ -0,0 +1,4 @@
+{
+  "description": "BOTTOM: find the 10 metric sources with the fewest metrics (least active agents)",
+  "tags": ["nassql", "bottom", "group", "count", "shaping"]
+}

package/dist-node/32-nassql-bottom-aggregation.nassql.data-store-v9580caa.json5

@@ -0,0 +1,43 @@
+/*
+ * `BOTTOM` — companion of TOP (#25). Same shape, returns the N
+ * rows with the LOWEST values in `column`. Use for outlier
+ * detection on the low end (e.g. quietest sources, smallest
+ * groups, lowest-coverage entities).
+ *
+ * Same `n` field gotcha as TOP — schema field is `n` not `count`.
+ *
+ * Investigative use: low-volume metric sources are often
+ * misconfigured / shutting-down / partially-monitored agents.
+ * Useful as a quality check.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_METADATA",
+      "querySpecifier": { "op": "ALL" },
+      "alias": "all_metadata"
+    },
+    {
+      "op": "GROUP",
+      "columns": ["metric.source"]
+    },
+    {
+      "op": "COUNT",
+      "as": "metric_count"
+    },
+    /*
+     * BOTTOM keeps the N rows with the LOWEST values in `column`.
+     * Same partial-sort efficiency as TOP. Same `n` field shape.
+     */
+    {
+      "op": "BOTTOM",
+      "column": "metric_count",
+      "n": 10
+    },
+    {
+      "op": "KEEP",
+      "columns": ["metric.source", "metric_count"]
+    }
+  ],
+  "limit": 10
+}

package/dist-node/33-nassql-cross-domain-pipeline.nassql-fm0ynphf.md

@@ -0,0 +1,45 @@
+# 33-nassql-cross-domain-pipeline (NASSQL)
+
+## Purpose
+
+Demonstrate a complex cross-domain pipeline that embeds a TAS TRAVERSE filter inside FROM_TOPOLOGY, then uses NASSQL aggregation to summarize the topology structure.
+
+## Query Construction
+
+The `FROM_TOPOLOGY` querySpecifier contains a full TAS query with a nested TRAVERSE:
+
+```
+FROM_TOPOLOGY
+  └── TAS Query:
+        filter: TRAVERSE
+          └── input: ATTRIBUTE(type IN [k8s_CLUSTER])
+          └── traverse: [{ direction: ANY, repeat: 3 }]
+          └── includeInput: true
+```
+
+This loads all vertices within 3 hops of the k8s cluster, then the NASSQL pipeline groups and counts by vertex type.
+
+## API Surface Exercised
+
+- **FROM_TOPOLOGY** with complex nested TAS filter (TRAVERSE + ATTRIBUTE)
+- **GROUP + COUNT + ORDER**: Standard aggregation
+- **Cross-domain composition**: TAS topology filtering inside NASSQL tabular processing
+
+## Expected Output
+
+Rows showing each vertex type and its count within the k8s cluster hierarchy:
+
+| vertex.attr.type | entity_count |
+|---|---|
+| k8s_CONTAINER | 21 |
+| k8s_POD | 20 |
+| k8s_NAMESPACE | 13 |
+| AGENT | 7 |
+| HOST | 3 |
+| ... | ... |
+
+## What the Results Tell You
+
+This is the power of NASSQL: it combines the graph-traversal capabilities of TAS with the relational aggregation of SQL-like operations. You can explore a topology subgraph (using any TAS filter), then immediately aggregate, filter, and shape the results as tabular data.
+
+This pattern is useful for "infrastructure summary" dashboards — e.g., "show me the composition of my Kubernetes cluster by entity type."

package/dist-node/33-nassql-cross-domain-pipeline.nassql.data-store-tmd-18881drs.json

@@ -0,0 +1,4 @@
+{
+  "description": "Cross-domain pipeline: FROM_TOPOLOGY with TAS TRAVERSE filter into NASSQL GROUP + COUNT — count entities by type across the k8s cluster hierarchy",
+  "tags": ["nassql", "from_topology", "traverse", "group", "count", "cross-domain"]
+}

package/dist-node/33-nassql-cross-domain-pipeline.nassql.data-store-vqs9hkx4.json5

@@ -0,0 +1,79 @@
+/*
+ * The most-composed pattern in this catalog: TAS-TRAVERSE inside
+ * NASSQL-FROM_TOPOLOGY's filter. Walks the k8s topology graph
+ * (cluster → 3-hop neighborhood) inside TAS, then flattens to
+ * NASSQL rows for grouping/counting by vertex type.
+ *
+ * Result: one row per Kubernetes vertex TYPE that appears in the
+ * neighborhood, with how many of each. Tells you the SHAPE of
+ * the k8s topology (e.g. "200 pods, 50 deployments, 5 namespaces,
+ * 1 cluster"). Useful for "audit my k8s coverage" investigations.
+ *
+ * The TRAVERSE-inside-FROM_TOPOLOGY pattern works for ANY graph-
+ * shaped seed-and-walk you want to flatten into a table — pods,
+ * services-and-their-hosts, agents-and-their-monitored-services,
+ * etc.
+ */
+{
+  "query": [
+    {
+      "op": "FROM_TOPOLOGY",
+      "querySpecifier": {
+        /*
+         * The TAS filter inside FROM_TOPOLOGY can be ANY TAS
+         * filter — including TRAVERSE for graph traversal.
+         * 3-hop walk from k8s_CLUSTER reaches: namespaces,
+         * deployments, pods, containers, daemonsets — the
+         * full k8s entity tree.
+         *
+         * `repeat: 3` is enough for typical k8s topology
+         * (cluster→namespace→deployment→pod). Bump to 4-5 if
+         * you also want containers / replicasets.
+         */
+        "filter": {
+          "op": "TRAVERSE",
+          "input": {
+            "op": "ATTRIBUTE",
+            "expressions": [
+              {
+                "name": "type",
+                "values": ["k8s_CLUSTER"],
+                "operator": "IN"
+              }
+            ]
+          },
+          "traverse": [
+            {
+              "direction": "ANY",
+              "repeat": 3
+            }
+          ],
+          "includeInput": true
+        }
+      },
+      "alias": "k8s_entities"
+    },
+    /*
+     * Group by VERTEX TYPE — one row per type, count per type.
+     * `vertex.attr.type` is the column name (the FROM_TOPOLOGY
+     * convention).
+     */
+    {
+      "op": "GROUP",
+      "columns": ["vertex.attr.type"]
+    },
+    {
+      "op": "COUNT",
+      "as": "entity_count"
+    },
+    {
+      "op": "ORDER",
+      "columns": [{ "column": "entity_count", "sortDescending": true }]
+    },
+    {
+      "op": "KEEP",
+      "columns": ["vertex.attr.type", "entity_count"]
+    }
+  ],
+  "limit": 20
+}