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

# Trust overview

> Detect quality issues after Move, apply Trust gate policy, open incidents, and remediate so data stays trustworthy.

Trust in Zwiron evaluates data after it has moved and been inventoried. Detect runs quality checks against Catalog assets. **Trust gate policy** (in Settings) decides whether gated failures **warn** or **block**. **Trust incidents** give operators a durable work queue to assign, investigate, cleanse, resolve, or hand off to Match.

<Note>
  Trust is separate from Match. Use [Data Quality](/platform/data-quality) to define tests, **Trust → Incidents** to triage failures, and [Match](/match/overview) when the remediation is entity resolution (duplicates).
</Note>

The following articles help you operate Trust:

* [Trust incidents](/trust/incidents) — triage open failures
* [Trust gate policy](/trust/gate-policy) — warn vs block when a quality gate fails
* [Data Quality tests](/platform/data-quality) — define and schedule checks
* [Match overview](/match/overview) — resolve duplicates that quality rules surface

***

## Where Trust sits

| Area | Relationship to Trust |
| - | - |
| **Jobs (Move)** | Sync runs may receive Trust status warn/blocked when a gated check fails |
| **Catalog (Know)** | Assets carry quality / certification signals Trust updates |
| **Data Quality** | Test cases and results feed detect (**Trust → Data Quality**) |
| **Incidents** | Operator inbox for gate and detect failures (**Trust → Incidents**) |
| **Match** | Optional remediation path for duplicate / uniqueness failures |

Typical sequence:

1. Data lands via a Job and assets exist in Catalog.
2. Detect evaluates quality rules (on demand, scheduled, or after Match write-back).
3. Gate policy applies: **Warn** or **Block** (see [Trust gate policy](/trust/gate-policy)).
4. Incidents open for operator triage.
5. Remediation (cleanse, fix data, adjust tests, or Match) then re-detect / re-certify.

***

## Building blocks

| Block | Responsibility |
| - | - |
| **Detect** | Engine or agent evaluates monitors / rules; Atlas does not scan row batches in-process |
| **Gate** | Org **Trust gate policy**: warn vs block when a gated check fails |
| **Incident** | Durable record of failure scope, status, assignee, and history |
| **Remediate** | Investigate, cleanse as MOVE, create Match project, or fix source / rules |
| **Re-know / re-cert** | Catalog and certification catch up after a clean detect |

***

## Certification signals

Catalog assets can show **quality / certification** signals after Trust detect runs. In practice:

| Signal | Meaning |
| - | - |
| **Certified / healthy** | Recent detect passed for attached tests (within your operating window) |
| **Failed / at risk** | One or more tests failed — open or resolve the [incident](/trust/incidents) |
| **Stale** | No recent successful detect after schema or data changes — re-run Data Quality |

Certification is not a separate product module — it is the Catalog view of Trust outcomes. Always triage from **Trust → Incidents** and confirm tests under **Trust → Data Quality**.

***

## Navigation

| Task | In the app |
| - | - |
| Triage failures | **Trust → Incidents** |
| Configure tests | **Trust → Data Quality** |
| Gate policy | **Settings → General** → **Trust gate policy** |
| Deduplicate entities | **Match → Projects** (or **Create Match project** from an incident) |

Sidebar under **Trust**: **Incidents**, **Data Quality**.

***

## Related articles

* [Trust incidents](/trust/incidents)
* [Trust gate policy](/trust/gate-policy)
* [Data Quality](/platform/data-quality)
* [Match overview](/match/overview)
* [Catalog](/platform/catalog)
* [Know overview](/know/overview)
* [Jobs](/platform/jobs)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.