How ADL Works

At its heart, ADL follows a simple formula:

Metadata + Templates = Output

You describe your data solution (the metadata), define what output you want (the templates), and ADL generates everything for you. Let’s break that down.

The workflow

Step 1: Define your metadata

Metadata is where everything starts. In ADL, metadata describes the structure of your data solution:

• Data Connections — Where does the data live? A SQL Server database, a Snowflake warehouse, a file system? Each connection captures the details ADL needs to know about a target platform.
• Data Objects — What are the tables, views, or queries you’re working with? Each data object describes a structure, including its columns (called Data Items), relationships to other objects, and any classifications.
• Data Object Mappings — How does data flow from one place to another? Mappings connect source objects to target objects and describe the transformations along the way.

All of this metadata is stored as plain JSON files in your project folder. There’s no hidden database — everything lives in your repository where you can see it, version it, and edit it however you like.

Step 2: Create or choose your templates

Templates define the output you want to generate. They’re written in Handlebars, a templating language that mixes static text with dynamic placeholders.

For example, a template might generate a SQL CREATE TABLE statement by looping through the columns in a data object and writing out each column definition. Another template might generate a stored procedure, a Markdown documentation page, or a deployment script.

ADL ships with a library of ready-made templates for common scenarios, but you can modify them or write your own for any output format you need.

Step 3: Map templates to metadata

To tell ADL which template should be used for which metadata object, you create template mappings. This is simply a link between a data object and a template — “use this template to generate output for this table.”

You can map different templates to different objects, so your staging tables might use one template while your Data Vault hubs use another.

Step 4: Generate output

When you’re ready, ADL processes each mapping: it takes the metadata object, applies the template, and writes the result to a file in your output folder. One template + one metadata object = one output file.

The generated files land in your project folder, ready to be reviewed, committed to your repository, and deployed through your normal CI/CD process.

What makes this approach powerful

Everything is a file

Metadata, templates, and output are all plain text files in your repository. There’s nothing hidden, nothing proprietary. You can edit them in ADL, in VS Code, or in any text editor.

Open formats throughout

The metadata uses the open-source Generation Metadata Schema for Data Solution Automation. Templates use the open-source Handlebars language. You’re never locked in.

Change a pattern, update everything

If you need to change how your staging tables are created — maybe you want to add an audit column — you update the template once and regenerate. Every table gets the update. No more hunting through hundreds of scripts.

Works with any platform

ADL doesn’t care what your target database is. The same metadata can be used with different templates to generate output for SQL Server, Snowflake, PostgreSQL, or anything else that uses text-based scripts.

What’s next?

• Metadata & Data Objects — Learn more about how metadata is structured in ADL.
• Templates & Code Generation — Dive into how templates work and what you can generate.
• Quick Start Guide — Jump in and set up your first project.