Open and interoperable

Roelant Vos · 13 Jun 2026

Many modeling tools keep the way their metadata is stored a secret. The metadata sits in a database only the tool can read, exported only through a proprietary application that hides what’s actually happening, and locked behind a license that makes it hard to take it elsewhere. When you ask “can I use this metadata with something else?”, the answer often is some version of “however the exporter or API allows it (but expect to lose some detail).”

ADL treats the format as a (human and machine-readable) contract instead. Your design metadata is plain JSON, conforming an open-source schema, and in a folder structure you pick. The same JSON ADL writes is the JSON anything else can read. There is no internal-only representation, and no exporter.

What ‘open’ actually looks like

The pieces that make this true are deliberately boring.

• Every JSON file ADL writes conforms to the Data Solution Automation metadata schema, an open-source schema with full docs. Inspect it, fork it, file issues, submit PRs.
• The format is JSON. Not XML, not a custom binary, not an encrypted blob. UTF-8, indented, camelCase. Open it in VS Code. Diff it in Git. Parse it in ADL, or use it with Python, Rust, Go, or whatever your preferred approach is.
• The templating languages are based on decades of community tooling, and used widely for many different purposes ranging from websites to mail-merge. If you ever stop using ADL the templates you wrote still work anywhere a public tools and scripts.
• There is no ADL-specific format anywhere in the pipeline. The output is plain text, and can manage SQL, Markdown, deployment scripts, test fixtures, YAML, OpenAPI specs — whatever the template emits.
• There are no internal/hidden IDs that mean nothing to other systems, no app-version stamps, no proprietary extensions. The file you read is the file the schema describes.

Concretely, this is what a small piece of ADL metadata looks like — a source-to-target mapping with two column-level mappings:

{
  "dataObjectMappings": [
    {
      "mappingName": "CustomerExample",
      "sourceDataObjects": [
        { "name": "CustomerSource" }
      ],
      "targetDataObject": { "name": "Customer" },
      "dataItemMappings": [
        {
          "sourceDataItems": [{ "name": "CustomerId_src" }],
          "targetDataItem": { "name": "CustomerId" }
        },
        {
          "sourceDataItems": [{ "name": "CustomerName_src" }],
          "targetDataItem": { "name": "CustomerName" }
        }
      ]
    }
  ]
}

That is the whole representation. Same on disk, same on the wire, same in any tool that opens it.

What ‘interoperable’ actually looks like

Open formats are nice. Interoperable ones are useful. The two are not the same — a published schema that nobody actually reads is visible, not interoperable. ADL works at the next level.

• Your metadata itself is the exchange format. Anything that reads JSON can read your design. We have shipped a sample that turns the open schema into a navigable website — a separate tool, not ADL, consuming ADL’s metadata. See The Data Solution Automation Schema as a sample design for what that actually looks like.
• ADL providers a Metadata Importer that can be used to reverse-engineer databases (and other formats) and emits the same JSON. You do not retype your model; you bring it across.
• Your CI/CD pipeline, your data catalog, your custom governance dashboard — anything that wants to consume your design can. The JSON is the API.
• If you ever stop using ADL — we hope you do not, but the option matters — every other tool that reads the schema sees your full design.

What this gets you

Some of the things that follow naturally once the format is genuinely open:

• Sharing the design with another team, another tool, or another vendor’s pipeline is sharing the same files you were already working with. There is no exporter necessary, and you can share repositories as-is. That’s how we’ve created the samples data solutions.
• Start anywhere, and incrementally add to your design metadata. Build a small script that lists every Data Object touching PII. Build a custom dashboard that reports on Data Vault hash collisions. Build a linter for your team’s naming conventions. None of these need ADL to run; they need the JSON. But of course you can use ADL for this as well 🙂.
• The schema, the format, and the files outlast ( the version of the) app that wrote them.

The principle

ADL is built on the assumption that the metadata is the essential artifact, and that the tool is replaceable. Open and interoperable is what it takes to truly mean that — and to let the metadata you author today still be useful many tooling generations from now.

The schema itself is formally described — and the broader thinking behind why metadata is the long-lived artifact is developed at length — in Data Engine Thinking. Worth a read if you want the full argument rather than the highlights.