Anomaly Detection Score Explainer

Explain anomaly scores, model behavior, and why results look the way they do. Use the ML REST API for job config and the standard _search API against .ml-anomalies-* for results, no ES|QL, fully compatible with Elastic Serverless. For job lifecycle (create, start, stop), use the elasticsearch-anomaly-detection skill.

<!-- begin-partial: preamble -->

Environment Configuration

This skill executes Elasticsearch operations through the elastic CLI. If the elastic CLI is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g., GET /, GET /_cat/indices, GET /{index}/_mapping, GET /{index}/_settings/index.mode, POST /_query). The Operations table at the end of this document maps each shorthand to the equivalent elastic CLI command, always use the CLI rather than calling the HTTP API directly.

<!-- end-partial: preamble -->

Prerequisite: ML anomaly detection requires a Platinum-equivalent license on self-managed clusters. Serverless projects include ML. The caller needs monitor_ml to read job config and anomaly results.

Serverless note: The _ml/.../results/* REST endpoints return HTTP 410 in Elastic Serverless. Always use POST /.ml-anomalies-*/_search for result queries instead, fully supported everywhere this skill runs.

Process

1. Decide whether to fetch data or interpret what the user supplied. If the user embeds an anomaly record (or job config) in the prompt, interpret it directly using the domain knowledge below, do not call APIs to re-fetch fields already present. If the job ID, time range, or record is missing, retrieve it from the cluster.