docs: pipeline: router: general doc updates and cleanup

pipeline/router.md

@@ -31,7 +31,7 @@ Tag-based routing is the traditional routing mechanism in Fluent Bit. It relies
 - **Tag**: A human-readable identifier assigned to data at the input stage
 - **Match**: A pattern rule configured on outputs to select which tagged data to receive
 
-When data is generated by an input plugin, it comes with a `Tag`. The tag is usually configured manually in the input configuration. To define where to route data, specify a `Match` rule in the output configuration.
+When data is generated by an input plugin, it comes with a `tag`. The tag is usually configured manually in the input configuration. To define where to route data, specify a `match` rule in the output configuration.
 
 ### Basic tag matching
 
@@ -81,7 +81,7 @@ pipeline:
 {% endtab %}
 {% endtabs %}
 
-Routing reads the `Input` `Tag` and the `Output` `Match` rules. If data has a `Tag` that doesn't match at routing time, the data is deleted.
+Routing reads the `input` `tag` and the `output` `match` rules. If data has a `tag` that doesn't match at routing time, the data is deleted.
 
 ### Routing with wildcards
 
@@ -124,11 +124,11 @@ pipeline:
 {% endtab %}
 {% endtabs %}
 
-The match rule is set to `my_*`, which matches any Tag starting with `my_`.
+The match rule is set to `my_*`, which matches any tag starting with `my_`.
 
 ### Routing with regular expressions
 
-Routing also provides support for regular expressions with the `Match_Regex` pattern, allowing for more complex and precise matching criteria. The following example demonstrates how to route data from sources based on a regular expression:
+Routing also provides support for regular expressions with the `match_regex` pattern, allowing for more complex and precise matching criteria. The following example demonstrates how to route data from sources based on a regular expression:
 
 {% tabs %}
 {% tab title="fluent-bit.yaml" %}
@@ -161,13 +161,13 @@ pipeline:
 
 [OUTPUT]
   Name         stdout
-  Match_regex  .*_sensor_[AB]
+  Match_Regex  .*_sensor_[AB]
 ```
 
 {% endtab %}
 {% endtabs %}
 
-In this configuration, the `Match_regex` rule is set to `.*_sensor_[AB]`. This regular expression matches any `Tag` that ends with `_sensor_A` or `_sensor_B`, regardless of what precedes it. This approach provides a more flexible and powerful way to handle different source tags with a single routing rule.
+In this configuration, the `match_regex` rule is set to `.*_sensor_[AB]`. This regular expression matches any `Tag` that ends with `_sensor_A` or `_sensor_B`, regardless of what precedes it. This approach provides a more flexible and powerful way to handle different source tags with a single routing rule.
 
 ## Conditional routing
 
@@ -245,24 +245,24 @@ pipeline:
 
 | Parameter | Description |
 | --- | --- |
-| `name` | A unique identifier for the route. |
 | `condition` | The condition block that determines which records match this route. |
+| `condition.default` | When set to `true`, this route matches all records that don't match other routes. |
 | `condition.op` | The logical operator for combining multiple rules. Valid values are `and` or `or`. |
 | `condition.rules` | An array of rules to evaluate against each record. |
-| `condition.default` | When set to `true`, this route matches all records that don't match other routes. |
-| `to.outputs` | An array of output names or aliases to send matching records to. |
+| `name` | A unique identifier for the route. |
 | `per_record_routing` | When set to `true`, enables per-record evaluation. Defaults to `false`. |
+| `to.outputs` | An array of output names or aliases to send matching records to. |
 
 ### Condition rules
 
 Each rule in the `condition.rules` array must include:
 
 | Parameter | Description |
 | --- | --- |
+| `context` | Optional. Specifies where to look for the field. See the Context types section. Defaults to `body`. |
 | `field` | The field within your logs to evaluate. Uses [record accessor syntax](../administration/configuring-fluent-bit/classic-mode/record-accessor.md). |
 | `op` | The comparison operator. |
 | `value` | This is the value to compare against. It can be a single value or an array for `in` and `not_in` operators. |
-| `context` | Optional. Specifies where to look for the field. See the Context types section. Defaults to `body`. |
 
 ### Context types
 
@@ -271,9 +271,9 @@ The `context` parameter determines where Fluent Bit looks for the field when eva
 | Context | Description |
 | --- | --- |
 | `body` | The main record body containing the log message and fields. This is the default context. |
-| `metadata` | Record-level metadata associated with individual records. |
-| `group_metadata` | Group-level metadata shared across records in the same group. |
 | `group_attributes` | Group-level attributes shared across records in the same group. |
+| `group_metadata` | Group-level metadata shared across records in the same group. |
+| `metadata` | Record-level metadata associated with individual records. |
 | `otel_resource_attributes` | OpenTelemetry resource attributes that identify the entity producing telemetry. |
 | `otel_scope_attributes` | OpenTelemetry scope attributes that identify the instrumentation scope. |
 | `otel_scope_metadata` | OpenTelemetry scope metadata containing scope name, version, and other scope information. |
@@ -285,15 +285,15 @@ The following comparison operators are available for condition rules:
 | Operator | Description |
 | --- | --- |
 | `eq` | Equal to |
-| `neq` | Not equal to |
 | `gt` | Greater than |
-| `lt` | Less than |
 | `gte` | Greater than or equal to |
-| `lte` | Less than or equal to |
-| `regex` | Matches a regular expression |
-| `not_regex` | Doesn't match a regular expression |
 | `in` | Is included in the specified array |
+| `lt` | Less than |
+| `lte` | Less than or equal to |
+| `neq` | Not equal to |
 | `not_in` | Isn't included in the specified array |
+| `not_regex` | Doesn't match a regular expression |
+| `regex` | Matches a regular expression |
 
 ## Conditional routing examples