A worked example · not your data
What happened when we ran it.
We pointed RippleProof at a demo warehouse with five dbt repositories and asked it to rename one column. Below is everything it did, in order, including the three times it stopped and refused to continue. Nothing here is yours; it is a record of one real run you can read end to end.
$ ripple-proof plan --instruction "rename user_id to customer_id"
New here? Start with what RippleProof is.
Run log
00:00.4
Read the source schema over MCP
analytics.orders confirms user_id exists and customer_id does not
list_schema_fields
00:01.1
Traced lineage and ownership5 reachable assets, 4 with column evidence, 6 review routes
get_lineage
00:01.9
Refused: two dbt models claim one assetA naive agent picks one and patches it. The campaign blocks pending a human choice.
blocked
00:02.0
A reviewer selected a discovered candidate
operations_primary chosen, operations_shadow retained in the record, hash-bound
human
00:02.4
Refused: dashboard reachable, column use unprovenReachability is not usage, so the Looker dashboard gets no invented patch
manual review
00:03.6
Generated 8 files across 4 repositories4 SQL model repairs and 4 dbt contract updates
8 files
01:12.8
Executed the repairs in isolation4 dbt roots built the exact expected nodes; a disposable PostgreSQL container renamed and rolled back
4 / 4 roots
01:31.2
Refused: the lineage moved after planningThe cached metadata interface still returned a removed edge; the uncached graph did not
stale context
02:04.7
Opened 4 review-only pull requestsRequired checks passing, auto-merge disabled, merging stays human
4 PRs
02:19.3
Recorded approved-for-review in DataHubRead back across 6 assets through a fresh client, explicitly not approved-to-merge
6 / 6 assets
0false repairs across 8 cases
3refusals in this run
8files across 4 repositories
11of 11 audit checks
Timings and counts come from the captured campaign bound to manifest 7b907e81. This page replays a completed run; it does not contact DataHub or GitHub.