Layered models

A layered model builds on top of one or more existing core models — reusing everything they already define, instead of redefining tables, joins, metrics, and instructions from scratch.

Keep a small number of well-maintained core models as your source of truth, then create focused, purpose-built models that automatically inherit from them.

When creating a new model, select an existing Core model to inherit its shared assets automatically.

From repeated definitions to one source of truth

Maintaining the same logic across several independent models means every fix or update has to be repeated everywhere it's used. Layering removes that duplication by centralizing shared logic in one place.

Layered models let you define shared logic once in a core model, then extend it for each domain-specific use case.

What a layered model inherits

When you query a layered model, the platform resolves its effective assets — its own assets, plus everything from the core models it references. Every table, column, and metric inherited from a Core model is clearly labeled "Fed by" its source throughout the model editor.

One level of inheritance

Layering is a single level by design.

A layered model can reference one or more core models — but a core model can't itself be layered on top of another model.

There's no support for multi-level chains. Inheritance always resolves in exactly one hop, which keeps it simple and predictable — you never need to trace a long dependency chain to understand what a model contains.

How assets are merged

When a layered model's assets combine with its core models', the platform applies simple "own-first" rules:

1. Lists are combined and de-duplicated — tables, columns, queries, and metrics list the layered model's own assets first.
2. Joins, custom metrics, and custom queries combine layered-first — the layered model's definitions come first, then its core models'.
3. Custom instructions merge into one set — layered model instructions first, followed by core model instructions.

The layered model's own definitions always take precedence, while everything useful from the core model comes along automatically.

How layered models behave at query time

A layered model behaves like any other model — whether its ID is passed directly, or the platform routes to it automatically.

Layered models vs. compound models

These concepts are related, but they solve different problems.

Summary

• A layered model inherits tables, columns, queries, metrics, joins, and instructions from its core models.
• Inheritance is one level deep and merged own-first, with de-duplication.
• At query time, the platform checks and generates SQL against the full effective model (own + inherited).
• Layered models are authored inheritance; compound models are query-time routing.

Structure

• Core model is chosen at creation time.
• A layered model can reference multiple core models.
• A core model can't be detached once connected.
• Layered models can't act as core models (max two generations).

Inheritance scope

• Inherits the full core model — no partial selection.
• Includes tables, columns, keys, relationships, metrics, and SQL.
• Layered models can extend inherited assets, but not edit them directly.
• Each model keeps its own benchmark set.

Lifecycle

• Core model changes auto-propagate to prevent drift.
• Applying changes creates a new layered-model version.
• Owners are notified of changes affecting their model.
• Core assets can't be removed if a layered model depends on them.