> For the complete documentation index, see [llms.txt](https://docs.decube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decube.io/trusty-ai/fix-incident-with-trusty.md).

# Fix Incidents with Trusty AI

{% hint style="info" icon="telescope" %}
Fixing incidents with Trusty AI is in **limited preview**. We're iterating on it quickly based on how teams actually use it, so tools, capabilities and availability may change at short notice. For access, questions, or feedback on how it's working for you, reach out at <support@decube.io>.
{% endhint %}

When a monitor triggers, Decube tells you what broke. **Fix with Trusty AI** takes the next step: it hands the full incident context to Trusty and asks for the likely root cause and the remediation steps, so you move from alert to fix without piecing the story together yourself.

## Where to find it

The **Fix with Trusty AI** button sits in the top right of the header on the [Incident Details](/data-quality/data-quality/incident-details.md) page, to the left of **View monitor**.

The button is available on any incident regardless of status.

{% hint style="info" %}
The button only appears for users who have access to Trusty AI. If you can view the incident but do not see the button, your account does not have Trusty AI enabled. Contact us for access.
{% endhint %}

## Before you begin

We highly recommend adding the **Incident Remediation** skill to your Trusty interface.

The skill gives Trusty a fixed procedure for working an incident: which context to pull and in what order, how to judge whether the data actually broke or the monitor is miscalibrated, and how to lay out the fix. Without it, Trusty still answers, but the depth and shape of the answer vary from incident to incident. With it, every incident gets the same structured investigation against the same quality bar.

{% file src="/files/qjKXisVCIh8ufjHcNNdW" %}

For what skills are and how to use them on other surfaces, see [Skills](/mcp/skills.md).

## How does it work?

1. Select an incident to open the **Incident Details** page.
2. Click **Fix with Trusty AI** in the top right of the incident header.
3. Trusty opens in a new browser tab with the details pre-filled within the prompt box. You can add or remove any context that is not required.
4. Read the remediation plan, then continue the conversation in the same session to dig deeper.

## What gets sent to Trusty

Each click starts a **new** Trusty session. It never posts into a session you already have open, so the incident is answered against a clean context and your existing conversations are left untouched.

The first message is composed for you and carries a structured summary of the incident:

| Field                          | What it contains                                                          |
| ------------------------------ | ------------------------------------------------------------------------- |
| **Incident ID**                | The unique ID of the incident, so Trusty can look up the full record      |
| **Affected asset**             | The table, column, or data job the incident was raised against            |
| **Incident type**              | Freshness, Volume, Field Health, Schema Drift, Custom SQL, or Job Failure |
| **Incident level**             | Info, Warning, or Critical                                                |
| **What triggered it**          | The name and description of the test that breached                        |
| **Observed & expected values** | The value recorded at detection and expected values                       |

Trusty can then pull further detail on its own: the monitor's run history, incident history, lineage, and profiling.

## What Trusty gives back

With the **Incident Remediation** skill in place, Trusty replies in plain language with a full remediation plan:

* **The diagnosis** — whether the data actually broke or the monitor is miscalibrated, and the evidence behind that call.
* **The likely root cause** — what most plausibly caused the breach, including whether this incident is a symptom of an upstream job failure or schema change.
* **The downstream impact** — the dashboards, reports, and jobs consuming the affected data, so you know who to warn.
* **The next steps** — ranked remediation actions with an owner against each, plus advisory SQL you can run yourself to localise the problem.
* **How it gets verified** — what confirms the fix has landed before you close the incident.

The answer is shaped by the incident type. For example:

* A Freshness incident points you at load schedules and upstream job timing
* A Schema Drift incident points you at the structural change and the downstream consumers exposed to it.

You will not get the same generic advice for both.

Where Trusty cannot land on a root cause with reasonable confidence, it says so and tells you what to check next rather than presenting a guess as fact. Nevertheless, as with any Trusty response, verify anything critical.