If it's text-based, ADL can generate it. SQL is just the start — test fixtures, deployment scripts, API configurations, custom documentation formats, configuration files. The template engine is yours to point wherever your team needs output.
Anyone who maintains text-based artefacts that should be derived from your data design but currently aren't. QA engineers writing test suites that drift from the schema. DevOps teams hand-maintaining deployment scripts. API teams generating OpenAPI specs by hand. Documentation authors keeping data dictionaries in sync the slow way.
The pain we hear most often: "Our schema is the source of truth, but every downstream artefact — tests, configs, docs, API specs — gets hand-written and then drifts. We end up trusting the database, not the documentation." Each artefact is a manual translation of the same underlying design.
The mechanism is identical to code generation: classify, configure template mappings, generate. The difference is what your templates emit. Because Handlebars is text-agnostic and ADL imposes no opinion on the output format, the same engine that builds a Snowflake warehouse can produce a YAML config, a pytest fixture, a Postman collection, or a custom Markdown report.
Tag Data Objects by whatever taxonomy your downstream artefacts care about — test priority (smoke, regression, full), deployment tier, API surface, audit category. The classifications you define drive how templates branch and what they emit.
Map your Data Objects to the templates that should produce output for them. One Data Object can map to many templates, so the same captured design simultaneously produces (say) a CREATE TABLE script, a pytest fixture, and a deployment-config YAML — each in its own output file.
The same generate-and-deploy loop covers every output. Generated files land in your repo; CI/CD picks them up; downstream systems consume what they're meant to consume. Drift between source-of-truth and dependent artefacts becomes impossible by construction.
A real example: ADL ships a Testing Framework reference implementation that generates SQL data-quality test assertions directly from your metadata.
The framework reads Data Items + their classifications and emits test scripts:
All produced from the same metadata that drives your warehouse generation. When the schema changes, regenerate; the tests stay current automatically. The Testing Framework integrates with the DIRECT execution framework for control-logged test runs.
That's one worked example. The same machinery — classify, configure, generate — applies to anything text-based. Some teams use it for:
Install any starter solution and open one of its templates in the editor. Modify it to emit a different output format — say, a Markdown documentation file instead of SQL — and run the generator. You'll see the substitution mechanism in five minutes.