Operational runbooks
How each pipeline runs, on what schedule, and what to do when it fails: the knowledge an on-call engineer needs at 2am.
Documentation that stays true.
The Chronicler writes runbooks and onboarding guides as the platform is built, generated from the build so they are accurate on day one and regenerate when it changes. The project ends with documentation, not tribal knowledge.
Documentation that lives
Written as the platform is built.
Most migrations finish with a working platform and a wiki nobody trusts. The Chronicler writes the documentation as the build happens, from the same knowledge base the migration runs on, so what you read matches what runs.
- Runbooks for the people who operate it
- Onboarding guides for the people who join
- Generated from the build, so it stays true
- In your repo and catalog, owned by you
# Runbook: dim_customer ## Purpose One row per customer, SCD Type 2. ## Schedule Daily at 02:00, incremental on modified_at. ## Upstream stg_customer, src.crm_customer ## On failure Re-run the model. If the row-count test fails, check the SCD backfill, then re-run the loop.
What gets written
The docs you always meant to write.
Not a glossary nobody opens: the operational, practical documentation a team needs to run a platform it did not build by hand.
Onboarding guides
A path into the platform for a new hire, so the first week is reading, not interrogating the one person who knows.
Generated, so current
Written from the build as it happens and regenerated when it changes, so the docs match the platform instead of lagging it.
In your repo, yours
Versioned alongside the code, delivered with the migration, and owned by you. No portal to rent from us.
In dbt the model docs come for free with the build; runbooks and onboarding guides we generate either way, and in your own framework that is extra effort on our side. dbt or your framework →
Down to the last consumer
Even your BI datasets are documented.
Documentation does not stop at the platform edge. Each Power BI dataset is captured as an exposure: what it is for, who owns it, how it is refreshed, and exactly which models it depends on.
Good questions
Living documentation, answered.
What documentation do we actually get?
A data dictionary, lineage docs, operational runbooks and onboarding guides for the new platform: enough for a new hire to understand and run it without shadowing someone for weeks.
How does it stay current?
It is generated from the build, so it regenerates when the build changes. It does not drift away from reality the way a hand-written wiki does the day after it is written. See everything you keep →
What format is it in?
Human-readable docs in your repository and your platform’s catalog, browsable and diffable. On the dbt flavor the model docs are the dbt docs site.
Is it ours to keep?
Yes. It is delivered with the migration and lives in your systems. Your code and data are used for your migration only, never to train models.
Let's talk
Want docs you can trust?
The estate assessment shows the kind of documentation the fleet would generate for your platform, so you can see what a new hire would read before you commit.
Plan my migrationA short form, no spam. We usually reply within one business day.