Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Anomaly Scan & Diagnosis

Anomaly Scan & Diagnosis answers the question you ask when you don't yet know what is wrong: is anything in this data off — and if so, what caused it? You hand it a set of records, and it checks every variable in each one against what the Digital Twin expects, flags the records that don't fit, and — with one setting enabled — automatically runs Root Cause Analysis on each one it flags.

For the workflow that produces a Digital Twin in the first place, see Step 5: Build Digital Twin.

Anomaly Scan vs. Root Cause Analysis. They are two halves of the same idea. Root Cause Analysis is deliberate: you already know a value looks wrong, name it, and ask for the cause. Anomaly Scan & Diagnosis is the discovery step before that: it watches every variable for you, surfaces the records that don't fit, and then diagnoses each one — so you don't have to know what is wrong to begin with.

How it works: every variable, every record

A trained Digital Twin learns the expected relationships among all the variables, so for any record it can say, for each value: given everything else I know about this record, here is the value I'd expect, and the range it should fall in. The gap between observed and expected is a deviation, measured as a z-score — the number of standard deviations the observation sits from expectation:

  • A z-score near 0 is in line with expectation.

  • |z| ≥ 2 is uncommon (≈1 in 20), |z| ≥ 3 is rare (≈1 in 370), |z| ≥ 4 is extreme (≈1 in 16,000).

Root Cause Analysis scores deviations along the path upstream from one variable you name. Anomaly Scan does the wider job first: it scores every variable in every record you give it, and flags any sample that carries a deviation large enough to clear your sensitivity threshold. Where Auto-RCA is enabled, each flagged sample is then handed to Root Cause Analysis automatically, so the scan returns not just which records are anomalous but why.

Starting a simulation

Open your trained Digital Twin from the Digital Twins list.

A trained Digital Twin open in the platform, showing its causal graph with the Model trained & ready banner and the Configuration, Versions, Simulations, and Model evaluation cards
Anomaly Scan runs against a trained Digital Twin — the same causal model that powers every other simulation type.

Open the twin's Simulations row, click New Simulation, and choose Anomaly Scan & Diagnosis from the type picker.

The empty Anomaly Scan & Diagnosis setup form: Step 1 Observed data with one blank record on the Field Input tab, listing every variable in the twin
The Anomaly Scan setup as it opens. There is no variable to name — the scan checks every variable in every record you provide.

Step 1: Provide the observed data

Supply the records you want to scan. Each row is one independent sample; the system checks every variable in every row. As with Prediction, you can enter records by hand (Field Input), upload a CSV on File Upload, or pull rows from a Dataset.

Fields may be left blank: the scan needs at least one recognized value per record, and validates only that the values you do supply are of the right type. The more of the profile a record carries — services, contract, charges, tenure, the observed outcome — the more variables the scan can check.

The Observed data step on the Dataset tab, listing three datasets to load records from (View of Customer Details, View of Customer Subscription info, and the Customer Subscription info × Customer Details star join), each with 4,998 rows, above the Detection settings step
Observed data on the Dataset tab: pick a dataset and its records load as the samples to scan; here each of the three carries 4,998 rows. Only columns matching the twin's variables are imported. The detection settings follow below.

Step 2: Detection settings (optional)

These tune how sensitive the scan is, and whether it diagnoses on its own.

  • Target false-positive rate — the slider runs from 0.1% (strict) to 5% (loose). A lower rate flags fewer records and reduces false positives; a higher rate flags more. The default is 0.50%.

  • Automatically run root cause analysis on anomalous samples — when ticked, every record the scan flags is passed straight to Root Cause Analysis. This is the Diagnosis in the name: the scan finds the anomaly, the diagnosis explains it. Leave it on unless you only want the flag.

Pick the twin version to run on, review the Configuration Summary, and click Run Simulation.

Running the scan

Scanning every variable across every record — and diagnosing each flagged one — is heavier than a single prediction. Expect a run to take minutes rather than seconds.

The Anomaly Scan run page mid-run, with a Simulation Running progress bar at the Initializing stage and the run list on the right showing only completed runs
The scan in progress — this run scans every variable across 4,998 samples at a 1.00% target FPR with Auto-RCA enabled. Expect minutes, not seconds.

Reading the result

The result opens with the headline verdict — how many anomalies were found across how many samples — followed by the z-score legend and a Samples table. Each anomalous sample is one row, carrying its severity, the variables that were flagged, and (with Auto-RCA on) its diagnosed root cause. Click any row to open its full Root Cause Analysis. Clean samples are hidden by default; toggle Show normal samples to see them.

A completed Anomaly Scan reporting 28 of 4998 samples anomalous, with the z-score legend, the anomaly score distribution, and a chart of the most frequently flagged variables led by TotalCharges and MonthlyCharges
A completed scan. The headline states the count, the charts show where the anomalies sit, and the samples table below lists each flagged record with its diagnosed cause.

In this run, the verdict was 28 of 4,998 samples anomalous:

28 of 4998 samples anomalous. 4998 samples scanned · target FPR: 0.50%.

The two charts unpack that count. The score distribution shows the overwhelming majority of records sitting far below the anomaly threshold, and the most frequently flagged variables chart shows the anomalies concentrating in TotalCharges and MonthlyCharges. With Auto-RCA on, the diagnosis goes a step further: it points to MonthlyCharges as the top cause behind the worst TotalCharges anomalies, so the issue is concentrated around those two variables rather than scattered across the model.

That grounding is the point, and it mirrors Root Cause Analysis: the answer comes from the causal model and the evidence in front of it. When a record genuinely deviates, the scan flags it and, with Auto-RCA, traces the cause. When nothing deviates, it says so. The answer is always defensible, because it never invents one.

Outside the UI

This simulation runs from the Python SDK and from the REST API, with the same configuration the wizard collects.

Over REST it is a scenario on POST /api/v1/workspaces/{workspaceId}/simulations with "type": "anomaly_detection", with a different spelling per twin kind. Sensitivity is targetFpr, a false-positive rate between 0.0001 and 0.1; lower flags less. (target_fpr is the Python SDK keyword, not the REST field.)

See Working with Digital Twins for the SDK, and Running Simulations over REST for the request body.

Other Simulation Types

  • Prediction — the most likely outcome for a specific input.

  • Intervention — change a single variable and observe propagation.

  • Optimization — find the input combination that best meets a goal.

  • Best Action — the minimum change needed to reach a target outcome.

  • Explanation — the drivers and impacts behind an outcome.

  • Root Cause Analysis — diagnose a specific outcome you already know is wrong.

See Simulation Types for the full picture and Step 6: Run Simulations for the general overview.

Last updated