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, an address table, and 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 has written down. Somebody still has to write it, and that somebody is a data engineer.

This is where most of the friction between the two sides of a data project actually lives. The business modeler is not 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 is not being difficult either, because the source was built by a vendor who never read your model, and it will 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 is 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: 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 was not 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, and 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, and that was fine, because every one of those ways was faster to fix than it would have 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 and promoted customer address to the primary table. That left a two-table join, which let us shorten the remaining aliases. Then we expanded each table and clicked the columns we actually wanted: the customer identifier and a handful of address columns, but not the address type, 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 is 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.

Think about what you now have. Your physical data model holds a structure named for what the business means, built from the sources that actually arrived, with the join and the filter written down instead of carried in someone’s head. That is not a source-to-target mapping document explaining the gap between the two worlds. It is a structure that closes it.

Here is how to run yours.

  1. Pick the concept your model promises and your source does not hold.
  2. Open a workspace.
  3. Ask for it in one sentence.

In the next session we take this view into Data Vault modeling, where the delivery address stops being a view and becomes part of the warehouse.