Warehouse models your product and finance people can query

I have sat in rooms where three dashboards disagreed on "revenue" and everyone blamed the BI tool. The tool was fine. The model had three grains and no owner.

Atalaya's job on the model layer is simple: one table a human can query without calling an engineer.

Grain first

Before columns, write the grain in a sentence.

• fct_orders is one row per order per plant.
• fct_telemetry is one row per signal per interval.
• dim_consent is one row per patient per purpose.

If two people cannot agree on the sentence, do not build the table. You will build two tables anyway, later, under worse names.

Names that survive a handover

We use boring names: fct_, dim_, stg_. We do not encode the source system in the public model. Renault floors, a dealer DMS, or a hospital HIS should land in staging. The mart speaks the business.

Product and finance do not care that the extract came from a FastAPI job on GCP. They care that ordered_at is a timestamp in Europe/Paris and that VAT is not mixed into net.

One place for the metric

If "on-time delivery" is defined in a Looker view, a dbt metric, and a Python notebook, you do not have a metric. You have a debate.

We put the definition in the warehouse — a dbt-shaped model or a SQL view the API also reads. Boards and apps consume that. When the definition changes, it changes once.

APIs we ship for "model and serve" are thin: auth, filters, the same grain. No hidden aggregations that contradict the table.

Sized for a small team

You do not need a semantic layer product and a data mesh slide to get this right. You need a warehouse you can pay for, models you can read, and tests on uniqueness and not-null for the grain.

That is enough for a team that has to move.