## TL;DR
Child rows without parents break joins and drop revenue or activity silently: enumerate the orphan keys, classify them as late parents, filtered parents, or genuinely missing, and reconcile at the load layer. The check should end with zero unexplained orphans, even if a small documented quarantine remains.

```text
referential integrity failed error: child rows without parent failed check
```

## Use this when
- The check or run fails with this symptom: the referential integrity check lists child rows whose parent keys do not exist.
- You are working on a referential check failing on child rows with no parent and the failure repeats on the same data or configuration.
- You need the failing rows, rule, or stage isolated before changing thresholds or code.

## Not for this skill when
- An orders-specific foreign key failure with business context on the parent table, which the orders-focused skill covers in depth instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Run the check query and save the orphan keys with counts per child table. Verify: orphan keys are saved per table
2. Look the keys up in source systems and parent load history to classify each group. Verify: each orphan group has a classification
3. Check the parent load for filters, late windows, or key transformations that differ from the child's. Verify: the parent-side cause is confirmed or ruled out
4. Backfill or correct the parent load, resequence dependent loads, or quarantine genuinely missing references with owner sign-off. Verify: the reconciliation action is applied per group
5. Rerun the referential check and confirm no unexplained orphans remain. Verify: the check passes with only documented quarantine, if any

## Variant phrasings
### referential integrity failed child rows without parent
The verbatim child-without-parent phrasing.
### child rows missing parent referential check fix
The fixing phrasing for load-order and filter causes.
### orphan keys referential integrity warehouse check
The orphan-key phrasing for classification workflows.

Compatibility: Referential integrity checks in Soda, dbt relationships tests, and warehouse SQL checks

## Why it happens
Referential integrity spans two independently loaded tables, so timing, filtering, and key formatting differences between the loads manufacture orphans. The check compares snapshots; the loads' history explains whether the relationship or the scheduling is broken.

## Edge cases / pitfalls
- Normalise keys identically on both sides before comparing. Formatting orphans waste more time than real ones.
- Gate child loads on parent load completion in the orchestrator to remove the timing class entirely.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ryt9U0VN3bZy1TWECjZ1dQ