> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Understanding Test Results
> What Completed, Failed and the Source Data result codes actually tell you about your compliance posture.
## "Completed" means the check ran — not that you passed
In **Data Library → Tests**, the **Status** column shows one of six pills: **Completed**, **Failed**, **Error**, **In Progress**, **Not Run**, **Deactivated**.
**Completed** means DSALTA reached your system, collected the data, and finished evaluating the check. On its own it does **not** mean the check found nothing wrong. A check that ran perfectly and found five misconfigured resources is still **Completed**, because the *run* succeeded.
**Failed** does not mean "you are non-compliant" either. It means DSALTA was **blocked** and could not evaluate the check at all — almost always a missing permission, or a setting it still needs from you.
To see what a check actually found, open it and read the result code.
## Where to find the result code
Go to **Data Library → Tests** and click the test's row. A panel opens on the right.
Open the **Source Data** tab. The table at the top lists the most recent runs, newest first, at most ten of them. Its heading reads **API Requests** on an integration test and **Run History** on a system test.
Each run shows a numeric result code. It renders as a bare colored number with no caption, so use the table below to read it.
If the test has never run, there is no table at all — the tab reads **No Source Data Found** / "Run the test to collect source data and evidence."
Underneath the run table, the **Evidence** panel shows the latest completed run as JSON. It is an envelope DSALTA builds around the run, not the stored result verbatim: `method`, `passed`, `result`, `error`, `source` and `timestamp`, with everything the check actually returned nested under `result`. Read `result.summary` first; where the check produced them, `result.findings` lists the specific offending items and `result.remediation` explains the fix.
The rows in the run table are **runs**, not resources. Ten rows means ten executions of the check, not ten findings. Individual offending resources live inside a single run's `findings` list.
## What each code means
| Code | Color | What happened | What to do |
| ------- | ------ | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| **200** | Green | The check ran and found nothing to fix. | Nothing. |
| **204** | Gray | Nothing to evaluate — usually the service isn't in use or isn't enabled in your account. | Confirm the service really is out of scope. If you do use it, enable it and re-run. |
| **207** | Amber | **The check ran successfully and found a compliance gap.** This is the code that means "you have something to fix". | Open the **Evidence** panel, read `result.summary` and `result.findings`, fix the listed items in your provider, then re-run the test. |
| **403** | Red | The check could not run — DSALTA is missing access it needs (a role, scope, or permission). | Grant the access named in the result, then re-run. |
| **428** | Red | The check could not run — it still needs settings from you, such as a list of critical repositories or approved email domains. | Provide the missing settings, then re-run. |
| **500** | Yellow | The run failed because of a problem on DSALTA's side. | Re-run the test. If it persists, [contact support](/troubleshooting/contact-us). |
| **102** | Blue | The run is still in progress. | Wait and refresh. |
## The one thing to watch: 207
For checks powered by a connected integration, a **207** run still shows as **Completed** in the Tests list. That is deliberate — the *run* succeeded. But **207 means there is an open compliance gap**, and the Tests list will not turn red for it.
**Practical rule.** Read the Tests list as *"did the check run?"* and the Source Data code as *"what did it find?"*. Review your **207** runs on a schedule. Do not wait for the Tests list to turn red — for integration-powered checks it never will.
## 403 and 428 are the only codes that turn the list red
Both mean DSALTA is blocked, not that you failed. They surface as **Failed**. A **500** also surfaces as **Failed** rather than as **Error** — so a red **Failed** pill on an integration check is a prompt to read the code before assuming a compliance problem.
## Uploaded evidence overrides the run
If you attach evidence to a test manually, DSALTA records a passing result for it: on an integration-powered test a **200** row joins the API Requests list and the status holds at **Completed** through later runs, even when the automated run behind it fails; on a DSALTA system test the status flips to **Completed** straight away and the next daily system-test run restamps it with the handler's own verdict, so read the **Evidence** tab for what you uploaded and the Run History rows for what the check itself found. Check for `result.evidenceSource: "manual_upload"` in the Evidence panel before taking a **200** as proof the automated check succeeded.
## Related pages
* [Tests](/guides/data-library/tests)
* [Test Detail](/guides/data-library/test-detail)
* [Integration errors](/troubleshooting/integration-errors)