Every column, defined
A plain-language description for each table and column, written from what the asset actually does, not its cryptic legacy name.
A data dictionary, written as you build.
The Chronicler writes a dictionary entry for every table and column as the platform is built: definitions, types, the tests that guard each field, and a link into the lineage. Searchable, in your catalog, and yours to keep.
A living dictionary
Every table, explained in plain language.
Most estates have a working platform and no current dictionary. The Chronicler fixes that as it goes: it writes a structured entry for every model and column, drawn from what the asset really does, so a new analyst can read a table instead of reverse-engineering it.
- One entry per model, the same shape every time
- Descriptions written from behavior, not legacy names
- Generated from the build, so it is always current
- Searchable and diffable in your catalog and repo
# generated by the Chronicler version: 2 models: - name: dim_customer description: "One row per customer, SCD Type 2." columns: - name: customer_key description: "Surrogate key, unique per version." tests: [unique, not_null] - name: customer_id description: "Business key from CRM." tests: [not_null] - name: valid_from description: "Row effective-from timestamp."
What each entry carries
Definitions you can act on.
A dictionary is only useful if it answers the next question. Each entry carries enough to do that.
Types and constraints
Data types, nullability and keys, captured so the contract of each table is explicit and checkable.
Owners and domains
Who owns what, grouped by domain, so questions go to the right team instead of into a void.
Linked to lineage and tests
Each entry links to the lineage graph and the tests on that column, so a definition, its origin and its guarantees sit together.
In dbt the dictionary is the dbt docs site, generated for free; in your own framework we write the same definitions into your catalog, which is extra effort on our side. dbt or your framework →
In the catalog
The dictionary you can browse.
On the dbt flavor those YAML definitions render as a searchable catalog: an overview of every layer and source, and a page per model with its columns, tests and lineage.
Good questions
Your data dictionary, answered.
What is in a dictionary entry?
For every model: a plain description, and for every column its type, a description, the tests that guard it, and a link into the lineage. Enough that a new analyst understands a table without asking anyone.
Is it searchable?
Yes. It lives in your platform’s catalog and your repository, so it is searchable and diffable. On the dbt flavor it is the dbt docs site; in your own framework the Chronicler writes the same definitions into your catalog.
Who keeps it current?
It is generated from the build, so it regenerates when a model changes. There is no separate wiki to update and forget. See everything you keep →
Does it describe the legacy side too?
The knowledge base documents the legacy estate; this dictionary documents the new platform. The lineage links the two, so a column’s definition and its origin sit one click apart.
Let's talk
Want your estate, defined?
The estate assessment documents a representative slice of your estate, so you can see the dictionary you would keep, linked to its lineage, before you commit.
Plan my migrationA short form, no spam. We usually reply within one business day.