Data map

Every table in your organization, on one page, with the lines that connect them. The Data map is where you answer “where does this number come from?”, “what else would this change touch?” and “is anyone still using this?” without opening twenty table pages.

Admins reach it from Advanced → Data map in the sidebar. Anyone can reach it from a table: the Show in data map button on a table’s page opens the map with that table’s pipeline already picked out.

Two views of the same thing

A switch at the top left of the page chooses between Graph and Tables. Both show the tables you have access to; they answer different questions. The graph is for tracing a pipeline, the list is for judging an estate.

Two things sit beside the switch: the Filters chip and the search box. Filters gathers every toggle that narrows what the map shows into one chip, with a badge counting how many are on; click it to open the list. Metrics only is in there in both views, and narrows the page to your metrics and what feeds them. The search box covers tables and columns, so a column name you half-remember is enough to find the table that has it — matches are highlighted in whichever view you’re in.

Picking one of the results selects that table rather than filtering the map: it opens the table’s panel, and in the Graph view dims the map to what that table touches. Your search text stays where you typed it — it isn’t a filter, and clearing the box doesn’t undo the selection.

The size of what you are looking at — how many tables and how many metrics — always sits under the bar: at the right end of the lens legend when a lens is on, and on a line of its own when there isn’t one.

Graph

The graph draws each table as a node and each input as an arrow, left to right, so you read a pipeline in the direction the data moves.

Group — Feature draws one card per feature that you open to see the tables inside, which is the view to start from when you don’t yet know where something lives. Table flattens everything into a single table-level flow. When grouped by feature, Expand all and Collapse all — on the canvas itself, at the bottom left beside the zoom controls — open and close every card at once.
Hide singles, under Filters, drops tables that aren’t connected to anything, which is usually most of the noise on a first look.

Grouped by feature, click anywhere on a feature card to open it and see the tables inside. Hovering a card — open or closed — brings up two buttons above it: Open feature goes to the feature’s own page, and Expand / Collapse opens or closes the card. Double-clicking an open card closes it again. The buttons stay the same size however far you have zoomed out.

A line between two closed cards stands for every dependency between the tables inside them, and when it stands for more than one, it carries a number saying how many. Hover that number to read which feature feeds which — or, when one end of the line is a single table, how many tables in the feature feed that table, or how many tables in the feature it feeds. Open a card to see each dependency drawn on its own.

Opening or closing one card keeps that card exactly where it is and slides the others around it, so you don’t lose your place; the map only moves the view if the card you opened would otherwise end up off-screen, and it never changes your zoom. Expand all and Collapse all still refit the whole canvas.

Drag a node to move it. Once you have moved at least one, a Reset layout button joins Expand all and Collapse all at the bottom left of the canvas and puts everything back where the map put it; until then there is nothing to reset and the button isn’t there.

Lens: painting the map with one question

Beside Group sits Lens. A lens paints every table on the canvas with the answer to one question. The feature a table belongs to stays in the container it sits in and its kind stays in the icon — colour belongs to the lens.

The options are None, Freshness, Usage, Cleanup, Health and Builds. Hover a lens name to see the question it answers, before you turn it on. None is the default and is the plain map. Whichever lens is on, a legend appears directly under the control — a row of swatches and what each one means, always visible, never behind a click.

A grey table means the map has no answer for it, not a zero: the table isn’t readable to you, or its history could not be loaded.

A collapsed feature card summarises the tables inside it: a slim bar across the card shows how its tables split under the lens — hover it for the counts — and the card’s border takes the colour of the worst answer in there, so you can see which features need opening without opening any of them.

Freshness

Whether each table’s data is as recent as it should be. Every table is judged by one rule, and hovering it names the rule and the moment it applies:

Tables that load from outside — synced from a connected system, pushed as files, or written to directly by Ronja, a workflow or the API — start Getting old after 7 days without new data and are Stale after 30. A table written exactly 30 days ago is still Getting old. Amber is a note, not an alarm: a weekly table that slipped a day lands here.
A table with a freshness health check is judged by the window that check declares instead. It is Getting old once the expected interval has passed, and Stale when the check itself would flag it — so a table expected to refresh daily turns red after a day and a half, not after a month.
A table built from other tables is judged by its inputs, not by its own age (below).
A Foundation table is not judged unless someone declares a freshness check on it: its age says when raw source data was last standardized, not when a pipeline last ran.
A table marked never stale — a list of country codes, a calendar, a lookup written once — is never judged. Ask Ronja to mark a table as never stale, or set it over the API. Marking it also silences its freshness check, if it has one.

The legend reads Stale (red), Getting old (amber), Fresh (green), Unknown (grey — nothing has ever been recorded as written to it, or the freshness rule couldn’t be loaded) and Never stale, which covers every table the lens does not judge. Those tables are left uncoloured, and the tooltip says why. Metrics are always left uncoloured: they store no data of their own.

Age is the only thing this lens measures. A failing health check and a failed build are real problems, but they are the Health and Builds lenses’ answers, not this one’s.

A table inherits its inputs’ staleness. A table that rebuilt an hour ago from an input that has not loaded in six weeks is showing six-week-old numbers, and the lens paints it red. Hover it and the tooltip names the culprit — stale via orders_raw — and the reason. Only red is inherited; an amber input does not make its consumers amber. A red input is inherited straight through a table marked never stale, too: marking a table does not hide a problem upstream of it.

A table built from other tables is Fresh only when at least one of the tables it depends on is actually judged — one that loads from outside, or one with a freshness check — and none of them is stale. If none of its inputs is judged, it is left uncoloured, with the tooltip Judged by its inputs, and none of them is tracked.

A dashed outline marks a table with a freshness health check. When that check is failing, the outline turns red, and the tooltip adds it in words: Its declared freshness check is failing. The check runs in the background every few minutes, so for a short while after the moment the tooltip names, the table can be red before its outline is.

Declaring a freshness check is the way to say “this one should rebuild nightly” and be told the moment it doesn’t: it sets the table’s window on this map, and it is what alerts your admins. The 30-day rule alone colours the map but alerts nobody.

A small partial tag means part of that table’s lineage is not on the map. Where no cause was found, none is claimed. Where one was, the tooltip names it and adds that other inputs are off-map — so the named input is a real cause, just not necessarily the only one.

Usage

How much each table is read, over the last 90 days, on a ramp that starts at No reads in 90 days — its own rung, with no bar at all — then Barely read up to Heavily read, with a bar under the name for the magnitude. A table with no read in a year is hatched: Not read in a year.

Based on recorded queries: opening a table’s page or its data preview does not count, so a table someone looks at weekly but never queries reads as unread here. Working out a metric — from a chat, from the metric’s own page, or through an app — counts as a read of the metric, and keeps the table it reads counted as in use, though it does not make that table more popular.

Cleanup

The same four states the Tables view sorts by: Healthy, Waste (fresh data nothing reads — it costs builds nobody looks at), Broken (something reads it, but its data is Stale under the Freshness rule — fix it rather than remove it) and Dead (neither). Hovering says which and why, and says when a table is part of a dead chain that should be removed as one decision. A fifth, grey swatch — Not judged — is for the rows this lens has no opinion about: the same metrics, drafts and conversation tables the Tables view will not let you tick.

Broken is a prompt to look, not a fault. A table filled once and read for a year, or topped up each quarter, is over 30 days old most of the time and lands here quite legitimately — which is why nothing read recently can be ticked for removal. If a table is never meant to refresh, mark it as never stale; if you care about how often it is written, say so in a health check.

The Not read in control lives on the Tables view, but it governs both: change the horizon there and the graph repaints at the same window, so the two views can never disagree about what is dead. Acting on any of it is still the Tables view’s job.

Health

Passing, Failing, Check error or No checks, from the table’s own health checks. The tooltip names how many are failing — or just says checks are failing, where the count is not available. A small amber dot under the name marks a table whose column scan has flagged possible personal data, whatever the check verdict.

Builds

Ready, Building, Invalidated or Build failed, plus Waiting on an input whenever some table on the map is in that state (its swatch appears in the legend only then). A table building right now pulses gently (it stays still if your system is set to reduce motion). The bar under the name is how long its last build took, and the tooltip gives the outcome and the duration. Waiting on an input is hatched amber: an upstream change has reached the table, but one of its inputs is still catching up with that same change, so it holds off and rebuilds once, over everything new — the tooltip says how long it has waited and, when Ronja has recorded which input it is waiting for, names it; otherwise it reads that the table is waiting for its turn.

What breaks if I change this

Click any table and the map dims to that table’s blast radius: everything it is built from, and everything built on it, however many hops away. Nothing is hidden — the rest of the map fades, so you keep your bearings.

A strip appears at the bottom of the canvas:

orders_mart · Fed by 3 tables · Feeds 7 tables · Also directly used by 1 app, 2 automations (2 structural)

Fed by and Feeds count the whole chain, however many hops away. Also directly used by counts one hop — the apps, automations and notes that name this table. An app that reads a table further down the chain is not in that number; select that table to see it. “Structural” consumers are the ones that stop working if the table changes; the rest merely mention it. Clear (or a click on empty canvas) returns the whole map, and so does closing the table’s panel or pressing Escape. Escape leaves your search text alone.

With the Freshness lens on, selecting a red table that is red because of one of its inputs also draws the path back to that input in red and fades every other connection — the shortest answer to “why is this number wrong”. A hop that runs through a collapsed feature card isn’t drawn; expand the feature to see it, or read the cause off the strip, which names it either way.

Tables

The same estate as a sortable list, which is the faster view when you know roughly what you’re looking for — and the view that answers whether a table still earns its keep.

Each row carries the table’s Name, its Feature, its Kind, its Level (how many hops from a source it sits), its Status, how many tables it reads (Inputs), and when it was last Updated. Between them sit five columns that answer “is anyone still using this, and is its data still arriving”:

Column	What it says
Last read	When something last queried this table. `> 1 year` means nothing has queried it inside the last year.
Last built	When data was last written to the table. `unknown` means Ronja has no record of a write; `building` means a build is running right now. A warning marker appears once the table is past its refresh window under the Freshness rule above — hover it and Ronja names the window that was crossed. Tables that rule does not judge never carry one, so an unmarked cell is not on its own evidence that the data is recent.
Health	The table’s health checks, the same marker the table page shows.
Used by	How many other tables read this one, hidden tables included. A struck-through count means every one of those tables is unused too — the whole chain below this table is dead. Hover it: when a metric reads this table, Ronja says so — a metric is a consumer the cleanup lens cannot judge, so a table a metric reads is never offered as a cleanup candidate.
Size	How much storage the table occupies.

At the end of each row, a label sums the two questions up: Waste (fresh data nobody reads), Broken (someone reads it, but its data is stale) or Dead (neither). A healthy table is left unlabelled.

Name, Level, Last read, Last built and Updated are sortable — click the column heading.

Group in this view is two independent switches: Feature and Source. Turn on neither and you get one flat list; turn on both and the list nests feature by feature and then by where the data came from. Show hidden tables, under Filters, brings hidden tables into the list; they are left out by default. Each row has a Show pipeline action that jumps to the Graph view with that table’s pipeline in focus.

Presets

Above the list, Preset narrows it five ways, each with a live count:

All — every table.
Cleanup candidates — unused tables with no live table dependent that is still in use. This is the shortlist to start from. Based on recorded queries — other consumers are checked when you preview a removal.
Broken — someone still reads it, but its data is Stale under the Freshness rule. Fix these; do not remove them — and they cannot be ticked for removal here. A slow or one-shot load sits in Broken quite legitimately: a table filled once and read for a year, or pushed each quarter, is over 30 days old most of the time. Mark a table that is never meant to refresh as never stale, and if you care about how often a particular table is written, say so in a health check rather than reading it off this preset.
Waste — the data is fine, nobody reads it.
Not read in a year — the widest question, and its own tier because it is where the “recorded queries” caveat matters most.

Beside them, Not read in sets the horizon the unused test uses: 30, 90 (the default) or 180 days.

Under Cleanup candidates, tables that feed each other are grouped into a Dead chain — one row for the whole chain, with its members listed beneath — so raw → staging → mart is one decision rather than three. Grouping by Feature or Source is ignored under this preset, because a dead chain crosses features and splitting one across cards is how a head gets trashed without its tail.

Removing tables

Tick the tables you want to remove, or tick a Dead chain to take the whole chain at once. A footer appears showing how many are selected and how much storage they hold.

Three kinds of row cannot be ticked, and hovering the box says which: a table that was read recently (Read recently — not a cleanup candidate), Broken ones included — something still queries them, however old their data is; a table Ronja has no read history for at all (No read history available) — a missing history is not evidence that nothing uses it; and a row the cleanup lens does not judge in the first place (Not judged by the cleanup lens) — a metric, which stores no rows of its own — it is a recipe recalculated from its sources — so there is nothing about it to go stale or to reclaim; a draft copy of a table; a table that belongs to a single conversation; and anything already in the Trash.
Click Preview removal →. Ronja checks what depends on each table.
Read the preview:
- A table that something else still depends on is Blocked and unticked, and the preview names what depends on it. Add that thing to the selection if it is dead too, or rewrite it first.
- A table mentioned in a note is not blocked, but its tick box only enables once you click Mentioned in N places — show before removing and read them. Mentions are the one consumer no ledger can see, so Ronja makes you look before you remove.
Click Move N to trash. Ronja removes them one at a time, dependents first, so a whole chain goes cleanly. Each removal records why — “not read in 104 d (horizon 90 d), no live dependents” — which is what a colleague sees if they later wonder what happened. The note states only what Ronja actually checked, so it names the horizon that was applied and never claims a read history it does not have.
You get a result for every table. Anything the server refused stays in the list with the reason. While a removal is running you cannot cancel or dismiss the dialog — closing it would hide the run, not stop it.

The peek panel

Clicking a table — a node in the graph, a row in the list — opens a read-only panel beside it, so you can check a table without losing your place on the map. It shows:

Metadata — the basics, plus Reads (how much the table is actually queried) and Recent builds.
Schema — the columns and their types.
How it’s calculated — for a derived table, the logic behind it.
Lineage — the other tables around this one: what feeds it and what it feeds, ordered by how many hops away each one is.
Used by — everything that isn’t a table: the workflows, apps and other resources built on it. Tables aren’t repeated here, because they’re already in Lineage above.

Open opens the table’s own page — where you can edit, share, move or check it — in a new tab, so the map keeps your place. The map itself changes nothing: it is a place to look, and every action it offers hands you off to the page that owns the change.

The same neighbourhood is reachable without leaving a conversation: a table’s side panel in chat carries a Map tab, described in The Map.

The page’s web address carries what you are looking at, so a link shows a colleague the same thing. The Graph view’s lens rides in ?lens=freshness; the Tables view’s ?preset= and ?horizon= carry the shortlist and the window it was judged on. A link can carry both, and an unrecognised value simply opens the plain map.