## TL;DR

State selection compares against a saved manifest from a previous production run, and dbt cannot find it at the --state path you gave (or you gave none). Download or mount the production manifest.json into a state folder, pass --state pointing at it, and rerun. Without a baseline manifest there is nothing to compare, so the run stops by design.

```text
dbt run --select state:modified: no state comparison artifacts found
```

## Use this when

- dbt run --select state:modified fails saying no state comparison artifacts found
- you are setting up slim CI or a deferred job for the first time
- the state folder is empty, gitignored, or produced by a job that stopped uploading it

## Not for this skill when

- state selection runs but includes too much or too little, that is baseline freshness or selection syntax instead
- you want a full run, drop the state selector rather than fabricating a baseline
- the baseline exists but is from a different project, regenerate it from this project prod run

## Steps

1. Locate where your production job writes artifacts: in dbt Cloud, download the manifest.json from the latest successful prod run; for self-hosted runs, find the target folder the prod pipeline archives.
   Verify: you have a real prod manifest.json file in hand.

2. Place it in a dedicated folder such as state/manifest.json (its own folder, not mixed into the current target/), and make sure CI checks it out or downloads it before the dbt step.
   Verify: the state folder contains manifest.json before dbt runs.

3. Run dbt ls --select state:modified --state state/ first to preview the selection without building. Confirm the listed models match a recent change you made.
   Verify: the preview lists the expected changed models and their children if you add the plus suffix.

4. Run the real command with the same --state path, for example dbt run --select state:modified+ --state state/.
   Verify: the run builds the selected models and completes.

## Variant phrasings

### first ever slim CI run
There is no baseline until prod runs once with artifact saving on. Bootstrap by running one full prod build that archives manifest.json, then enable state selection.

### artifacts found but stale
An old baseline makes state:modified select nearly everything. Refresh the baseline on every successful prod run, not weekly.

Compatibility: dbt-core state selection, 1.x; --state expects a folder containing manifest.json from a prior run of the same project. dbt Cloud exposes run artifacts for download via the API and UI.

## Why it happens

state:modified is a diff, and a diff needs two sides. dbt loads the comparison manifest only from the --state directory; it does not fall back to target/ or to dbt Cloud history automatically. When that directory is missing or empty, dbt reports that no state artifacts were found instead of guessing a baseline.

## Edge cases / pitfalls

- Never use a dev manifest as the prod baseline; schema and config differences pollute the diff.
- Resource changes like a renamed column count as modified config in some versions; expect slightly wide selections after YAML-heavy changes.
- Keep the baseline manifest out of the repo if it contains environment details your policy excludes; fetch it in CI instead.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7uy-7sDBCXyjRVevXWy_yA