elastic · craigtaverner · Mar 13, 2025 · Mar 5, 2025 · Mar 5, 2025 · Mar 5, 2025
diff --git a/docs/docset.yml b/docs/docset.yml
@@ -2,8 +2,8 @@ project: 'Elasticsearch'
 exclude:
   - README.md
   - internal/*
-  - reference/esql/functions/kibana/docs/*
-  - reference/esql/functions/README.md
+  - reference/query-languages/esql/kibana/docs/**
+  - reference/query-languages/esql/README.md
 cross_links:
   - beats
   - cloud

diff --git a/...ns/_snippets/search-aggregations-metrics-cardinality-aggregation-explanation.md b/...ns/_snippets/search-aggregations-metrics-cardinality-aggregation-explanation.md
@@ -0,0 +1,17 @@
+* configurable precision, which decides on how to trade memory for accuracy,
+* excellent accuracy on low-cardinality sets,
+* fixed memory usage: no matter if there are tens or billions of unique values, memory usage only depends on the configured precision.
+
+For a precision threshold of `c`, the implementation that we are using requires about `c * 8` bytes.
+
+The following chart shows how the error varies before and after the threshold:
+
+![cardinality error](/images/cardinality_error.png "")
+
+For all 3 thresholds, counts have been accurate up to the configured threshold. Although not guaranteed,
+this is likely to be the case. Accuracy in practice depends on the dataset in question. In general,
+most datasets show consistently good accuracy. Also note that even with a threshold as low as 100,
+the error remains very low (1-6% as seen in the above graph) even when counting millions of items.
+
+The HyperLogLog++ algorithm depends on the leading zeros of hashed values, the exact distributions of
+hashes in a dataset can affect the accuracy of the cardinality.
diff --git a/...es/esql/_snippets/functions/percentile.md → ...ics-percentile-aggregation-approximate.md b/...es/esql/_snippets/functions/percentile.md → ...ics-percentile-aggregation-approximate.md
@@ -1,60 +1,3 @@
-## `PERCENTILE` [esql-percentile]
-
-**Syntax**
-
-:::{image} ../../../../../images/percentile.svg
-:alt: Embedded
-:class: text-center
-:::
-
-**Parameters**
-
-true
-**Description**
-
-Returns the value at which a certain percentage of observed values occur. For example, the 95th percentile is the value which is greater than 95% of the observed values and the 50th percentile is the `MEDIAN`.
-
-**Supported types**
-
-| number | percentile | result |
-| --- | --- | --- |
-| double | double | double |
-| double | integer | double |
-| double | long | double |
-| integer | double | double |
-| integer | integer | double |
-| integer | long | double |
-| long | double | double |
-| long | integer | double |
-| long | long | double |
-
-**Examples**
-
-```esql
-FROM employees
-| STATS p0 = PERCENTILE(salary,  0)
-     , p50 = PERCENTILE(salary, 50)
-     , p99 = PERCENTILE(salary, 99)
-```
-
-| p0:double | p50:double | p99:double |
-| --- | --- | --- |
-| 25324 | 47003 | 74970.29 |
-
-The expression can use inline functions. For example, to calculate a percentile of the maximum values of a multivalued column, first use `MV_MAX` to get the maximum value per row, and use the result with the `PERCENTILE` function
-
-```esql
-FROM employees
-| STATS p80_max_salary_change = PERCENTILE(MV_MAX(salary_change), 80)
-```
-
-| p80_max_salary_change:double |
-| --- |
-| 12.132 |
-
-
-### `PERCENTILE` is (usually) approximate [esql-percentile-approximate]
-
 There are many different algorithms to calculate percentiles. The naive implementation simply stores all the values in a sorted array. To find the 50th percentile, you simply find the value that is at `my_array[count(my_array) * 0.5]`.
 
 Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
@@ -72,11 +15,3 @@ The following chart shows the relative error on a uniform distribution depending
 ![percentiles error](/images/percentiles_error.png "")
 
 It shows how precision is better for extreme percentiles. The reason why error diminishes for large number of values is that the law of large numbers makes the distribution of values more and more uniform and the t-digest tree can do a better job at summarizing it. It would not be the case on more skewed distributions.
-
-::::{warning}
-`PERCENTILE` is also [non-deterministic](https://en.wikipedia.org/wiki/Nondeterministic_algorithm). This means you can get slightly different results using the same data.
-
-::::
-
-
-
diff --git a/...ta-analysis/aggregations/search-aggregations-metrics-cardinality-aggregation.md b/...ta-analysis/aggregations/search-aggregations-metrics-cardinality-aggregation.md
@@ -65,19 +65,8 @@ Computing exact counts requires loading values into a hash set and returning its
 
 This `cardinality` aggregation is based on the [HyperLogLog++](https://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/40671.pdf) algorithm, which counts based on the hashes of the values with some interesting properties:
 
-* configurable precision, which decides on how to trade memory for accuracy,
-* excellent accuracy on low-cardinality sets,
-* fixed memory usage: no matter if there are tens or billions of unique values, memory usage only depends on the configured precision.
-
-For a precision threshold of `c`, the implementation that we are using requires about `c * 8` bytes.
-
-The following chart shows how the error varies before and after the threshold:
-
-![cardinality error](../../../images/cardinality_error.png "")
-
-For all 3 thresholds, counts have been accurate up to the configured threshold. Although not guaranteed, this is likely to be the case. Accuracy in practice depends on the dataset in question. In general, most datasets show consistently good accuracy. Also note that even with a threshold as low as 100, the error remains very low (1-6% as seen in the above graph) even when counting millions of items.
-
-The HyperLogLog++ algorithm depends on the leading zeros of hashed values, the exact distributions of hashes in a dataset can affect the accuracy of the cardinality.
+:::{include} _snippets/search-aggregations-metrics-cardinality-aggregation-explanation.md
+:::
 
 
 ## Pre-computed hashes [_pre_computed_hashes]

diff --git a/...ata-analysis/aggregations/search-aggregations-metrics-percentile-aggregation.md b/...ata-analysis/aggregations/search-aggregations-metrics-percentile-aggregation.md
@@ -175,31 +175,14 @@ GET latency/_search
 
 ## Percentiles are (usually) approximate [search-aggregations-metrics-percentile-aggregation-approximation]
 
-There are many different algorithms to calculate percentiles. The naive implementation simply stores all the values in a sorted array. To find the 50th percentile, you simply find the value that is at `my_array[count(my_array) * 0.5]`.
-
-Clearly, the naive implementation does not scale — the sorted array grows linearly with the number of values in your dataset. To calculate percentiles across potentially billions of values in an Elasticsearch cluster, *approximate* percentiles are calculated.
-
-The algorithm used by the `percentile` metric is called TDigest (introduced by Ted Dunning in [Computing Accurate Quantiles using T-Digests](https://github.com/tdunning/t-digest/blob/master/docs/t-digest-paper/histo.pdf)).
-
-When using this metric, there are a few guidelines to keep in mind:
-
-* Accuracy is proportional to `q(1-q)`. This means that extreme percentiles (e.g. 99%) are more accurate than less extreme percentiles, such as the median
-* For small sets of values, percentiles are highly accurate (and potentially 100% accurate if the data is small enough).
-* As the quantity of values in a bucket grows, the algorithm begins to approximate the percentiles. It is effectively trading accuracy for memory savings. The exact level of inaccuracy is difficult to generalize, since it depends on your data distribution and volume of data being aggregated
-
-The following chart shows the relative error on a uniform distribution depending on the number of collected values and the requested percentile:
-
-![percentiles error](../../../images/percentiles_error.png "")
-
-It shows how precision is better for extreme percentiles. The reason why error diminishes for large number of values is that the law of large numbers makes the distribution of values more and more uniform and the t-digest tree can do a better job at summarizing it. It would not be the case on more skewed distributions.
+:::{include} /reference/data-analysis/aggregations/_snippets/search-aggregations-metrics-percentile-aggregation-approximate.md
+:::
 
 ::::{warning}
 Percentile aggregations are also [non-deterministic](https://en.wikipedia.org/wiki/Nondeterministic_algorithm). This means you can get slightly different results using the same data.
-
 ::::
 
 
-
 ## Compression [search-aggregations-metrics-percentile-aggregation-compression]
 
 Approximate algorithms must balance memory utilization with estimation accuracy. This balance can be controlled using a `compression` parameter:

diff --git a/docs/reference/esql/functions/README.md b/docs/reference/esql/functions/README.md
diff --git a/docs/reference/esql/functions/kibana/docs/not_rlike.md b/docs/reference/esql/functions/kibana/docs/not_rlike.md
diff --git a/docs/reference/esql/functions/kibana/inline_cast.json b/docs/reference/esql/functions/kibana/inline_cast.json
diff --git a/docs/reference/query-languages/esql/README.md b/docs/reference/query-languages/esql/README.md
@@ -0,0 +1,50 @@
+The ES|QL documentation is composed of static content and generated content.
+The static content exists in this directory and can be edited by hand.
+However, the sub-directories `_snippets`, `images` and `kibana` contain mostly
+generated content.
+
+### _snippets
+
+In `_snippets` there are files that can be included within other files
+using the [File Inclusion](https://elastic.github.io/docs-builder/syntax/file_inclusion/)
+feature of the Elastic Docs V3 system.
+Most, but not all, files in this directory are generated.
+In particular the directories `_snippets/functions/*` and `_snippets/operators/*`
+contain subdirectories that are mostly generated:
+
+* `description` - description of each function scraped from `@FunctionInfo#description`
+* `examples` - examples of each function scraped from `@FunctionInfo#examples`
+* `parameters` - description of each function's parameters scraped from `@Param`
+* `signature` - railroad diagram of the syntax to invoke each function
+* `types` - a table of each combination of support type for each parameter. These are generated from tests.
+* `layout` - a fully generated description for each function
+
+Most functions can use the generated docs generated in the `layout` directory.
+If we need something more custom for the function we can make a file in this
+directory that can `include::` any parts of the files above.
+
+To regenerate the files for a function run its tests using gradle.
+For example to generate docs for the `CASE` function:
+```
+./gradlew :x-pack:plugin:esql:test -Dtests.class='CaseTests'
+```
+
+To regenerate the files for all functions run all of ESQL's tests using gradle:
+```
+./gradlew :x-pack:plugin:esql:test
+```
+
+### images
+
+The `images` directory contains `functions` and `operators` sub-directories with
+the `*.svg` files used to describe the syntax of each function or operator.
+These are all generated by the same tests that generate the functions and operators docs above.
+
+### kibana
+
+The `kibana` directory contains `definition` and `docs` sub-directories that are generated:
+
+* `kibana/definition` - function definitions for kibana's ESQL editor
+* `kibana/docs` - the inline docs for kibana
+
+These are also generated as part of the unit tests described above.
diff --git a/docs/reference/query-languages/esql/_snippets/aggregation-functions-new.md b/docs/reference/query-languages/esql/_snippets/aggregation-functions-new.md