The Model Says Yes. The Source Says No.
Your conceptual model says the customer has a delivery address and a home address. Open the source system, and neither one exists.
What you find instead is a customer table, a customer address table and an address table. And there’s a column called address type, carrying values like Shipping and Main Office. The clean noun on your diagram turns out to be a join and a filter that nobody’s written down. Somebody still has to write it, and that somebody is a data engineer.
Most of the friction between the two sides of a data project lives in that gap. The business modeler isn’t being unreasonable. Delivery address is what the business means, and the model would be worse for inventing a name just because the source happened to use it. The engineer isn’t being difficult either, because the source was built by a vendor who never read your model. It’ll keep arriving in that shape no matter how the diagram looks. Neither side is wrong. And someone still has to translate.
Watch this in action:
Ask for the structure your model already promised
Here’s how we ran ours, starting from the conceptual data model the workshop produced. The project canvas carried more tables than anyone wants to hold in their head, so we worked in a workspace instead. A workspace is the subset of tables a given piece of work actually needs. With the scope narrowed, we opened Ask AI and typed one sentence, that we need a view for the customer’s delivery address. That was the whole prompt.
What came back wasn’t an answer. It was two questions. Should the address type filter to shipping, and which layer should this view live in? We answered shipping and persistent staging. The proposal came back with every table name resolved against the catalog rather than invented. It parked as a proposal card with nothing yet written to the model.
The first proposal is a draft, and that is fine
The view designer opened with the tables, the filter, and the name already in place. The proposal was wrong in a few ways. That was fine. Every one of those ways was faster to fix than it would’ve been to specify up front.
It had anchored on the customer table, when customer address and address between them carry everything we wanted. So we dropped customer, which left a two-table join. Then we expanded each table and clicked the columns we actually wanted: the customer identifier and a handful of address columns. We left the address type out, because the filter already settles that question.
The preview pane rewrote the CREATE VIEW statement as we went, so what we saved is exactly what runs. Correcting the whole thing took less time than reading this description of it.
That division of labor is the point. The machine did the tedious part: finding the tables, working out the join, drafting the shape. You did the part only you can do, which was knowing that the third table was redundant and that the type column had no business being in the output.
Does the saved view keep column-level lineage?
The saved view is a catalog object like any other, not a query somebody pasted. Every projected column records the source columns it reads, so the bridge carries column-level lineage rather than becoming the one opaque step in the chain. It saves through the same branch, review, and commit path as any other metadata change. And it lands in the layer you chose, sitting on the canvas beside the tables it draws from.
So what do you have now? Your physical data model holds a structure named for what the business means, built from the sources that actually arrived. The join and the filter are written down instead of carried in someone’s head. That isn’t a source-to-target mapping document explaining the gap between the two worlds. It’s a structure that closes it.
Here’s how to run yours.
- Pick the concept your model promises and your source does not hold.
- Open a workspace with just the tables this piece of work needs.
- Ask for it in one sentence.
From here, the view is ready for Data Vault modeling, where the delivery address stops being a view and becomes part of the warehouse.