Documentation
dex allows you to add human-readable descriptions to your data models, columns, and tests. This metadata helps your team understand what each object in your project represents—improving collaboration, onboarding, and trust in your data assets.
Well-documented models create clarity for both technical and non-technical stakeholders. By keeping documentation close to your transformation logic, you ensure that knowledge stays version-controlled, discoverable, and always up-to-date.
How Documentation Works
In dex, documentation is stored directly in the same .yml
files used to define tests and register models. This ensures your model logic and your documentation stay tightly coupled.
You can document:
Models: What the table represents
Columns: What each field means and how it should be interpreted
Tests: Why a test exists and what it’s validating
Once defined, documentation is surfaced across dex:
In the Develop section alongside your code
In the Lineage and Data Catalog views
In model previews, helping you interpret the outputs
Adding Descriptions to Models and Columns
To document a model, create or open the corresponding .yml
file in the same folder where your model resides. Use the description
field for both models and their columns.
Example
version: 2
models:
- name: customers
description: "A dimension table containing one row per unique customer, including demographic and location data."
columns:
- name: customer_id
description: "Unique identifier for each customer. Used as the primary key."
tests:
- not_null
- unique
- name: customer_type
description: "Business logic-driven classification such as 'new', 'returning', or 'VIP'."
Where Documentation Appears in dex
dex automatically renders your documentation across multiple views in the platform:
Model Explorer: View model-level and column-level descriptions inline while browsing or editing.
Data Lineage View: See descriptions alongside dependencies and impact graphs.
Catalog: Search and browse datasets with their documented context.
Preview Pane: Get field-level tooltips when inspecting query outputs.
This makes documentation immediately accessible for anyone interacting with your models—without needing to open the YAML file directly.
Best Practices
Be clear and concise: A good description helps someone unfamiliar with the model understand its purpose.
Keep it updated: Documentation should evolve with your models. If logic changes, update the description as part of the same commit.
Use business terms: When possible, write descriptions in plain language that aligns with how your business talks about data.
Describe intent, not just structure: For example, instead of “customer_type: the type of customer,” say “customer_type: Business logic-driven classification such as 'new', 'returning', or 'VIP'.”
Last updated
Was this helpful?