Source dataset · postgres · proposed rename

analytics.orders

The requested change. RippleProof confirmed user_id exists and customer_id does not, so the rename cannot land on an existing column.

migration.sqlnever executed on a source database

+ ALTER TABLE "analytics"."orders" RENAME COLUMN "user_id" TO "customer_id";

ISOLATED

Tested in a disposable container, never against the source. A networkless PostgreSQL container observed user_id, applied the rename, verified customer_id, rolled back, and confirmed user_id was restored.

Reachable assets

5

4 column-confirmed, 1 asset-level

Review routes

6

resolved from DataHub ownership

Downstream asset · column evidence · 1 hop

orders_daily

The direct consumer. RippleProof rewrote the executable references and left the string literal alone, because a quoted value is not a column.

dbt_project/models/orders_daily.sql+3 −3

select-    user_id,+    customer_id,    date(created_at) as order_date,    sum(order_total) as total_revenue,     'user_id' as source_key_label      <- string literal, left alonefrom {{ source('analytics', 'orders') }}-where user_id is not null+where customer_id is not null-group by user_id, date(created_at)+group by customer_id, date(created_at)

SQL AWARE

Comments, string literals and Jinja stay inert. The rewrite changes executable identifiers only. A find-and-replace would have corrupted the label above.

dbt_project/models/schema.yml+1 −1

  - name: orders_daily    columns:-      - name: user_id+      - name: customer_id        description: Stable downstream user identifier.        data_tests:          - not_null

Downstream asset · column evidence · 2 hops

customer_revenue

A transitive consumer in the finance repository, patched because DataHub proved it derives the renamed column.

dbt_finance_project/models/customer_revenue.sql+1 −1

select-    user_id,+    customer_id,    sum(total_revenue) as lifetime_revenuefrom {{ ref('orders_daily') }}

Repository

dbt_finance_project

pull request #6, checks passing

Reviewer

Finance Analytics

routed from DataHub ownership

Downstream asset · column evidence · 2 hops

customer_segments

A transitive consumer in the growth repository, patched on the same confirmed column evidence.

dbt_growth_project/models/customer_segments.sql+1 −1

select-    user_id,+    customer_id,    case when lifetime_revenue > 1000 then 'high' else 'standard' end as segmentfrom {{ ref('orders_daily') }}

Repository

dbt_growth_project

pull request #5, checks passing

Reviewer

Growth Analytics

routed from DataHub ownership

Downstream asset · column evidence · 2 hops

customer_identity_export

One DataHub asset matched two candidate dbt implementations. The campaign blocked until a reviewer chose one of the candidates RippleProof had already discovered.

BLOCKED

Two dbt models claimed this asset. A naive agent picks one and patches it. RippleProof refused, and the reviewer could select only a candidate it had actually found. The choice is hash-bound, and the rejected candidate stays in the record.

dbt_operations_primary/models/customer_identity_primary.sql+1 −1

select-    user_id,+    customer_id,    email,    created_atfrom {{ ref('orders_daily') }}

Selected

operations_primary

chosen by a reviewer, hash-bound

Rejected

operations_shadow

retained in the decision record

Downstream asset · asset-level reachability only · 2 hops

Revenue Dashboard

DataHub proves this Looker dashboard is reachable from the renamed column. It does not prove the dashboard uses that column.

MANUAL

Reachability is not usage, so it gets no invented patch. A naive agent patches it anyway, or reports it as broken. RippleProof routes it to a human and states exactly why.

Evidence tier

asset level

column usage unconfirmed

Disposition

manual review

visible, never silently dropped

Reviewer

Revenue Operations

routed from DataHub ownership

Repository candidate · discovered, not selected

dbt_operations_shadow

The second implementation that claimed customer_identity_export. RippleProof discovered it, refused to choose between the two, and kept it in the record after the reviewer picked the other.

NOT SELECTED

Kept in the decision record rather than discarded. An agent that silently picks a winner leaves no trace of what it rejected. The resolution hash covers both the selected and the unselected candidate.

Discovered

yes

a reviewer could have chosen it

Patched

no

no pull request opened