> ## 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.

# Changepoint Detection

> Real-time changepoint detection on RHEED streams, with labels inherited from reference changepoints in a project

The Changepoint Detection workflow monitors RHEED streams in real time and flags changepoints as a growth unfolds: the moments where the signal's behavior shifts. Each detected changepoint is matched against reference changepoints you have already labelled elsewhere in the same project, so recurring events inherit consistent, human-meaningful labels. Surfacing these events as they happen lets you respond quickly to unexpected changes in deposition.

It runs automatically on [RHEED](/platform/reference/models/data-items#rheed) data once a project with labelled reference changepoints is in place. See [Setting up reference changepoints](#setting-up-reference-changepoints).

<Tabs>
  <Tab title="Overview">
    ## Detection Process

    For each monitored RHEED stream:

    1. **Detect**: As the stream arrives, the workflow continuously scans the derived metric timeseries for changepoints.
    2. **Score severity**: Each changepoint is assigned a severity (**High**, **Moderate**, or **Low**) reflecting how large the shift is.
    3. **Label from references**: Each new changepoint is compared against the labelled reference changepoints in its project. If a close enough match exists for the same metric, the changepoint inherits that label. Otherwise it stays **Unlabelled** until someone labels it.

    ## Setting up reference changepoints

    The labels applied to detected changepoints come entirely from changepoints you have already labelled in the same [project](/platform/reference/models/projects). A project that has no labelled changepoints still detects events, but those events stay unlabelled. Setting a project up as the label source takes a few steps.

    <Steps>
      <Step title="Choose or create a project">
        Pick the [project](/platform/reference/models/projects) that will hold both the reference data and the sample you want to monitor, or create a new one.
      </Step>

      <Step title="Add labelled reference data items">
        Add one or more [data items](/platform/reference/models/data-items) from earlier runs of this workflow to the project, then label their changepoints. These labelled changepoints define the full set of labels that can be applied during monitoring.
      </Step>

      <Step title="Add the sample you want to monitor">
        Add the physical sample for the new growth to the same project, so its detected changepoints can be matched against the references.
      </Step>

      <Step title="Stream the growth">
        Start streaming. Detected changepoints are matched against the project's references and labelled automatically as they appear.
      </Step>
    </Steps>

    <Note>
      If the project has no labelled changepoints for this workflow yet, detected changepoints are still flagged, but they remain unlabelled. Label the matching changepoints on data items already in the project to use them as references.
    </Note>

    Only labelled changepoints on the same data modality and metric are considered as references, so a label set on one RHEED metric is never applied to a different metric.

    ## How changepoints appear

    Detected changepoints surface in two places in the [Monitor](/platform/reference/monitoring) view.

    **As bars on the timeseries chart**: In the Growth Metrics panel, each changepoint is drawn as a colored vertical band over the chart at the time it occurred. The color encodes severity: red for **High**, amber for **Moderate**, and blue for **Low**. Instantaneous changepoints are widened to a minimum so they stay visible, and the time axis can be switched between elapsed time and absolute timestamps.

    **In the activity timeline**: The Details sidebar's [Activity tab](/platform/reference/monitoring/session-view) lists every changepoint as a row, ordered through the run, showing its timestamp, the metric it was found on, a severity badge, and its label (or **Unlabelled**). You can filter the timeline by label, deviation, and assigner, relabel an event, add notes, or request a suggested label. An info card shows which project is supplying the labels and the categories available.

    ## Severity

    Severity reflects how large the detected shift is and drives the color of the changepoint in the chart and timeline:

    | Severity     | Color | Meaning                                      |
    | ------------ | ----- | -------------------------------------------- |
    | **High**     | Red   | A large shift. Investigate promptly.         |
    | **Moderate** | Amber | A noticeable shift that may be worth review. |
    | **Low**      | Blue  | A subtle or minor shift.                     |

    Default thresholds apply across your organization. Per-project and per-data-item overrides let you tighten thresholds for sensitive metrics or relax them for known-noisy signals.
  </Tab>

  <Tab title="Technical">
    ## Detection

    Detection runs incrementally as the stream arrives, so changepoints are flagged in near real time rather than only after a run completes. Two parameters shape the raw output:

    * **Cooldown**: the minimum time between consecutive detections, which suppresses bursts of near-duplicate events. This is the main parameter exposed when configuring the workflow.
    * **Merge gap**: changepoints on the same metric that fall within a short window of each other are merged into a single event.

    ## Reference-based labeling

    When a changepoint is detected, the workflow looks for the best-matching labelled changepoint to copy a label from:

    * **Candidate pool**: labelled changepoints on data items in the same project (linked through their physical samples), restricted to the same data modality and metric as the new changepoint.
    * **Ranking**: candidates are ranked by how close they sit in the run to the new changepoint (the distance between their window centers). Labels confirmed by a person are preferred over unconfirmed automatic suggestions, which keeps earlier guesses from compounding into the taxonomy.
    * **Confidence gate**: the top candidate's label is applied only when the match is confident enough. Weak matches are left unlabelled rather than guessed.
    * **Cold start**: if the project has no labelled reference for that modality and metric, no label is applied.

    Labels can also be propagated manually across a chosen scope: a single data item, all data items of a physical sample, an entire project, or every data item of the workflow.

    ## Severity and Thresholds

    Severity is derived from the size of the detected shift, mapped onto **High**, **Moderate**, and **Low** through configurable thresholds. Defaults are set at the organization level; per-project and per-data-item overrides let you adjust them for individual metrics.

    ## Configuration

    The workflow reads an organization-level default configuration, which individual data items can override. Key settings:

    * the metrics to monitor,
    * the cooldown and merge windows,
    * the severity thresholds.

    If no organization-level configuration exists, detection is skipped.
  </Tab>
</Tabs>
