> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Investigations

> How scaling.cloud diagnoses an incident automatically — investigations, runs, and confidence-scored findings you confirm or dismiss.

An **investigation** is scaling.cloud's diagnostic layer for an incident. When a high-impact incident opens, scaling.cloud reads the signals it can reach — your past incidents, recent code changes, and connected error tracking — and posts **findings**: short, confidence-scored statements about what is likely going on, each backed by evidence you can open.

Investigations never act on their own. Every finding is a suggestion you **confirm** or **dismiss**, and any action a finding proposes waits for a human to approve it. See [Proposed actions](/concepts/proposed-actions).

## The shape of an investigation

| Concept           | What it is                                                                                                                  |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Investigation** | At most one per incident, created automatically when the incident is created. The container for findings.                   |
| **Run**           | A single pass of the investigation against the available signals. The first run starts automatically; you can trigger more. |
| **Finding**       | One diagnostic statement — a `kind`, a one-line summary, a `confidence` score, and links to its evidence.                   |

## What gets investigated

Investigations run automatically only when **both** conditions hold:

* Your organization is on a plan that includes AI Investigations (**Pro** or **Enterprise** — see [Pricing](https://scaling.cloud/pricing)).
* The incident's [severity](/concepts/incidents#severity-levels) is `critical`.

<Note>
  The gate is **severity**, not how the incident was opened. A `critical`
  incident that an alert opened automatically at 3am is investigated just like
  one a person declared — exactly when no one is awake to start digging.
</Note>

Incidents below `critical`, and all incidents on the **Free** plan, do not auto-run. You can still open the investigation panel on any entitled incident and start a run by hand.

## Findings

Every finding carries:

| Field        | Meaning                                                                                                  |
| ------------ | -------------------------------------------------------------------------------------------------------- |
| `kind`       | The type of finding — see [Signal sources](/concepts/signal-sources) for the full list.                  |
| `summary`    | A one-line, human-readable statement (e.g. *"Deploy 8 min before the first alert touched `payments/`"*). |
| `confidence` | How strongly the signal supports the statement, shown as a percentage.                                   |
| `evidence`   | Links to the underlying material — a past incident, a deploy, a Sentry issue.                            |
| `status`     | `proposed` when posted, then `confirmed` or `dismissed` once a responder weighs in.                      |

Findings are produced with an **origin** of `ai` — the same attribution model the rest of the timeline uses to distinguish machine actions from human ones (see [Origin](/concepts/incidents#origin-human-vs-system)).

<Note>
  scaling.cloud stays quiet when it is unsure. A finding is only posted when its
  confidence clears an internal floor, so a cold-start incident with no
  matching signal produces **silence**, not noise.
</Note>

### Confirming and dismissing

In the incident's **Findings** panel, each proposed finding has **Confirm** and **Dismiss** controls. Confirming records that a responder agreed with the diagnosis; dismissing clears it. Neither changes the incident's status — findings inform the humans running the incident, they do not drive the lifecycle.

## Where findings show up

Findings are surfaced where responders already work:

* **Incident page** — the Findings panel lists every finding with its confidence and evidence, and lets you confirm, dismiss, or start another run.
* **Chat** — tag `@scaling` in the incident channel for a live summary synthesized from the findings (Slack and Microsoft Teams). See [Work with AI findings](/guides/work-with-ai-findings).
* **Post-mortems** — when a [post-mortem](/concepts/post-mortems) draft is created on resolution, its root-cause and contributing-factors sections are pre-filled from the findings, so your retro starts from a draft instead of a blank page.

## Where findings come from

The first run of every investigation looks at your own resolved incidents. Once you connect a code or error-tracking source, later runs draw on those too:

<CardGroup cols={2}>
  <Card title="Signal sources" icon="signal-stream" href="/concepts/signal-sources">
    Past incidents, GitHub changes, and Sentry errors — the inputs a run reads.
  </Card>

  <Card title="Proposed actions" icon="wand-magic-sparkles" href="/concepts/proposed-actions">
    How a finding can propose a next step for a human to approve.
  </Card>
</CardGroup>