← All use cases

Compliance & governance

Surface PII, sensitive data, and regulated flows directly on your data design — and let the same tags drive your governance reports, access-control scripts, and audit documentation.

Who this is for

Governance officers, compliance reviewers, security and privacy teams, and any data-management function responsible for knowing where regulated data lives.

The pain we hear most often: "Where does customer email actually live in our warehouse?" Every answer involves a manual hunt through scripts and screenshots. Compliance reviews drag on because the inventory is implicit — locked inside the heads of senior engineers — rather than expressed in the design itself.

How ADL is configured for this

The pattern lives in three of ADL's four configurable layers. The starter classifications ship today; the persona and templates can be the ones in the box, or yours.

Classify

Tag Data Objects and Data Items by sensitivity (PII, Sensitive, Confidential), regulatory regime (GDPR, HIPAA, SOX), or any taxonomy your governance team uses. ADL ships a Global reference set; you can extend or replace it.

Configure

A compliance persona surfaces those classifications as colored chips directly on the model graph. Switch into the persona for a review, switch out for normal design work. The metadata never changes — only what you see.

Generate

Templates read the same classification tags. Generate sensitivity-aware documentation, GRANT scripts that restrict access to regulated tables, audit reports that list every PII column with its lineage. One source of truth; many compliance artefacts.

In practice

A common scenario: your auditor asks for a complete inventory of personally identifiable information flowing through the data warehouse, with lineage from source to consumer.

  1. Tag once. A data modeler goes through the metadata in ADL and marks Data Items that hold PII. The tags live in the project's JSON metadata, version-controlled in your git repository.
  2. Configure the persona. Switch into the compliance persona. PII, sensitive, and confidential chips appear on every node that carries those tags. Lineage edges from source through staging into the warehouse are still visible — so it's immediately clear which downstream tables inherit the sensitivity.
  3. Generate the audit artefacts. Run the governance template against the same metadata. Output: a Markdown report listing every PII-tagged Data Item with its parent table, the connection it's hosted on, and the mappings that flow it downstream. Hand it to the auditor.
  4. Stay current. When the design changes, regenerate. The audit document is no longer a one-off spreadsheet that drifts — it's a function of your metadata, produced on demand.

What ships today

  • Global classifications sample — ADL ships a reference set of classifications you can install from the Marketplace, covering conceptual, logical, and physical groupings. Start there; adjust to your taxonomy.
  • Classification chips on the graph — see the post: See your classifications at a glance with chips.
  • Classifications concept docs — the docs explain how to apply classifications to Data Objects, Data Items, and Connections, and how templates can read them. Read the concept doc.
  • Custom governance templates — the template library is open Handlebars; write the reports your auditor actually wants. How to write a custom template.

Try it

Install a sample solution, classify a few of your Data Objects, configure a compliance persona, and watch the graph fill in. A first usable picture is achievable in under an hour.

Try the app — free in public preview