Beyond medallion architecture: the written rules that keep a growing dbt project consistent

Silja Märdla, head of analytics engineering at Bolt, opened her dbt Summit 2026 session with a blunt thesis: having dbt does not guarantee a good data model. Bolt, the European "super app" for rides, delivery, and rentals operating across Europe and Africa, had rolled out dbt without much in the way of rules.

That worked while the analytics engineering team was small. It stopped working once the team grew past 20 people last year, at which point teams were staging the same data differently, informal guidance was being interpreted inconsistently, and answers coming out of the analytics engineering team started to diverge.

Over several months, the team whiteboarded and signed off together on an explicit, written rule set, which Silja presented as 14 specific rules. A few of the more distinctive ones: every table exposed to consumption tools has to be one of exactly three shapes (a single-entity table, a slowly changing dimension, or a table representing a combination of entities, usually with time), and exposed tables should be simple selects on top of intermediate models rather than carrying business logic themselves.

Intermediate models are also limited to three shapes: spine (identifiers and raw attributes), feature (derived business logic on an entity), and metrics (aggregated values on a grain), with metrics kept separate because they're auto-generated from a centralized set of metric definitions rather than hand-built like feature models. A metric is defined once against its source fact table; when it gets aggregated to a different grain elsewhere, Bolt calls that a "feature," not a second copy of the same metric.

No dbt model has shared ownership, and dbt projects have one-directional dependencies that mirror the business itself: a vertical team (rides, delivery, rentals) can read from a horizontal team's project (billing, geo), never the reverse, with shared logic pushed upstream into a common project instead of duplicated downstream.

One more rule addresses a subtler failure mode: metrics that can't legally be re-aggregated across grains, like distinct counts, get split into their own marts away from additive metrics. Bolt's BI tool requires a mandatory "metric key" field whenever a non-additive metric is selected, specifically to stop someone from aggregating it in a way that produces a wrong number without any error.

The rules have been in place for about six months with no major issues. Silja's framing throughout was less about the specific rules and more about the discipline of having them written down at all: "the fact that you do have dbt doesn't mean your data model is good," and "there is no shared ownership of a dbt model" were two of the lines she returned to.

Bolt's structure guide echoes practices in dbt Labs' own best-practices guide for structuring dbt projects, which covers similar staging, intermediate, and marts layering for teams looking to write their own version of this rule set.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →