Tables

Tables hold the data everything else in Ronja is built on. Every table lives in a feature (with one scratch-pad exception — see Session tables below), has a kind that says where its data comes from, a build lifecycle that keeps it fresh, and lineage that connects it to the rest of your data estate.

The four kinds

Each table wears a kind chip, and the product explains each one in a sentence:

Kind	What it means (product copy)
Foundation	“Cleans and standardizes raw source data into a reliable base layer.”
Integration	“Synced from an external connection — its shape mirrors the upstream system.” (Tables updated by uploading files directly also display as Integration.)
Derived	“Built from other tables as inputs, typically via SQL or Python.”
Dynamic	“Written to directly by agents as they run.”

The kind decides what you can do on the table page. Derived tables expose their code — a third tab alongside Result and Catalog — because they’re defined by a query over inputs. Foundation, Integration, and Dynamic tables hide per-table build controls.

Builds

A table’s contents are produced by a build. On the table page you’ll see its state at a glance: a status dot, “Building table…” while a build runs, and banners when something needs attention — “Build failed” with an expandable error, or “Out of sync — showing data from last successful build” when the data on screen predates a change. Stale tables show a rebuild affordance; rebuilding is a Data Admin action.

Ronja sizes each build automatically — you’ll see a small read-only badge (Light, Batch, and up) and, for big tables she builds in several pieces at once, a Parallel badge. Nothing to configure; it’s just telling you how heavy the build was.

Lineage

Tables don’t exist alone, and the table page shows their connections directly:

• Inputs — the tables a Derived table is built from.
• Dependents — the downstream tables built from this one.
• Producers — the workflows that write this table.

A “Show in architecture” action opens the table’s pipeline in the organization-wide architecture graph, and from a feature’s Inventory list, “View in graph” shows a resource’s cross-feature dependencies. Lineage is why Ronja’s answers are traceable: you can always walk from a number back to its sources.

A table’s page shows its own lineage; to see the whole picture — how this table connects to the workflows, notes, and data apps around it, including links that cross into other features — open the Graph action on the feature it lives in.

Reading a table

The Result tab previews the data — small tables render in full as a searchable grid; larger ones show a capped preview. The Catalog tab is the column-statistics view: Field, Kind, Rows, Missing, Cardinality, and Examples per column. The “Explore this table” button starts a fresh exploration anchored on the table — “Ask anything · build · transform”.

Changing a table safely

Edits to tables go through per-user drafts: your changes live in a draft (one per person per table) until they’re committed, and edits to shared tables by non-admins wait for review before going live. Version history lets you restore an earlier committed version. The full lifecycle is covered in Versions, drafts, and approvals; the hands-on recipe is Create tables with Ronja.

Two special cases

• Session tables — scratch tables that exist only inside one exploration. In the product’s words: “This is a scratch table that only exists in this session. It isn’t saved to a feature and can’t be opened elsewhere.”
• Data dictionary tables — a table can be marked as a data dictionary and linked to the tables it describes, powering column and table descriptions across the product. See Maintain the data dictionary.

Note

Like everything in a feature, a deleted table goes to the trash and can be restored for 30 days before it’s permanently purged. See Restore from trash.

For a compact comparison of the kinds — source, rebuild behavior, editability — see the table types reference.