Usage

You can use the apply operator to compute predictions for the current search results based on a model that was learned using the fit operator. The apply operator must include one or more explanatory fields (independent variables).

The output will include all the input fields and the predicted field(s), helping you analyze the prediction results. Additionally, you can use the ml_model_summary operator to store these explanatory fields when creating the model for future reference.

apply also supports explicit feature field selection. See Support for explicit arguments for more information.

Examples

Example 1: Training with Context, Applying with Context

In the following example, you train a Birch clustering model on authentication behavior.

Training a model

Here, date_day_num and date_hour are used features, while also keeping src_ip and sourcetype in the training data:

calc date_hour = strftime(event_time, "%H")
calc date_hour = tonumber(date_hour)
calc date_day = strftime(event_time, "%a")
calc date_day_num = case(
  date_day = "Sun", 0,
  date_day = "Mon", 1,
  date_day = "Tue", 2,
  date_day = "Wed", 3,
  date_day = "Thu", 4,
  date_day = "Fri", 5,
  date_day = "Sat", 6
)
aggr count as login_count by src_ip, sourcetype, date_day_num, date_hour
fit Birch login_count from date_day_num date_hour into "birch_with_context"

Applying the model while preserving context

After training, you want to apply the same model and keep src_ip and sourcetype in the output, along with the model scores:

calc date_hour = strftime(event_time, "%H")
calc date_hour = tonumber(date_hour)
calc date_day = strftime(event_time, "%a")
calc date_day_num = case(
  date_day = "Sun", 0,
  date_day = "Mon", 1,
  date_day = "Tue", 2,
  date_day = "Wed", 3,
  date_day = "Thu", 4,
  date_day = "Fri", 5,
  date_day = "Sat", 6
)
aggr count as login_count by src_ip, sourcetype, date_day_num, date_hour
apply birch_with_context date_day_num date_hour

In the apply phase:

• date_day_num and date_hour are explicitly passed as features to the birch_with_context model.

• src_ip, sourcetype, and login_count remain in the result as context columns.

• The output includes all of the above plus the model’s output fields (for example, cluster assignment, anomaly score).

Example 2: Anomalous Authentication Detection with Full Context

This example shows a typical workflow where you:

• Aggregate authentication events.

• Compute behavioral features.

• Apply a saved ML model.

• Investigate anomalies with full user and device context.

Step 1–2: Aggregate and build features

aggr count as total_logins,
     sum(failure_count) as failure_count,
     dc(src_ip) as unique_ips,
     dc(country) as unique_countries,
     sum(weekend_logins) as weekend_logins,
     sum(night_logins) as night_logins,
     avg(ti_score) as avg_ti_score
  by user, device_id, time_bucket
calc failure_rate = failure_count / total_logins
calc weekend_rate = weekend_logins / total_logins
calc night_rate = night_logins / total_logins

Step 3: Apply the model with explicit features

Instead of stripping context columns with fields, call apply with the feature list:

apply azuread_scaler_jan26
      total_logins
      failure_rate
      unique_ips
      unique_countries
      weekend_rate
      night_rate
      avg_ti_score

In this example:

• The model uses the 7 listed fields as features.

• Context fields such as user, device_id, time_bucket, src_ip, and country remain in the pipeline.

• The model outputs additional columns, such as anomaly_score and prediction.

Step 4: Investigate anomalies

You can now filter and sort directly, without any re-joins:

where prediction = -1
sort anomaly_score desc
fields user, device_id, time_bucket, anomaly_score, prediction, failure_rate

This produces results such as:

USER        | DEVICE_ID   | TIME_BUCKET | ANOMALY_SCORE | PREDICTION | FAILURE_RATE
------------+-------------+-------------+---------------+------------+-------------
john.doe    | laptop-001  | 2026-01-29  | 87.3          | -1         | 0.45
jane.smith  | mobile-042  | 2026-01-28  | 92.1          | -1         | 0.67

You retain all the information needed to:

• Identify the affected users and devices.

• Understand when and where anomalies occurred.

• Take follow-up action (for example, pivot to raw events for the same user/device/time window).

Best Practices

Prefer explicit features

Where applicable, use explicit features for machine learning use cases, instead of using fields to drop context columns before apply.

Copy

... | apply my_model feature1 feature2 feature3

Keep identifiers and metadata in your aggregations

Wherever applicable, include user-related identifier fields in your aggregation clause, helping you preserve and leverage context for downstream analysis or scoring.

Use legacy behavior only when necessary

If you omit explicit feature names, apply will still attempt to use all columns as input to the model. This is only recommended if your pipeline exactly matches the schema used during training.