Atlas Catalog
A server-indexed, searchable documentation browser for every model, source, seed, snapshot, exposure, metric, macro, and analysis in your dbt project. Browse descriptions, columns, tests, lineage, compiled SQL, warehouse stats, and coverage scores - all without downloading multi-MB manifest files.
The catalog is organized into these tabs:
- Overview - your project's landing page, built from the
__overview__doc block - Browse - a searchable, filterable list of every node with a detail pane
- Graph - a full, zoomable whole-project lineage DAG
- Coverage - animated scorecards showing documentation and test coverage gaps
- Mesh - declare upstream project dependencies and see how ready your project is for dbt Mesh
- Organization - a company-wide view of every project, its public data products, and cross-project lineage
Why Atlas Catalog
| Challenge with other tools | How Atlas Catalog solves it |
|---|---|
dbt docs serve requires downloading the full manifest to the browser, which is slow for large projects | Server-indexed: only the slice you need is fetched, so browsing is instant even for 5,000+ node projects |
| Only models and sources get docs pages; exposures, metrics, and macros are invisible | All eight node types get first-class pages with type-specific detail views |
No project-level landing page unless you view the raw __overview__ block | A dedicated Overview tab renders your project's doc block as a polished landing page |
| No whole-project lineage graph without downloading and parsing the full manifest | A zoomable DAG graph is rendered server-side and viewable in both the catalog and the shared docs portal |
| Documentation coverage is invisible until someone runs a manual audit | Coverage scorecard with animated rings shows doc/test gaps at a glance, broken down by schema and type |
| Fixing documentation gaps means switching to a code editor, writing YAML, re-generating docs | One-click "Document with Atlas" sends the undocumented model to Atlas AI for instant doc generation |
| Column lineage requires separate tooling or is unavailable entirely | Column-level lineage is built into the node detail pane, computed on demand from compiled SQL |
| Docs go stale because they only reflect parse-time metadata | Warehouse-aware metadata (real types, row counts, storage, source freshness) is ingested after every run |
| Regenerating docs overwrites the previous version, so last month's documentation is gone | Every generation publishes a version you can browse, compare, and share, and nothing you already published is ever rewritten |
| Sharing docs externally requires granting platform access | Share docs via tokenized links with public, password, or SSO access gates - no login needed for recipients |
| "Who owns this?" is a Slack question, and the answer is a string in a YAML file that may name someone who left | Business and Technical owners are real members, adopted from dbt, assigned in bulk, or inherited from folder, layer, and tag rules, with an ownership score that shows the gaps |
Project Overview
The Overview tab is the landing page for your project's catalog. If your dbt project includes a {% docs __overview__ %} block, its content is rendered here as formatted markdown with any nested {{ doc() }} references already resolved.
When no overview block exists, a summary card shows your project's total entry count and doc-block count so the page is never blank.
To add an overview, create a __overview__ doc block in any of your dbt project's docs files.
Searchable Node Index
The Browse tab lists every node with type-colored indicators:
- Models, Sources, Seeds, Snapshots - your core data assets
- Exposures - dashboards, notebooks, and ML applications
- Metrics - semantic-layer metric definitions
- Macros - reusable Jinja functions with arguments and source
- Functions - dbt 2.0 user-defined functions with their signatures
- Analyses - ad-hoc analytical queries
Full-text search filters the list as you type. A labeled, collapsible filter panel keeps the controls organized instead of a wall of unlabeled dropdowns, and lets you narrow the list by:
- Type (model, source, test, semantic model, and the rest)
- Schema and database
- Layer: the layers your project actually has. dbdeux reads your folder structure, so the standard staging, intermediate, and marts appear in that order, and any additional layer your team uses (reports, exports, and so on) shows up automatically instead of being lumped into "other"
- Health: healthy, caution, degraded, or unknown, each with a live count
- Documentation and test status
The stats band at the top shows totals by type with animated coverage rings. Tests and semantic models are first-class, browsable entries alongside models and sources.
Click any node to open its detail pane.
Node Detail Pane
Each node's detail view shows:
Description and Metadata
- Node description (from your YAML or schema files)
- Materialization type, schema, database, and tags
- Package name and file path
- Meta: any
metafields your team declared on the node in YAML (owner, tier, domain, and anything else you track) rendered as a readable block, so your own conventions are visible in the catalog rather than buried in a file
Long detail views are organized into collapsible sections, so you can fold away what you are not looking at and keep the parts you care about in view.
Columns
A sortable table of every column with:
| Column | Source |
|---|---|
| Name | Manifest |
| dbt type | Manifest (parse-time) |
| Warehouse type | catalog.json (actual type in the database, e.g., NUMBER(38,0)) |
| Description | Manifest |
| Tests | Inline chips showing attached generic tests (not_null, unique, etc.) |
| Position | catalog.json (ordinal position in the relation) |
Warehouse Stats
After a dbt docs generate run, the detail pane shows live warehouse metadata:
- Row count and storage size (bytes)
- Adapter-specific extras (clustering key, last modified, partitioning) displayed as label-value pairs
- These fields update automatically after every run, so your docs never go stale
Cost
On Business and up with Cost Insights set up, a model's Cost section shows what it costs to build, the findings that would lower it, and Propose rewrite with Atlas. See Costly Models.
Source Freshness
For source nodes, the detail pane shows:
- Last loaded at timestamp
- Freshness status (pass, warn, error) with a visual staleness indicator
- Criteria (warn-after and error-after thresholds)
- Freshness data comes from
dbt source freshnessruns and updates automatically
The catalog always overlays the latest freshness result for each source, drawn from your most recent scheduled or on-demand freshness check. You do not have to hunt for the run that produced it. Whenever a job checks source freshness, the catalog reflects the new status.
Compiled SQL
View the rendered SQL for any model, with syntax highlighting. Useful for understanding what dbt actually sends to your warehouse after resolving refs, macros, and Jinja. The compiled SQL is refreshed after every scheduled run, even when the job does not generate docs. A new catalog version still comes from Generate docs on run.
Lineage
Model-level upstream and downstream dependencies are shown inline. Click any linked node to navigate to its detail view.
Exposure Details
Exposure nodes display type-specific fields: Type (dashboard, notebook, ML model, application), the URL of the external asset, Maturity, Owner, and the models and sources it reads. An exposure's detail page also carries Why this health, its Data promise, and Embed health tile, described in Exposures: Is the Dashboard Data Ready?
Metric Details
Metric nodes show:
- Metric type and label
- Expression (the calculation formula)
- Filter conditions
- Upstream semantic model linkage
Macro Details
Macro nodes include:
- Arguments table with name, type, and description for each declared argument
- Macro source - the full Jinja body with syntax highlighting
Functions
Projects on dbt 2.0 can define user-defined functions, and the catalog treats them as first-class objects alongside models and macros. Each function node shows:
- Signature in the form you would call it,
cents_to_dollars(amount number, precision int = 2) -> number, with the primary signature first - Arguments with name, type, default, and description, and the return type
- Overloads: a function that accepts more than one set of argument types lists every variant, each with the file and line it is defined in
- Facts such as scalar, deterministic, and the language it is written in, where the project declares them
- Source: the function body with syntax highlighting, and the compiled body for each overload
Functions appear in Browse with their own type indicator and filter and in search, so an analyst reading a model's SQL can look up a function and see what it does without opening the repository.
Warehouse Tables and Views
Not everything in your warehouse was built by dbt: the tables a loader fills, a view someone created by hand two years ago, the schema another team owns. The catalog now lists those too, so "what is in our warehouse" and "what does dbt know about" are finally the same page.
- Where they come from: the same scan of your warehouse connection you see on the Databases page, read through the connections of the project's environments that you have access to. Re-scan the connection there to pick up new tables, columns, or row counts
- Clearly marked: each one carries a Warehouse table or Warehouse view type, its own filter in Browse, and a note naming the connection it was found through, so it is never mistaken for a dbt model
- What you see is what the warehouse says: columns, types, and row counts. dbt-only information such as descriptions, tests, run history, lineage, and SQL exists only for objects dbt manages and is not shown for these
- Honest about gaps: if the last scan stopped before it saw every object, or a connection is not shared with you, the catalog says so in place rather than listing a suspiciously short schema. Ask an organization admin for access to a connection and the objects appear
These objects also show up in Search anything, so a warehouse table you have heard of but never seen is one keystroke away, with the place to ask about it right there.
Exposures: Is the Dashboard Data Ready?
A dashboard is only as good as the data under it, and the people reading it rarely know when last night's build failed. The Exposures view of the catalog answers the question they actually ask: can I trust this dashboard right now?
One Health Verdict per Dashboard
Every exposure in your project, the dashboards, notebooks, ML models, and applications that read it, gets a row with its type, owner, maturity, the last upstream build, and one Health verdict: Healthy, Caution, Degraded, or Unknown.
- Health is rolled up from everything the exposure reads, all the way upstream. The worst signal wins, so one failed model three steps back is enough to mark the dashboard Degraded.
- Why this health on the exposure's detail lists each upstream model and source in plain words:
built OK, 2 h ago,last build failed, 3 h ago,2 tests failed. You see the cause, not just a red dot. - Filter by name, owner, or type to find the dashboards you are responsible for.
Data Promises
Most dashboards have a time by which their data has to be ready, usually before the morning meeting. Open an exposure, and under Data promise set Data expected by: a time of day, a time zone, and every day or weekdays.
- Each day, dbdeux judges the promise from what really happened: Delivered on time (for example "Delivered 06:12, 48 min early"), Late ("Late: delivered 08:12, 1 h 12 min after the deadline"), or Missed ("Missed at 07:00: no upstream build has been recorded").
- Recent outcomes on the exposure and the outcome on its row in the Exposures list show the record at a glance, so you can tell a one-off from a pattern.
- When a promise is missed, the exposure's owners are told, along with any notification rule that listens for Exposure data promise missed and your webhooks. Every organization starts with a default rule for it, and each owner can turn the alert off under Missed data promise in their preferences.
Power BI Dashboards Without Writing YAML
Writing an exposures: block for every report is the step most teams skip. Auto exposures from Power BI fills the gap: choose a Power BI credential from Integrations, press Scan now, and dbdeux reads your Power BI workspaces.
- A Power BI semantic model becomes an Auto exposure when at least one of its tables is a model, seed, snapshot, or source of this project, matched on database, schema, and table.
- Auto exposures appear in the same list with the same health and data promises, and their detail shows the Reports built on them and when they were first and last seen.
- Rescan every 6 hours keeps the list current: new semantic models are added and ones Power BI no longer has are dropped. Your YAML exposures are never changed.
- If your Power BI tenant has not allowed the scan yet, the card says Power BI needs a Fabric administrator's consent and what to switch on. Nothing changes in dbdeux until then.
Put the Verdict Inside the Dashboard
Embed health tile creates a small tile with the exposure's verdict in plain words, the top reason, the last rebuild, and its data promise, refreshing every minute. Copy the snippet into a web-content or text visual in your dashboard.
- Choose who can see it: Anyone with the dashboard can see it, or Only signed-in members of this organization.
- The tile shows this exposure's health only, nothing else from your project, and you can revoke it any time from the catalog's share links.
Exposures in the Editor
Exposures now show in the editor's lineage graph as their own nodes at the end of the chain. Type __exposure in a YAML file to insert a complete exposures: block, and the run preview understands exposure: selectors, so +exposure:weekly_metrics shows everything that dashboard reads before you build it.
Governance Metadata
When your project uses dbt's governance features, the detail pane surfaces them so consumers know how a model is meant to be used:
- Contract - a badge when the model declares an enforced contract, signalling that its column names and types are guaranteed
- Access - the model's access level (
public,protected, orprivate), so it is clear which models are safe for other teams to reference - Group - the owning group a model belongs to, along with the group owner, so it is clear who is responsible for a set of models
- Version - the model version, with an "outdated" indicator when a newer version exists so you can steer consumers to the latest one
- Deprecation date - a clear sunset date when a model is scheduled to be retired
These fields stay hidden for models that do not use governance, so the pane stays clean for everyone else.
Project DAG Graph
The Graph tab renders a full, zoomable whole-project lineage graph. Unlike dbt docs serve, the graph layout is computed server-side from the ingested manifest, so the browser never parses multi-MB artifacts.
Key capabilities:
- Longest-path layered layout - nodes flow left to right, grouped by dependency depth
- Zoom, pan, and minimap - navigate large graphs with standard controls
- Search - find and center any node by name
- Type-colored nodes - each node type has a distinct color matching the Browse list
- Click-to-inspect - clicking a node opens its full detail pane inline beside the graph, without navigating away
- Full transitive highlight - clicking a node highlights its entire upstream and downstream lineage, not just its direct neighbors, so you can see everything a change could touch at a glance
- Shared portal support - the same graph is available in the no-login docs portal via share links
When a project is too large, the graph shows the closest neighbors and displays a "showing N of M nodes" indicator.
Focused Lineage
Instead of taking in the whole graph at once, focus on a single node's neighborhood. Pick a node as the anchor and choose how many hops of upstream and downstream lineage to show. The graph redraws to just that neighborhood, so tracing how one model connects to its sources and consumers stays readable even in a large project. Focus mode works the same way on the authenticated graph and in the no-login docs portal.
Hide-Layer Filters
Large graphs often carry layers you do not need in a given view. Hide-layer filters let you exclude nodes by tag, file path, schema, or type so the graph shows only what is relevant. For example, hide staging models to see just marts, or hide tests to focus on data flow. You can also multi-select specific models to hide, or use Hide this model directly on a node to drop it from the view without building a filter expression. The filters apply in both Browse and Graph, and are carried into share links, so a link opens with exactly the view you curated.
Catalog Versions and History
Each time your docs are generated from an environment, whether from a scheduled job or from the editor, the catalog publishes a version of that documentation. Versions are never rewritten, so the catalog is a history you can go back through rather than a single view that the next run replaces.
The easiest way to keep this current is to let a job do it: tick Generate docs on run on any scheduled job and your documentation refreshes after each successful build. This works the same way for projects hosted by dbdeux, which have no repository, so a managed project's documentation history is just as complete.
Browse a Point in Time
Two pickers sit in the catalog header:
- Environment, which scopes the list to a single environment. Only environments that actually published documentation appear, so the list never offers you an empty choice
- Version, which is Latest (live) by default. Pick any published version to pin the whole page to it
While a version is pinned, a banner keeps it obvious what you are looking at: the version number, the environment it came from, when it was generated, and who or what generated it. Everything you do while pinned, including browsing, searching, the graph, and node details, reads from that version. Clear the pin to return to the live view.
This answers the questions a single mutable catalog cannot:
- What did this model look like before last night's release?
- When did that column change type, and who shipped it?
- What did the stakeholder actually see when we sent them the docs last quarter?
Compare Two Versions
Choose a base (older) and a head (newer) version and compare them. The summary counts what moved between the two:
- Models added, removed, and changed
- Columns added and removed, and column types changed
- Descriptions changed
- Tests added and removed
Below the summary, each affected model is listed with what changed about it, so a schema change review becomes reading a diff rather than clicking through nodes and remembering what they used to say. This is useful before announcing a breaking change, during an incident review, and for showing an auditor exactly what changed between two dates.
Pin a Share Link to a Version
When you share docs, you can pin the link to a specific version instead of the live view. Recipients keep seeing exactly that version even after your team regenerates docs, which makes a link you put in a data contract or a board pack stable. Versions that an active share link points to are never removed from history, so a pinned link cannot quietly break.
How Long History Is Kept
History is kept per project and environment according to your plan. Older versions beyond that are cleaned up automatically, with pinned versions always preserved. Your current allowance is visible under Plan & Limits in Organizations.
Model Health, Performance, and Recommendations
Each model carries an at-a-glance health verdict so you can spot trouble without opening every node:
- A colored dot marks each model healthy (green), caution (amber), degraded (red), or unknown (gray)
- The last run status is shown inline, so you know whether a model built cleanly on its most recent run
- Health counts appear in the filter panel, so you can jump straight to everything that needs attention
Open a model to see its performance history: the execution time of each recorded run, so you can see whether a model is trending slower over time and catch a regression before it becomes a problem.
Where dbdeux can suggest an improvement (for example a missing test, an absent description, or a model that has been slow across recent runs), it surfaces a recommendation on the node, turning the catalog from a passive reference into an active checklist for keeping your project healthy.
Recommendations now include what the last runs taught dbdeux about speed. A view read by several models is recomputed by each of them, so the recommendation names it and suggests building it as a table. A slow model or test gets the same plain advice as the run's Performance tab.
Custom References (Annotations)
Attach arbitrary metadata to any catalog node or individual column. References are user-curated attributes that live outside your git-managed schema YAML, so anyone on the team can add context without opening a pull request.
How it works
- Click Add reference on any node's detail pane to create a new label-value pair
- Pick a value type so the reference renders correctly:
- Link: a clickable URL (e.g., a Jira ticket, wiki page, or dashboard)
- Email: a click-to-mail address for the owner or on-call contact
- Date: a formatted date (e.g., a review or deprecation date)
- Code: monospace text for identifiers like a ticket key or commit SHA
- Text: plain notes
- Add free-form tags to group and categorize references
- Search and filter references by label, value, or tag to find them quickly on busy nodes
- Each reference shows its provenance: who added it and when
- References are scoped per project and tied to the node's unique identifier, so they survive manifest re-ingestion
- Column-level references work the same way: in the columns table, each column has its own "Add" control
Common uses
| Label | Type | Example value |
|---|---|---|
| Requirement Link | Link | https://jira.example.com/browse/DATA-1234 |
| Data Owner | Text | analytics-eng@company.com |
| SLA | Text | Refreshed daily by 06:00 UTC |
| PII Classification | Link | https://wiki.example.com/data-classification |
| Deprecation Notice | Text | Replaced by stg_customers_v2 after Q3 |
References are visible to anyone browsing the catalog and editable by any project member with write access. In a shared docs portal they are shown read-only alongside the node and its columns, so the context your team curated travels with the documentation you send out instead of being visible only to signed-in members.
Column-Level Lineage
For each output column of a model, Atlas Catalog traces which upstream columns it is built from. The lineage comes from the compiled SQL of your last build and understands each warehouse's SQL dialect, so it works across all supported warehouses.
This helps with:
- PII tracking: Follow a sensitive column through every model it reaches
- Impact analysis: Know exactly which output columns change when you rename or remove an upstream column
- Debugging: When a metric looks wrong, trace that one column back to its source
The Column Graph
The model graph tells you which models depend on each other. The column graph tells you which columns do. On the lineage graph, select a model, click Focus lineage to load only the area around it, then click Columns in the focus pill: the model and its neighbors are redrawn as cards listing their columns, with an edge from every column to the columns built from it. From the editor, Open in Atlas Catalog takes you straight to this view for the model you were looking at.
Calculated columns are traced too: a column built with CASE, arithmetic, or a function links to every column it uses, and macros are already expanded because the graph reads the compiled SQL of your last build.
| What you do | What happens |
|---|---|
| Click a column | The graph traces it. Only the columns it comes from and the columns it feeds stay lit, across every card on screen. Click Stop tracing this column to clear it |
| Change the hops | Separate upstream and downstream controls widen or narrow the area around the model, up to 20 hops each way. Widen upstream to follow a column back to the raw source |
| Double-click a card | Opens that model's details, just like in the model graph |
| Back to model view | Returns to the model-level graph with the same model selected |
Each edge says how much you can trust it:
| Edge | Meaning |
|---|---|
| Solid (Exact) | Parsed from the compiled SQL. The column really comes from there |
| Dashed (Approximate) | Part of the SQL could not be resolved, for example a column built by a dynamic macro. What is shown is correct, but some inputs may be missing |
Each edge also says what happened to the column on the way, with its style, a filter chip, and the expression on hover. Search by expression, follow the chain hop by hop, and see the same badges on a model's columns in its detail. The editor's column graph shows the same kinds while you type.
| Kind | Meaning |
|---|---|
| Pass-through | The upstream column kept under its own name |
| Renamed | The upstream column under a new name, value unchanged |
| Derived | Computed from one or more columns (CASE, arithmetic, CAST, a function) |
| Aggregated | An aggregate or window function over upstream rows |
| Constant | No column input: a literal or a function of literals |
| Unknown | The SQL could not be classified |
When lineage is approximate or missing, Why lineage may be incomplete explains the reason in plain words, such as a model that has not been built yet, or SQL the parser does not support, and what to do about it. Columns with no lineage path are listed as such instead of being hidden, so an empty graph never looks like a model with no inputs. Very large areas show the closest nodes first and tell you to lower the hops to see the rest.
The column graph is also available to everyone who opens a shared catalog link. It is read only and follows the link's settings: a link pinned to a version shows the lineage of that version, and models hidden from the link stay hidden in the column graph too.
Why This Is Different
| dbdeux | dbt docs | Separate lineage tools | |
|---|---|---|---|
| Column-to-column graph | Built in, next to the model graph | Not available | Usually a separate product and login |
| Trust signal per edge | Exact or approximate, with the reason | Not available | Often not shown |
| Same graph in shared docs | Yes, read only, pinned to the shared version | Not available | Usually requires a seat |
| In the editor | Yes, see DAG Explorer | Not available | Not available |
Owners
Every data question eventually becomes a people question: who decides what this metric means, and who do I page when this model breaks? Those are two different people, so Atlas Catalog tracks two kinds of owner on every model, source, seed, snapshot, exposure, and metric:
| Owner kind | The question they answer |
|---|---|
| Business owner | Who to ask about meaning, definitions, and business rules |
| Technical owner | Who maintains the code and fixes it when it breaks |
Owners are real members of your organization, picked from a member search by name or email, so an owner is always someone you can actually reach rather than a string in a YAML file. If an owner later leaves the organization, their assignments stay visible and are clearly marked, so you can see exactly which objects need a new home instead of discovering it during an incident.
The right owner is not always a member yet. If the person who really knows fct_revenue has never signed in to dbdeux, type their email address into the same owner picker: they are invited to the organization and pencilled in as owner in one step. Until they accept, the object shows a dashed invited chip with their address so nobody wonders whether the assignment was made, and the moment they first sign in the chip becomes a normal owner with their name. A pending owner can be cancelled from the chip, and the invitation itself is managed with everyone else's under Organizations, Members. Owner invitations grant at most the Member role; administrators are invited from the Members tab.
Three Ways an Owner Gets Assigned
Adopt from dbt. If your project already records ownership in meta (keys such as owner, business_owner, steward, technical_owner, or maintainer), in a model group's owner, or in an exposure's owner block, the catalog reads those hints, matches them to organization members by email or display name, and offers them as one-click Adopt suggestions on the object. Nothing is written until you accept, and adopted owners carry an Adopted from dbt meta marker so it is clear where they came from.
Assign by hand. Add or change owners directly on any object from its detail pane. To cover many objects at once, switch Browse into selection mode, tick the entries you want (or everything loaded), and use Assign owners to add the same people to all of them in one action. Objects that already have that person keep their existing assignment untouched.
Ownership rules. For a project with hundreds of models, naming owners one at a time does not scale, so you can give every object in a folder, a modeling layer (staging, intermediate, marts, and any other layer your project produces), or a dbt tag a default owner. Rules re-apply automatically on every new catalog version, so a model added to models/marts next week is owned the moment it lands. Owners that came from a rule show an inherited chip naming the rule that assigned them. Hand-picked owners are never overwritten by a rule, and if you remove an inherited owner from one object, the catalog remembers that choice and does not put it back. Deleting a rule removes only the owners it assigned.
Find Objects by Owner
Browse gains an owner filter: everything, mine, unowned, or a specific member. Combined with the existing layer, schema, group, and health filters, "unowned marts models" or "everything Priya owns that is degraded" is one filter combination rather than a spreadsheet exercise. Owner names also match in the search box.
Owners Everywhere the Catalog Is Read
Owners appear on the node detail pane, in Browse, in the read-only portal behind a share link (names only, never email addresses, so a public link does not leak contact details), and to a connected AI assistant when it asks about a model. Every assignment, removal, adoption, and bulk change is recorded in the Audit Log.
Owners Hear About It
In most catalogs an owner is a label: it tells you who to chase, and then you chase them yourself over chat. In dbdeux, being an owner means the catalog keeps you in the loop without anyone having to remember you exist.
Owners are told, by email and in Slack when the project has a channel set up, when one of three things happens to an object they own:
| Alert | When it fires | What it tells you |
|---|---|---|
| Owned model changed | A new catalog version is published and a model you own is different from the previous version | Which models changed, with the columns added or removed, tests added or removed, and whether the description changed, plus a link to the catalog version |
| Slimmer CI failure | A pull request build fails on a model you own, or on one of its tests | The model, the failing test or step, and the pull request, so the technical owner sees a break before it is merged |
| Questions and change requests | Someone asks a question or requests a change on an object you own | The request itself, with a link to the thread on the object |
| Missed data promise | An exposure you own was not rebuilt by its promised time of day | The exposure, the deadline, and why it counts as missed, with a link to the exposure. See Data Promises |
Each person decides what they want to hear about. User Preferences gains an Owner alerts section with a switch for each of the three, so a business owner who wants questions but not build failures can say so. Test failures are attributed to the model they test, so the owner of fct_revenue hears about not_null_fct_revenue_customer_id failing without owning the test separately.
Ask a Question or Request a Change
Every catalog object has two buttons at the bottom of its detail pane: Ask a question and Request a change from the owners. Both take a one-line title and as much context as you like ("which column, which report, what you expected to see" for a question; "new column, changed logic, deprecation, tests to add" for a change), and both go straight to the object's Business and Technical owners.
The result is a Requests to owners thread that lives on the object, not in someone's inbox:
- Owners reply in the thread, and everyone who can see the object can read the answer, which turns a one-off question into documentation
- A change request moves through Open, In progress (the owner clicks Start working), and then Resolved or Declined, so the person who asked can see where it stands without following up
- Status can be changed by the requester, the object's owners, or an organization admin, and every status change and reply is recorded in the Audit Log
- If an object has no owners yet, the request is still saved on it. Nobody is alerted until owners are assigned, the thread says so plainly, and once owners exist they can pick it up from there
Compare this with the usual pattern of pasting a model name into a team channel and hoping the right person is online: the question reaches the right people by definition, the answer stays attached to the object it was about, and the coverage scorecard already tells you which objects have nobody to ask.
Project Health: One Score for the Whole Project
The Health tab in Atlas Catalog scores each project from 0 to 100 against 71 rules covering documentation, tests, structure, performance and run history. Each rule counts once in the score, and each finding names the model and the fix.
- Ask Atlas to fix on any finding drafts the change for you.
- Health score trend appears once there are two reports, so you can see the project improve over time.
- Badges everywhere you work: models carry their health in Catalog browse and in the editor's file tree, and the Catalog Organization view rolls every project up into one picture.
- Honest about what it could not judge: before a project has runs, the run rules (failing, flaky and slow models) are marked as not evaluated instead of counted as passed.
- Accept a finding on purpose: add
-- dbdeux-ignore rule-id reasonto the model's SQL, ormeta.dbdeux.ignorein its YAML. The reason is part of the record.
How strict it is is set once for the organization, under Organization settings > Project Health policy:
| Policy | What it means |
|---|---|
| Default | Built-in severities |
| Strict | Documentation and tests are errors |
| Enterprise | Strict, plus governance, PII and sources |
In Slimmer CI, each project chooses a Project Health gate: Off, Warning (the default: report findings, never fail the check) or Error (fail the check on an error finding or a suppression without a reason). The pull request comment shows the score change against the base branch and the findings on changed files.
Usage: Who Reads Each Model
Each model's detail has a Usage section: the models and exposures that read it, the reads from outside dbt in the last 30 days (BI tools and ad hoc queries, recorded by Cost Insights on Business and up), and which columns are actually read. Usage inside the project shows on every plan. When reads from outside dbt are not known, it says Unknown instead of guessing, so Read by nothing is never a false alarm.
- Find what nothing reads: the Usage filter in Catalog browse lists models marked Read by nothing, and the cleanup list shows what each one costs to build when Cost Insights is set up.
- Clean up in one click: Retire with Atlas opens a pull request that either adds a
deprecation_dateor removes the model, and Drop unused columns with Atlas rewrites the select list and the YAML without those columns. Nothing changes until the pull request is merged. - Project Health flags unused models and columns too, and skips those rules, with the reason, when reads from outside dbt are not available.
Coverage Scorecard
The coverage view provides animated ring charts showing your project's documentation health:
- Node documentation % - what fraction of models/sources have descriptions
- Node test % - what fraction have at least one test. Sources are excluded from test coverage, because sources are usually validated downstream and flagging every source as untested only produces noise you learn to ignore
- Column documentation % - what fraction of columns across all nodes have descriptions
- Ownership % - what fraction of objects have at least one named owner, with a business-owned and technical-owned split, a per-layer breakdown, a count of objects whose only owners have left the organization, and a plain-language recommendation for what to do next
Breakdown by Schema or Type
Below the rings, a per-slice breakdown shows dual progress bars (documentation and testing) for each schema or resource type. This makes it easy to spot which corner of your project needs attention.
Gap Lists
Drill into three categories:
- Undocumented - nodes with no description at all
- Partially documented - nodes that have descriptions but some columns lack them
- Untested - models and other data assets with zero tests. A source without tests is never treated as a problem, and a test is never itself flagged as untested
- Unowned - objects with no owner of either kind. From this tab you can open bulk assignment for the whole list, or open the ownership rules drawer to cover them with a folder, layer, or tag rule instead of naming them one by one
Each row includes a "View" link to jump to the node and a "Document with Atlas" button that sends the node to Atlas AI for one-click documentation generation.
Models That Could Run Less Often
A model that dbdeux State keeps reusing because its inputs did not change gets a could run less often badge (Business and up) in Catalog browse, with how many runs in a row it stayed unchanged. The suggestion appears after six runs, and shows the build time you would save when it is known. Copy exclude selector gives you a selector to paste into the job's command in the schedule wizard; nothing changes until you save. Each environment's Lag tolerance card lists its longest unchanged streaks.
Ask Atlas in the Catalog
Atlas is available directly inside the catalog. Open the chat panel from a node and ask questions grounded in that exact node: what a model does, where a column comes from, what depends on it, or how to document it. A visible context chip shows which node the conversation is grounded in, so you always know what Atlas is reasoning about, and it never silently answers about the wrong model. The chat is scoped to the catalog's selected project, so answers stay grounded in the project you are actually browsing.
When you use Document with Atlas on an undocumented model, it opens this in-catalog panel and generates a description without sending you to the editor. The generated documentation is written back into a shared, folder-level schema file following the dbt-standard naming convention _<directory>__models.yml (for example _netsuite__models.yml), so a folder's models are documented together in one place rather than scattering a separate YAML file next to every model.
Column names are written back exactly as your warehouse reports them. A column that is upper case or mixed case is quoted in the YAML, because an unquoted CUSTOMER_ID and a quoted "CUSTOMER_ID" are not the same thing to dbt, and getting that wrong is how documentation silently stops matching a column. When Atlas updates a file that already documents some columns, it matches existing entries whether or not they were quoted, so re-documenting a model adds what is missing instead of creating a second entry for a column you already described.
Sharing Catalog Docs
Share your project's documentation externally with stakeholders who do not have a platform account. Recipients get the model graph and the column graph, read only:
Access Modes
| Mode | How it works |
|---|---|
| Public | Anyone with the link can view (default) |
| Password | Viewer enters a passphrase once; only its hash is stored |
| SSO | Only signed-in members of your organization can access |
Email Sharing
After generating a link, use the built-in email composer to send it directly to stakeholders. The email includes a branded template with a direct link to the docs portal.
Docs Portal
Recipients see a read-only documentation portal with the full catalog: searchable node list, descriptions, columns, tests, lineage, and your curated references. No login required for public and password-gated links. Any focused-lineage view and hide-layer filters you set are preserved in the link, so recipients open the exact view you intended. The portal header states which environment the documentation came from, so a reader is never left guessing whether they are looking at production.
Share links resolve correctly for projects that live in a shared workspace, so a catalog you share from an organization workspace opens for its intended audience rather than failing to authorize.
How It Compares
| Capability | Atlas Catalog | dbt docs / Explorer | Other tools |
|---|---|---|---|
| Browsing speed | Instant (server-indexed, paginated) | Slow for large projects (full manifest download) | Varies |
| Node type coverage | All 8 types: models, sources, seeds, snapshots, exposures, metrics, macros, analyses | Models and sources only | Varies |
| Project overview | Rendered __overview__ doc block with resolved refs | Raw markdown block | Not available |
| Whole-project DAG | Server-rendered, zoomable, with inline detail pane | Client-rendered (downloads full manifest) | Separate tools |
| Coverage scoring | Built-in with animated scorecards and gap lists | Not available | Requires separate tooling |
| One-click doc fix | "Document with Atlas" sends to AI for instant generation | Manual YAML editing | Manual |
| Column lineage | Built-in, dialect-aware, on demand | Not available in dbt docs | Separate paid tools |
| Warehouse metadata | Row counts, storage, types, freshness - auto-updated | Requires separate dbt docs generate and manual viewing | Varies |
| External sharing | Tokenized links with public/password/SSO gates, including overview and graph | Not available | Requires platform access |
| Freshness tracking | Inline staleness indicator with pass/warn/error | Separate dbt source freshness command | Separate monitoring |
| Custom references | Attach arbitrary label-value annotations (links, text) to any node or column | Not available | |
| Ownership | Business and Technical owners who are real members, adopted from dbt meta, assigned in bulk, or inherited from folder / layer / tag rules, with an ownership coverage score and unowned list | Owner shown only if declared in meta or a group; no coverage, no rules | Usually a separate data catalog product |
| Documentation history | Every generation publishes an immutable version you can browse, compare, and pin a link to | Latest generation only, previous docs are overwritten |