# Templates and slots > What an Emolysis template contains, the eleven slot types, how slots are filled and validated, and how to write your own templates. A template is the tested, platform-specific form of one pipeline shape. Emolysis fills templates instead of writing pipelines from scratch, so every pipeline starts from code that already passes its tests. The template format is public, so you can read it and write your own. ## Template ids A template is named `.`, for example `scd2.databricks` or `cdc-merge.snowflake`. Local-only examples use `duckdb` as the platform. Ten shapes on three platforms make thirty templates in the library. The shape part is the id from the [pipeline shapes](https://emolysis.com/docs/shapes): `ingest-batch`, `incremental-append`, `cdc-merge`, `scd2`, `snapshot`, `backfill`, `late-arriving`, `dedupe-conform`, `aggregation-gold` and `reverse-etl`. The platform part is `databricks`, `snowflake`, `fabric` or `duckdb`. ## What is in a template Each template is a folder: ```tree scd2.databricks/ template.sql the template file, with named slots (or template.py) manifest declares the template id, its slots and their types tests/ input fixtures and the expected output for each case cost note what drives the template's cost on its platform constraints what the template needs from the platform profile ``` - **The template file,** `template.sql` or `template.py`, with named slots where values go. - **A manifest** that declares the template's id, its slots and their types. Its format id is `emolysis.template/v0`. - **Tests:** input fixtures, usually Parquet, and the expected output for each case. - **A cost note** that says what drives the template's cost on its platform, such as a full table scan or a warehouse that stays awake. - **Platform constraints:** what the template needs from the [platform profile](https://emolysis.com/docs/platform-profiles), such as a table format or a minimum feature. The file names in the tree above are for orientation. The format specification in the public SDK repository is the source of truth for exact names. ## Slots and their types A slot is a named value the template needs. Every slot has a type, so the agent cannot put a column list where a table name belongs: | Type | Holds | | ------------- | ------------------------------------------- | | `identifier` | A name, such as a constraint or job name | | `table` | A table reference | | `column` | One column | | `columns` | A list of columns, such as a composite key | | `expression` | One SQL expression | | `expressions` | A list of SQL expressions | | `string` | Text | | `integer` | A whole number | | `boolean` | True or false | | `duration` | A length of time, such as a lookback window | | `enum` | One value from a fixed list | ## What the slots look like per shape The slots follow what each shape needs. These are the kinds of values the agent asks for, in plain words: | Shape | Values the template needs | | ------------------ | ---------------------------------------------------------------------------------------------- | | Ingest (batch) | Source location and format, target table, schema hints, the columns that identify a duplicate | | Incremental append | Source, target, the watermark column and its type, an optional lookback window | | CDC merge | Key columns, the ordering column, the operation column and its values, how deletes are handled | | SCD Type 2 | Business key, tracked columns, where the effective date comes from, the current flag | | Snapshot | Source, target, snapshot date column, retention period, replace or keep dated copies | | Backfill | The pipeline to run, partition column, grain, date range, how many partitions run at once | | Aggregation / gold | The grain, the measures and their aggregates, the dimensions, the source tables | ## How slots get filled The slot schema tells the agent exactly what is missing. It fills slots from your catalog where it can (column names and types, keys), from your request where you said it, and asks you for the rest. Literal values are rendered for the target platform's dialect, so quoting and escaping follow that platform's rules. Because values have types, a value of the wrong type is rejected with an `invalid_params` error before anything is rendered, instead of producing a broken query. See [Error codes](https://emolysis.com/docs/error-codes). ## Validation The public validator checks a template folder against the format: the manifest, the slot types, the fixtures and the expected outputs. A template that does not validate is not rendered. ## Writing your own The format and the validator are public in [emolysis/template-sdk](https://github.com/emolysis/template-sdk) on GitHub (MIT license). You can write templates for your own recurring patterns and use them in your projects. The tested library that ships with Emolysis stays part of the product. The SDK package is not published to a registry yet. ## Readiness Each library template is judged per platform: - **Green:** it passes its golden tests on the real platform. - **Yellow:** it passes on DuckDB only. - **Missing:** it does not exist yet. The matrix of shapes by platforms is the scorecard for the library. A template does not count as green until it has run on the real platform. See [Golden tests on DuckDB](https://emolysis.com/docs/golden-tests). ## Status The library holds a template for each shape on Databricks, Snowflake and Microsoft Fabric. Their golden tests pass on DuckDB, and none has passed on a real platform yet. The template format is public as source, not as a package, and can change before the first release. --- Page: https://emolysis.com/docs/templates. Emolysis is a product of Bandpey GmbH, Munich, Germany. It is in private development, and nothing is released yet.