← Back to home

Git-native by design

Metadata and templates live as files in your repository. Branching, code review, pull requests, CI/CD — nothing changes about how your team works. The design metadata becomes just another set of artefacts that travel with the rest of your codebase.

Why this matters

Most data modeling and code-generation tools store their metadata in a proprietary database. That means the modeling tool sits next to your codebase, not inside it. To collaborate, your team has to invent workflows that the rest of the engineering organization doesn't use — vendor-specific check-in/check-out, branching extensions, review tooling that doesn't connect to your normal pull-request process.

The cost is friction at every joint. Designers can't easily review each other's changes the way engineers review code. CI/CD has to special-case the modeling tool. Onboarding a new team member means teaching them two version control systems. The metadata that drives your warehouse becomes second-class to the code that runs on it.

How ADL delivers

The decision is built into the architecture: everything ADL produces or consumes is a file.

  • Metadata as JSON files. Every Data Object, Data Item, Mapping, Connection, Classification, Convention, and Template Mapping is a separate JSON file in your project folder. Diffing a change shows you exactly what changed. Branching the metadata is just branching the repo.
  • Templates as Handlebars text files. Open them in any editor. Review them in any code-review tool. Treat them like the rest of your codebase, because they are part of the rest of your codebase.
  • Generated output lands in your repo. SQL, documentation, deployment scripts — all written back to folders you specify. Your normal CI/CD picks them up. The generation step is just another build step.
  • No server, no central state. ADL runs entirely in your browser; it reads and writes files in a local folder you point it at. There's no central metadata server for your team's repository to disagree with.

What this enables in practice

  • Feature branches for design changes. Spin up a branch, change a few classifications, regenerate, commit. Review in a pull request alongside any code changes that depend on the new design.
  • Atomic commits across metadata + code. When the design needs new audit columns and the loading procedure needs to populate them, both changes ship in one commit. The metadata and the implementation never drift.
  • Full design history in your existing git tools. git blame, git log, GitHub's history view, your normal review queue — every tool you already use works on metadata too.
  • CI/CD with no special configuration. Your existing pipeline can regenerate output from metadata as part of a build, validate the result, and deploy. No vendor plugin required.

What ships today

  • File-system access in the browser. ADL uses the modern File System Access API to read and write your local project folder directly — no upload step, no server intermediary.
  • Plain JSON throughout. Every metadata file is human-readable JSON. No proprietary binary format anywhere in your project.
  • Public-preview blog post — see ADL — live and free in public preview for the original design principles announcement.

Try the app — free in public preview