Layers and Naming

Amfelt generates the layers in your data platform from the data contract rather than from hand-written SQL. You configure what should be true; the SQL that makes it true is produced for you. See Layering for the wider picture.

The Layers  

• Staging. Each load lands here as received: typed from the data contract, with the hash and run properties the history layer compares on.
• History. Where history is kept. Depending on the history mode, earlier versions of a record stay available.
• Bridge layers. The endpoint your analytics tools read.

In the history layer, under SCD Type 2, a full reload does not lose what a source has already forgotten: when a source hard-deletes last quarter’s records, their versions are closed, not removed.

Naming Is a Convention, Not a Decision per Object  

Layer schemas take their names from a fixed convention: each job’s schema prefix (derived from its source’s slug or abbreviation) plus a layer suffix (_stg, _hst, _bdg). Objects and properties keep their source names. That is deliberate: every source lands in a predictable shape, and someone who has never seen this project can guess what an object is called instead of looking it up.

The schema prefix and source abbreviation are part of the project’s configuration, so they are versioned along with everything else and a change to them is reviewable.

Native SQL, Not a Common Denominator  

The SQL Amfelt renders targets your platform’s own dialect. You get objects that look like objects a competent engineer on that platform would have written, not a translation layer that avoids anything platform-specific.

Point Consumers at the Bridge Layers  

Bridge layers are the intended consumption point. Aim dashboards and downstream tools at them rather than at the layers underneath, so that a change in how a layer is built does not break reports.

Next  

Choose a Load Strategy , or see what has been generated so far in Explore the Catalog .