CATALOG DECISION WORKFLOW

DataHub Actions

Turn analysis into visible catalog context through explicit, item-level human approval.

SIMULATED WRITEBACK

◇

DATAHUB OPERATIONAL GRAPH

Draft changes for DataHub

contextIsKey rebuilds every approved proposal on the server. Browser input never controls catalog content.

⌾ Nothing is written without approval

SIMULATEDNo DataHub is connected to this hosted demo. Approval records an entry in the local demo catalog, not DataHub. The same gate uses real GraphQL through make live-demo.

✓ RAISE INCIDENT Proposed schema change: customer_id varchar to bigint Target · stg_orders

Records the proposed change against the source dataset so the review is visible to everyone downstream.

Preview catalog payload

contextIsKey analyzed a proposed change to stg_orders.customer_id (varchar to bigint).

Confidence: HIGH
Strategy: parallel_typed_field

Observed downstream impact:
  1. fct_order_sales (hop 1)
  2. loyalty_customer_value (hop 2) [critical]
  3. regional_returns (hop 2)
  4. executive_revenue_dashboard (hop 3) [critical]

Hidden SQL consumers:
  - loyalty.usp_reconcile_loyalty_customer (convert, HIGH)
  - operations.usp_match_regional_returns (join, MEDIUM) - Verify both join operands are BIGINT before changing the source.
  - finance.vw_customer_revenue_bridge (cast, HIGH)
  - exports.usp_export_customer_segments (dynamic_sql, LOW) - Contains dynamic SQL, so the referenced object and runtime type need manual review.

Regional exposure:
  - NORTHEAST: HIGH; 3 assets, 2 SQL objects
  - SOUTH: MEDIUM; 3 assets, 2 SQL objects
  - MIDWEST: MEDIUM; 3 assets, 2 SQL objects
  - WEST: HIGH; 4 assets, 3 SQL objects
  - UNKNOWN: REVIEW; 0 assets, 1 SQL objects

Evidence limits:
  DataHub lineage and static module scans can miss runtime dynamic SQL, external tools, and assets with absent region metadata.

Introduce a parallel typed field for `customer_id`, validate the safe cast from `varchar` to `bigint`, and migrate downstream consumers in stages.

Raised by contextIsKey on human approval. Lineage is evidence of observed dependencies, not proof of every consumer.

✓ ADD TAG Tag loyalty_customer_value as pending an upstream change Target · loyalty_customer_value

loyalty_customer_value is tagged critical and sits 2 hops downstream of the edit.

Preview catalog payload

urn:li:tag:changeproof-pending-change

✓ ADD TAG Tag executive_revenue_dashboard as pending an upstream change Target · executive_revenue_dashboard

executive_revenue_dashboard is tagged critical and sits 3 hops downstream of the edit.

Preview catalog payload

urn:li:tag:changeproof-pending-change

✓ UPDATE DOCS Document the parallel_typed_field migration on stg_orders Target · stg_orders

Puts the migration plan where the next engineer reading this dataset will find it.

Preview catalog payload

Pending change: customer_id varchar to bigint.

Rollout:
1. Add a parallel typed field for `customer_id` alongside the current `varchar` contract.
2. Backfill the parallel field with a safe cast from `varchar` to `bigint` and record validation results.
3. Migrate observed downstream assets to the new typed field in hop order after owner review.
4. Promote the new typed field only after compile, test, and backfill validation succeed for `bigint`.

Rollback:
1. Keep or restore the original `varchar` field for `customer_id` as the active contract.
2. Revert downstream consumers to the original field until cast and backfill issues are resolved.
3. Re-run compile and regression checks against the original type contract.

⌾

Human approval gateOnly selected IDs are accepted. Content is recomputed server-side.

TAKE IT WITH YOU