> ## Documentation Index > Fetch the complete documentation index at: https://docs.atomscale.ai/llms.txt > Use this file to discover all available pages before exploring further. # Diagnose Why Runs Differ > Understand what changed when a run doesn't match expectations by inspecting it over time and comparing it across your dataset When a run produces unexpected results, the first question is always: *what's different?* Atomscale provides two complementary approaches to answer this, depending on the level of detail you need. ## Two Approaches to Diagnosis **Inspect a single run over time to see exactly what happened.** The [Monitor](/platform/reference/monitoring/index) page replays a run with its growth metrics, tool state, and detected events on one synchronized timeline. It shows time-resolved detail on how the process evolved, which metrics shifted and when, and what the tool was doing at the moment of a change. Use this when you need to understand *exactly when and how* a run departs from expected behavior. **What you see:** * **Growth metrics** charts of derived RHEED metrics across the course of the run * **Tool state** instrument parameter logs, synchronized with the metrics so you can line up a change with the conditions that produced it * **Activity timeline** of detected events and changepoints, which you can filter, relabel, and annotate ### Setting Up Select the session from the **Sessions** sidebar on the [Monitor](/platform/reference/monitoring/index) page. An active run appears under **Ongoing**; a finished run appears under **Completed**. For a completed run, use the playback bar to replay it and adjust the speed. For an active run, the view follows the live edge as data streams in. See [Session View](/platform/reference/monitoring/session-view). Watch the growth metrics and tool state together. Where a metric shifts, check the tool state at the same moment to see whether an instrument event coincides with it. Open the **Activity** tab in the Details sidebar to see detected changepoints. Filter by label or magnitude to find the moments where the run's behavior changed. **Find similar and dissimilar runs across your entire dataset.** Explore Similarity uses learned embeddings to position every run by its overall process signature. Instead of inspecting one run in isolation, you see where a run sits relative to your full history: which clusters it belongs to, which it's far from, and how different it is from any other run. Use this to understand *where a run fits* in the broader population and discover unexpected groupings or outliers. **What you see:** * **Similarity map** where runs cluster by process signature, with outliers visually separated * **Ranked matches** with similarity scores for any selected run * **Filtering** by project, sample, or tags to focus on relevant subsets ### Setting Up In the{" "} Explore Similarity {" "} page, choose a metric, transformation, and time scale window. These control what aspects of the process signature are used for comparison. A 2D scatter plot shows your runs positioned by similarity. Similar runs cluster together; divergent runs sit far apart. Points are colored by the selected metric value. Click any point and select{" "} View Similar Data {" "} to see ranked matches with similarity scores. Filter by project, sample, or tags to focus your comparison. ## What to Look For Both approaches follow the same logic: identify *where* the run diverges, assess *how much*, and connect that to *what it means* for your outcome. ### Identifying Divergence In the **Monitor session view**, watch the growth metrics for the point where they depart from the run's earlier behavior or from what a healthy run looks like. The synchronized tool state shows whether a specific instrument event coincides with the shift, and the activity timeline flags changepoints automatically so you can jump straight to them. In **Explore Similarity**, look at where the problem run sits relative to runs with known outcomes. A run that clusters with failures but used a "good" recipe suggests the issue is in execution, not design. A run between clusters may indicate a borderline process condition. ### Assessing Significance Not every difference matters. The **Monitor session view** shows the *magnitude* of a shift over time: a brief excursion that self-corrects is different from a sustained drift. **Explore Similarity** scores quantify how far a run sits from its nearest neighbors, which you can compare against the natural spread of your process. Cross-reference with [anomaly detection](/platform/guides/detect-anomalies) results: if a run looks anomalous in similarity analysis and also triggered drift or point anomalies, that strengthens the case that the deviation is real. ### Connecting to Outcomes The diagnostic value comes from linking process divergence to outcome differences. When the **Monitor session view** shows a run shifting during a specific phase, check whether that phase historically correlates with the outcome property that degraded. When **Explore Similarity** shows a run clustering with failures, examine what those failures have in common. Runs that are "close" in embedding space tend to produce similar outcomes, making the distance itself a meaningful diagnostic signal. ## Choosing the Right Approach | Scenario | Approach | Why | | ---------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------- | | You need to know exactly when and how a single run changed | Monitor session view | Time-resolved metrics, tool state, and changepoints on one synchronized timeline | | You want to find what a problem run is most similar to | Explore Similarity | Searches your full dataset without pre-selecting references | | An active run looks like it's drifting | Monitor session view | Follows the live edge so you can decide whether to intervene before the run completes | | Process transfer to a new tool | Explore Similarity | Shows how new-tool behavior compares to original-tool signatures across your history | | Recurring intermittent failures | Both | Explore Similarity identifies what failing runs share; the session view shows the full detail of each | ## Documenting Findings When you identify the source of divergence, record it: * **Tag the run** with descriptive labels (e.g., "temperature-drift", "flux-excursion") so it's findable in future similarity analyses. * **Add notes** in the session's Metadata documenting which parameters diverged, your hypothesis, and any corrective action taken. * **Build up labeled examples** of good and bad runs over time so your similarity comparisons grow more informative as your dataset matures. ## Next Steps Diagnose consistency problems within a single run that similarity analysis alone may not surface. Set up automated detection to catch divergence patterns before they require manual diagnosis.