log10x-mcp 1.30.19 → 1.30.21

package/build/product-kb/docs/engine/launcher/extension.md

@@ -93,14 +93,14 @@ The [log10x MCP](https://doc.log10x.com/apps/mcp/) emits this entire plan from a
     The layer is published in every region below, for both architectures, and
     is readable by any AWS account. Nothing to build.
 
-    **Engine 1.1.75, republished 2026-09-07.** Every layer below carries the
+    **Engine 1.1.79, republished 2026-09-17.** Every layer below carries the
     same build, so there is one digest per architecture rather than one per
     region:
 
     | Architecture | `CodeSha256` |
     |---|---|
-    | x86_64 | `CrxpplzMzotOH8FUpGYV4bETI4OWAGfpWu0MddnSK/M=` |
-    | arm64 | `2shOwbaBd2H1+yUl1J+aWjb+HAC7Ql/lXzrlc0OfVgo=` |
+    | x86_64 | `ACkSX/XS5nei+rAm6eiKyyxabq3lwcAqvAeFu437dDo=` |
+    | arm64 | `DbhgTftIcnzEi+SenwH+YMotPX11sIavGQb6o17IBkU=` |
 
     `aws lambda get-layer-version` returns that digest to any caller, so you can
     check what you are about to attach:
@@ -108,20 +108,20 @@ The [log10x MCP](https://doc.log10x.com/apps/mcp/) emits this entire plan from a
     ``` { .console .copy }
     aws lambda get-layer-version --region us-east-1 \
       --layer-name arn:aws:lambda:us-east-1:351939435334:layer:tenx-receive \
-      --version-number 7 --query Content.CodeSha256 --output text
+      --version-number 8 --query Content.CodeSha256 --output text
     ```
 
 
     | Region | x86_64 | arm64 |
     |---|---|---|
-    | `us-east-1` | `arn:aws:lambda:us-east-1:351939435334:layer:tenx-receive:7` | `arn:aws:lambda:us-east-1:351939435334:layer:tenx-receive-arm64:3` |
-    | `us-east-2` | `arn:aws:lambda:us-east-2:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:us-east-2:351939435334:layer:tenx-receive-arm64:3` |
-    | `us-west-2` | `arn:aws:lambda:us-west-2:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:us-west-2:351939435334:layer:tenx-receive-arm64:3` |
-    | `eu-west-1` | `arn:aws:lambda:eu-west-1:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:eu-west-1:351939435334:layer:tenx-receive-arm64:3` |
-    | `eu-central-1` | `arn:aws:lambda:eu-central-1:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:eu-central-1:351939435334:layer:tenx-receive-arm64:3` |
-    | `ap-southeast-1` | `arn:aws:lambda:ap-southeast-1:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:ap-southeast-1:351939435334:layer:tenx-receive-arm64:3` |
-    | `ap-northeast-1` | `arn:aws:lambda:ap-northeast-1:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:ap-northeast-1:351939435334:layer:tenx-receive-arm64:3` |
-    | `ap-south-1` | `arn:aws:lambda:ap-south-1:351939435334:layer:tenx-receive:3` | `arn:aws:lambda:ap-south-1:351939435334:layer:tenx-receive-arm64:3` |
+    | `us-east-1` | `arn:aws:lambda:us-east-1:351939435334:layer:tenx-receive:8` | `arn:aws:lambda:us-east-1:351939435334:layer:tenx-receive-arm64:4` |
+    | `us-east-2` | `arn:aws:lambda:us-east-2:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:us-east-2:351939435334:layer:tenx-receive-arm64:4` |
+    | `us-west-2` | `arn:aws:lambda:us-west-2:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:us-west-2:351939435334:layer:tenx-receive-arm64:4` |
+    | `eu-west-1` | `arn:aws:lambda:eu-west-1:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:eu-west-1:351939435334:layer:tenx-receive-arm64:4` |
+    | `eu-central-1` | `arn:aws:lambda:eu-central-1:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:eu-central-1:351939435334:layer:tenx-receive-arm64:4` |
+    | `ap-southeast-1` | `arn:aws:lambda:ap-southeast-1:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:ap-southeast-1:351939435334:layer:tenx-receive-arm64:4` |
+    | `ap-northeast-1` | `arn:aws:lambda:ap-northeast-1:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:ap-northeast-1:351939435334:layer:tenx-receive-arm64:4` |
+    | `ap-south-1` | `arn:aws:lambda:ap-south-1:351939435334:layer:tenx-receive:4` | `arn:aws:lambda:ap-south-1:351939435334:layer:tenx-receive-arm64:4` |
 
     Match the architecture to the function's own: `arm64` for Graviton,
     `x86_64` otherwise. A mismatch fails at INIT rather than silently.
@@ -245,19 +245,19 @@ The [log10x MCP](https://doc.log10x.com/apps/mcp/) emits this entire plan from a
     The published layer suits every case except one: baking a static mute file into the image, which pins the policy to the layer version. Build it from the release artifacts:
 
     ``` { .console .copy }
-    gh release download 1.1.69 -R log-10x/pipeline-releases \
-      -p 'tenx-edge-1.1.69-amd64-native' -p 'tenx-modules-1.1.69.tar.gz' \
-      -p 'tenx-config-1.1.69.tar.gz' -p 'tenx-symbols-1.1.69.10x.tar' \
+    gh release download 1.1.79 -R log-10x/pipeline-releases \
+      -p 'tenx-edge-1.1.79-amd64-native' -p 'tenx-modules-1.1.79.tar.gz' \
+      -p 'tenx-config-1.1.79.tar.gz' -p 'tenx-symbols-1.1.79.10x.tar' \
       -p 'build-receive-layer.sh'
 
     mkdir modules config symbols
-    tar xzf tenx-modules-1.1.69.tar.gz -C modules
-    tar xzf tenx-config-1.1.69.tar.gz -C config
-    cp tenx-symbols-1.1.69.10x.tar symbols/
+    tar xzf tenx-modules-1.1.79.tar.gz -C modules
+    tar xzf tenx-config-1.1.79.tar.gz -C config
+    cp tenx-symbols-1.1.79.10x.tar symbols/
 
     chmod +x build-receive-layer.sh
     ./build-receive-layer.sh \
-      ./tenx-edge-1.1.69-amd64-native ./modules ./config ./symbols \
+      ./tenx-edge-1.1.79-amd64-native ./modules ./config ./symbols \
       ./tenx-receive.zip \
       ./mutes.csv                  # the 6th argument is the policy file
 
@@ -268,4 +268,4 @@ The [log10x MCP](https://doc.log10x.com/apps/mcp/) emits this entire plan from a
       --content S3Bucket=<your-bucket>,S3Key=layers/tenx-receive.zip
     ```
 
-    Swap the bootstrap for `tenx-edge-1.1.69-aarch64-native` and the architecture for `arm64` to build the Graviton variant. With a mute file present the build validates every entry and refuses a malformed one, rather than shipping a disposition that would be silently skipped.
+    Swap the bootstrap for `tenx-edge-1.1.79-aarch64-native` and the architecture for `arm64` to build the Graviton variant. With a mute file present the build validates every entry and refuses a malformed one, rather than shipping a disposition that would be silently skipped.

package/build/product-kb/docs/faq/apps/receiver.md

@@ -22,7 +22,7 @@ The [Receiver](https://doc.log10x.com/apps/receiver/) is the execution arm of th
 
     - **pass**: forward unchanged.
     - **sample**: forward a rate-limited share against a per-pattern budget. Uses automatic [message enrichment](https://doc.log10x.com/run/initialize/message/){target="_blank"} to identify event types by their symbol identity and calculate ingestion cost per event (bytes × $/GB). When an event type exceeds its share of the budget, the Receiver samples it down, in real time at the source, before expensive data reaches your analyzer. A [severity floor](https://doc.log10x.com/run/receive/rate/){target="_blank"} keeps a minimum share of ERROR and WARN events flowing even when their pattern is over its cap.
-    - **compact**: replace repeated lines with an encoded form the destination expands at query time, with no dashboard or query changes. Lossless only on Splunk and self-hosted Elasticsearch/OpenSearch with the expand plugin installed ([Splunk](../../apps/receiver/compact/splunk.md), [Elasticsearch](../../apps/receiver/compact/elasticsearch.md)). It is a no-op on managed/SaaS destinations (Datadog, CloudWatch, Azure, GCP, Sumo, managed Elasticsearch).
+    - **compact**: replace repeated lines with an encoded form the destination expands at query time, with no dashboard changes. Lossless only on Splunk and self-hosted Elasticsearch/OpenSearch with the expand plugin installed ([Splunk](../../apps/receiver/compact/splunk.md), [Elasticsearch](../../apps/receiver/compact/elasticsearch.md)). It is a no-op on managed/SaaS destinations (Datadog, CloudWatch, Azure, GCP, Sumo, managed Elasticsearch).
     - **tier_down**: tag the pattern for a cheaper storage tier the destination enforces (Datadog Flex, CloudWatch IA, Azure Monitor Basic/Auxiliary).
     - **offload**: route the pattern to customer-owned object storage (S3 or any S3-compatible bucket) instead of the destination.
     - **drop**: stop forwarding the pattern.

package/build/product-kb/docs/faq/stacks/aws-cloudwatch.md

@@ -51,7 +51,9 @@ Cut [CloudWatch](https://www.log10x.com/aws-cloudwatch.html){target="_blank"} co
 
     **CloudWatch charges $0.50/GB for log ingestion** (us-east-1), the single biggest line item for most teams. A 10TB/month environment pays $5,000/month just to ingest.
 
-    **Down-tier to a cheaper log group:** route the low-value slice to a [CloudWatch Logs Infrequent Access](https://aws.amazon.com/cloudwatch/pricing/){target="_blank"} log group at $0.25/GB ingest (50% off the $0.50 standard) and $0.0075/GB-month storage, still queryable in Logs Insights. Down-tiering half of a 10TB/month volume saves ~$1,250/month on ingest alone (5TB x $0.25 saved).
+    **Down-tier to a cheaper log group:** route the low-value slice to a [CloudWatch Logs Infrequent Access](https://aws.amazon.com/cloudwatch/pricing/){target="_blank"} log group at $0.25/GB ingest, 50% off the $0.50 standard, still queryable in Logs Insights. The saving is ingest-side only: AWS bills storage and Logs Insights queries at the same rate in both log classes. Down-tiering half of a 10TB/month volume saves ~$1,250/month (5TB x $0.25 saved).
+
+    Before down-tiering a log group, check what reads it. An Infrequent Access group serves Logs Insights, but not subscription filters, metric filters, Live Tail, field indexing, or the `GetLogEvents` and `FilterLogEvents` APIs. A consumer on any of those stops returning events with no error. The log class is fixed when the group is created, so the slice moves to a new IA group rather than converting the one already in place.
 
     **Offload to your own S3:** route the bulk slice to customer-owned S3 at $0.023/GB-month and fetch it back with [Retriever](https://log10x.com/retriever.html){target="_blank"} only when you query. For compliance and archival profiles where most volume is offloaded, total savings reach an estimated 80%+.
 

package/build/product-kb/docs/faq/stacks/splunk/optimization.md

@@ -30,13 +30,13 @@ How the 10x for Splunk app expands compact events at search time, search-time ov
     - Top templates by usage
     - Expansion success rate
 
-    **User experience:** Interactive search and dashboards are completely transparent, on the original full-fidelity data. Scheduled alerts are compiled once at save time into a native saved search that then runs on the same expanded data.
+    **User experience:** Classic dashboards keep their panel SPL unchanged. From the search bar a query is wrapped in the app's `tenxsearch` command, since Splunk's search page loads no app JavaScript. Scheduled alerts are compiled once at save time into a native saved search. All three read the original full-fidelity data.
 
     **Open source:** Available on [GitHub](https://github.com/log-10x/splunk-app){target="_blank"}.
 
 ??? tenx-costopt "What is the search-time overhead in Splunk"
 
-    A one-time template resolution matches search terms against the templates. Per-event expansion uses a KV Store primary-key lookup and native SPL functions, negligible overhead per event. Queries and dashboards work unchanged; scheduled alerts run unchanged after a one-time save-time compile.
+    A one-time template resolution matches search terms against the templates. Per-event expansion uses a KV Store primary-key lookup and native SPL functions, negligible overhead per event. Dashboard panels keep their SPL; a search-bar query carries the `tenxsearch` wrapper; scheduled alerts run unchanged after a one-time save-time compile.
 
     The 10x Engine processes events at sub-millisecond per event, 100+ GB/day on a single node (512 MB heap, 2 threads). For resource requirements and Kubernetes resource specs, see [Node counting](https://doc.log10x.com/faq/pricing/node-counting/).
 

package/build/product-kb/docs/run/bootstrap/index.md

@@ -179,8 +179,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # 'disabledArgs' specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []
@@ -357,8 +359,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []
@@ -798,8 +802,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # 'disabledArgs' specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []
@@ -976,8 +982,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []
@@ -1417,8 +1425,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # 'disabledArgs' specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []
@@ -1595,8 +1605,10 @@ To configure the Pipeline Bootstrapper unit, [:material-cog: Edit](https://doc.l
     # 'jarFiles' specifies .jar files to dynamically load for use by compile, input and output API extensions.
     jarFiles: []
     
-    # 'metricEndpoint' specifies the Prometheus endpoint to report usage/health metrics (enterprise version only).
-    # metricEndpoint: https://prometheus.log10x.com/api/v1/write
+    # 'metricEndpoint' specifies a Prometheus remote-write endpoint for pipeline usage and health metrics.
+    # Unset by default. The endpoint is a self-hosted or vendor Prometheus-compatible store, never a 10x
+    # service, and is where the MCP reads engine state back from to tune policy such as regulator rates.
+    # metricEndpoint: https://prometheus.example.com/api/v1/write
     
     # specifies a list of launch arguments that are disallowed from either command line or user config files.
     disabledArgs: []

package/build/product-kb/docs/run/initialize/message/index.md

@@ -15,16 +15,33 @@ The message initializer uses symbol libraries to isolate stable [message pattern
 
 Every token the symbol library recognizes carries a set of candidate origins: the source unit, a file or a binary, that can emit the token, together with the enclosing scope the library recorded for it. A token emitted by many units resolves to many candidates, so ambiguity is the normal case and resolving it is the selector's job. Candidates are keyed by originating unit plus enclosing scope, so symbols sharing an origin and a scope coalesce into one candidate.
 
-The initializer identifies the core message pattern by ranking those candidates from a [TenXTemplate](https://doc.log10x.com/run/template/ "Import joint JSON schemas files to expand events into well-defined TenXObjects.") **by coverage**, on a four-key comparator, every key descending:
+The initializer identifies the core message pattern by ranking those candidates from a [TenXTemplate](https://doc.log10x.com/run/template/ "Import joint JSON schemas files to expand events into well-defined TenXObjects."), on a five-key comparator, every key descending:
 
-1. **Widest matched phrase**: a per-field maximum, rather than a sum, over library-matched, multi-character tokens that are not [reserved](https://doc.log10x.com/run/transform/symbol/#symbolsequencereserved "list of terms to ignore when scanning symbol tokens"). This is the widest single library-matched phrase the origin accounts for.
-2. **Distinct known tokens**: the count of distinct library-known tokens anywhere on the line that the origin explains. This is the coverage term, and it decides most events.
-3. **Character total**: the combined character length of those distinct tokens.
-4. **Span length**: the run length of the selected span. This is the only run-length key, it sits last, and the comparator reaches it only when the first three keys all tie.
+1. **Prose evidence**: the width of the candidate's widest matched field that is **not inside a container**. Container depth is counted from the opens and closes preceding the field, so a JSON attribute value that quotes another component's message is excluded here even though it is prose-shaped. This key decides first.
+2. **Widest matched phrase**: a per-field maximum, rather than a sum, over library-matched, multi-character tokens that are not [reserved](https://doc.log10x.com/run/transform/symbol/#symbolsequencereserved "list of terms to ignore when scanning symbol tokens"). This is the widest single library-matched phrase the origin accounts for.
+3. **Distinct known tokens**: the count of distinct library-known tokens anywhere on the line that the origin explains. This is the coverage term.
+4. **Character total**: the combined character length of those distinct tokens.
+5. **Span length**: the run length of the selected span. This is the only run-length key, it sits last, and the comparator reaches it only when the first four keys all tie.
+
+Prose ranks ahead of bulk because text inside a container is citation, not authorship. A twenty-token error value carried as an attribute does not outrank the two-token statement it is attached to.
 
 Coverage ranks ahead of length because the more places a word appears across a code base, the less that word says about where a line came from. A word appearing in one file identifies that file; a word appearing in hundreds identifies nothing. Ranking by how many distinct known words an origin explains picks the origin that best accounts for the line.
 
-Contiguity is a property of the emitted value rather than of the selection. Once a candidate wins, the output spans from the candidate's first field start to its last field end, then pads forward and backward while the [`symbolMaxLen`](#symbolmaxlen "max number of output chars") budget allows. A candidate whose tokens sit in three separate phrases scattered across the line can beat a candidate holding one longer contiguous run.
+One tie-break runs after the ranking rather than as a sixth key. Where the winner ties its nearest rival on all five, the tied group yields to a candidate whose unit the line's own authorship region names.
+
+### Evidence gate
+
+A typed selection ([`symbolContexts`](#symbolcontexts "types of symbols to search") of `log,exec`) claims an origin: this source statement wrote this line. That claim stands on prose evidence exclusively, and a candidate whose prose score is below two is rejected rather than crowned. **A line with no prose evidence gets no typed origin and keeps its raw fallback identity.** The lone `any` context asserts nothing about provenance and gates at one token instead, so thin fragments still receive an identity.
+
+### Emission
+
+Selection picks the origin. Emission then builds the value in three stages.
+
+- **Anchor**: the winner's widest matched prose field, emitted verbatim. The message region runs forward from the anchor's own start and stops at the first container open, newline, or second timestamp; where that boundary falls inside the anchor field the region collapses back to the field. The anchor is **exempt from reserved filtering**: applying it here renames the statement, turning `no baggage found in context` into `no_found`. Timestamps, variables and repeats are still dropped.
+- **Suffix**: distinct non-reserved tokens from the winner's other matched fields, each token counted once however often it repeats, up to a budget of sixteen.
+- **Padding**: forward and backward from the emitted region while the [`symbolMaxLen`](#symbolmaxlen "max number of output chars") budget allows. Reserved filtering governs here and in the suffix, which is where a generic word is genuinely noise. The backward walk stops where the statement starts: at the nearest preceding timestamp, or at a token that closes a container or ends a line. Everything before that point is preamble, the node ids, request ids, thread and logger names a format prints ahead of the message, and it stays out of the pattern.
+
+Every stage, and the `any` fallback below, skips an **identifier fragment**: a library word whose neighbour carries a digit, directly or across a single `-`, `_` or `.`. The `C` in the node id `R21-M0-N4-C:J05-U11` and the `req` in `req-b3e2...` are library words, and skipping them keeps one statement on one identity however its ids are spelled. Detection reads only the line, so the identity stays a function of the line and the library.
 
 The [`symbolContexts`](#symbolcontexts "types of symbols to search") list filters which symbol contexts participate. Contexts are evaluated in a single pass, so list order acts as a filter rather than a precedence chain.
 
@@ -34,9 +51,9 @@ The `inputField` parameter limits searches to specific JSON fields. Setting `inp
 
 The comparator is deterministic: every key is a content-derived integer. Three details bound that behavior.
 
-- A full four-key tie falls back to candidate insertion order, which holds stable for a given engine build and is not a documented ordering.
+- A full five-key tie that the authorship pass also leaves undecided falls back to candidate insertion order, which holds stable for a given engine build and is not a documented ordering.
 - Two truncation caps can hide a true origin: [`symbolMaxOrigins`](https://doc.log10x.com/run/transform/symbol/#symbolmaxorigins "max number of source/binary origins to list per symbol") (default 64, the cap that binds at runtime) and [`maxSymbolUnitsPerToken`](https://doc.log10x.com/run/symbol/#maxsymbolunitspertoken "number of symbol units to retrieve when searching for the origin of an TenXTemplate symbol sequence") (default 128, approximate, stopping in the low 130s).
-- When the selected sequence comes back as a single token, the module re-runs the selection under the `any` context, which concatenates all symbol tokens in range and bypasses the comparator.
+- When the selected sequence comes back as a single token, the module re-runs the selection under the `any` context, which concatenates all symbol tokens in range, minus identifier fragments, and bypasses the comparator.
 
 The claim the engine supports is scoped: the same engine version, the same symbol library, the same configuration and the same event yield the same pattern.
 

package/build/product-kb/docs/run/transform/symbol/index.md

@@ -548,7 +548,7 @@ symbol:
 
     #  Specifying '*' will emit information for all source code /binary files that have
     #  been selected as the origin of any TenXTemplate objects within the pipeline.
-    symbols: [''
+    symbols: [
     #  '*'
     ]
 ```

package/build/product-kb/docs/run/transform/timestamp/index.md

@@ -246,14 +246,21 @@ timestamp:
   - "yyyy-MM-dd HH:mm:ss"                      # Widely used in Java applications, databases (e.g., MySQL, PostgreSQL), and application servers (e.g., Tomcat, JBoss).
   - "yyyy-MM-dd'T'HH:mm:ss.SSSZ"               # Common in web services, APIs, Java (with DateTimeFormatter.ISO_OFFSET_DATE_TIME), Python (with datetime.isoformat()), and systems requiring precise timestamps with timezone information.
   - "MMM dd HH:mm:ss"                          # Frequently seen in syslog, Unix-based systems, network devices (e.g., Cisco routers), and web servers (e.g., Apache, Nginx).
+  - "MMM  d HH:mm:ss"                          # Classic syslog (RFC 3164) on days 1-9: the day is space-padded, e.g. "Jan  3 17:38:36".
+  - "MMM d HH:mm:ss"                           # Same date without the padding (strftime %b %-d), e.g. "Nov 9 12:01:01" in Thunderbird-style system logs.
   - "dd/MMM/yyyy:HH:mm:ss Z"                   # Standard syslog format, used in firewalls (e.g., Cisco ASA, Palo Alto), network monitoring tools, and Unix-based systems.
   - "yyyy-MM-dd HH:mm:ss,SSS"                  # Common in Java logging frameworks like Log4j and Logback.
   - "yyyy-MM-dd'T'HH:mm:ss,SSS"                # Common in Java logging with ISO 8601 date-time, comma-separated milliseconds.
   - "MM/dd/yyyy HH:mm:ss"                      # Used in Windows event logs, .NET applications, and U.S.-based systems.
   - "EEE MMM dd HH:mm:ss yyyy"                 # Human-readable format used in various logs, including some web servers and application logs.
+  - "EEE MMM dd HH:mm:ss zzz yyyy"             # java.util.Date.toString() and the Unix date command, e.g. "Thu Jan 15 10:00:01 UTC 2026". Common in Java application logs and shell-script output.
   - "yyyy-MM-dd'T'HH:mm:ss"                    # Simplified ISO 8601 format, used in many modern applications and frameworks.
   - "HH:mm:ss"                                 # Time-only format, used when the date is implied or provided separately, common in embedded systems and some programming languages.
   - "yyyyMMdd HH:mm:ss"                        # Compact format used in some legacy systems and batch processing logs.
+  - "yyyyMMdd-H:m:s:SSS"                       # Compact date, hyphen, unpadded time, colon before the milliseconds, e.g. "20171223-22:15:29:606" or "20171224-0:0:0:234". Android HealthApp and similar mobile logs.
+  - "yyyyMMdd-H:m:s:SS"                        # Same with two fraction digits, e.g. "20171223-22:30:24:28".
+  - "yyyyMMdd-H:m:s:S"                         # Same with one fraction digit.
+  - "MM.dd HH:mm:ss"                           # Month.day without a year, e.g. "10.30 16:49:06". Proxifier and other Windows utility logs.
   - "MMM dd, yyyy h:mm:ss a"                   # Human-readable format with 12-hour clock, used in application logs and some U.S.-based systems.
   - "MMM dd, yyyy hh:mm:ss a"                  # Human-readable format with 12-hour clock (padded hour), used in application logs and some U.S.-based systems.
   # Common formats with slight variations

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "log10x-mcp",
-  "version": "1.30.19",
+  "version": "1.30.21",
   "description": "Rank log patterns by cost, then compact, tier down or offload them. No log data reaches log10x.",
   "mcpName": "io.github.log-10x/log10x-mcp",
   "type": "module",