Diagnose state, deferral and partial CI results

Understand the likely causes

• A stale or overwritten manifest can corrupt comparison assumptions. Default deferral depends on selection and target existence, while favor-state changes preference. Selection is not permission enforcement, and DAG build outcomes are not one project-wide transaction.

Establish the baseline’s identity before trusting selection

Inspect the comparison manifest’s project revision, artifact schema, generation and applied environment using approved existing evidence. Keep it read-only and separate from the current target output directory. state:modified compares supported project metadata, not every changed raw row. A correctly empty result can still be wrong for the intended release if the baseline came from another branch or was overwritten during the run. Record why each expected resource is or is not selected; a filename containing production does not prove provenance.

Separate a model preview from the full build scope

The command text would list modified models and descendants against a fictional baseline, but is not executed here. Associated tests and other resource types need their own command-specific review. Inspect actual effective configs and the selected generation’s indirect-selection rules. An exclusion from execution does not prove the resource’s existing relation will not be read. Likewise, successful list output cannot prove warehouse permissions, source completeness or a correct data assertion. Keep preview evidence tied to the same target and artifact context used for the approved build.

dbt ls --select "state:modified+" --state lab-baseline --resource-type model

Trace deferred parents and runtime write paths

By default, eligible unselected refs can defer when the relation is absent from the current target; favor-state changes this preference. Physical and ephemeral resources do not share identical behavior. A relationship test can join a CI child with a deferred parent from another environment, so define whether that mixed population is the intended assertion. Verify actual read and write permissions, including hooks, operations and stored failures. A unique CI schema name does not prevent a broadly privileged account from writing elsewhere. No connection, grant or target probe is performed by this guide.

Reconcile partial results before promotion or replay

The local outcome model retains a built fact, failed assertion and skipped report. It is not a native run-results artifact and provides no actual commit evidence. Review the real per-resource outcomes and preserve the previous validated publication until required checks are reconciled. A failed command does not automatically undo earlier relations, and a lost sink acknowledgment does not prove rollback. Repeated hooks or additive incremental effects need operation identity and an approved recovery protocol. This guide launches no CI job or dbt command and changes no state artifact, schema or data.

{"scope":"local CI outcome model","fact":"built","required_assertion":"failed","report":"skipped","publication":"previous validated version retained"}

Keep it from recurring

• Retain immutable baseline provenance, separate artifact output paths, explicit relation-resolution review and least-privilege runtime identities. Publish a recovery runbook for partial builds and unknown commit outcomes rather than retrying every failed invocation blindly.