The silver layer holds cleaned, conformed data: one row per entity or event, consistent types and names, duplicates removed and bad rows set aside. Silver tables are the shared foundation that gold tables and analysts build on. They usually keep the detail of the source, not aggregates.
For example, the bronze orders table may hold the same order line twice because a file was delivered twice, store codes in mixed case, amounts as text and dates in two formats. The silver orders table holds each order line once, store codes in one case, amounts as decimals, dates as dates and columns named the same way as in every other silver table. Rows that could not be cleaned, such as an order with no store code, go to a quarantine table with the reason, so they can be fixed and loaded again.
Conforming is the part that crosses sources: if two systems both describe customers, silver is where their records are mapped to one shape, keys are aligned and code values are translated to a shared list. That work is what lets gold tables join data from different sources without each one repeating the mapping.
Silver tables are usually kept up to date incrementally, with merges on the natural key, and they are a good place for data quality tests, because errors caught here never reach reports. Some teams open silver to analysts for detailed questions; others keep it internal to the data team and publish only gold. See also medallion architecture.
On Databricks and Microsoft Fabric, silver tables are usually Delta tables in their own schema, and on Snowflake they are often tables maintained by tasks or dynamic tables. Wherever they live, they are the layer where most of a data team's cleaning rules are written down, which makes them worth testing well. See also bronze layer and gold layer.
In Emolysis, the Dedupe / conform shape turns bronze into silver, and the CDC merge and SCD Type 2 shapes often maintain silver tables. Silver is also where bad rows are set aside for review instead of failing a whole load.