A semantic layer

Model your business, not your tables.

Name the things your organization cares about, how they relate and how they are measured, once and in your own words. Every query is generated from that.

A model in Futuremodel's words: the Entities Order and Customer, the Relation between them and the Metric Total Revenue. Beside it, the SQL generated from that model for a warehouse.
CommerceDomain
  • OrderEntity
    • revenueQuantity
    • statusCategory
    • has CustomerRelation
  • CustomerEntity
    • countryCategory
  • Total RevenueMetric

    The sum of Order revenue, where status is paid.

The warehouse the SQL is generated for
SELECT  c.country AS customer_country,  SUM(o.order_total) AS total_revenueFROM `shop.sales.orders` AS oJOIN `shop.crm.customers` AS c  ON o.customer_id = c.idWHERE o.status = 'paid'GROUP BY customer_country
SELECT  c."COUNTRY" AS "CUSTOMER_COUNTRY",  SUM(o."ORDER_TOTAL") AS "TOTAL_REVENUE"FROM "SHOP"."SALES"."ORDERS" AS oJOIN "SHOP"."CRM"."CUSTOMERS" AS c  ON o."CUSTOMER_ID" = c."ID"WHERE o."STATUS" = 'paid'GROUP BY "CUSTOMER_COUNTRY"
SELECT  c.country AS customer_country,  SUM(o.order_total) AS total_revenueFROM sales.orders AS oJOIN crm.customers AS c  ON o.customer_id = c.idWHERE o.status = 'paid'GROUP BY customer_country

Total Revenue by Customer country, from Release 12

Generates SQL for

  • BigQuery
  • Snowflake
  • Redshift
  • PostgreSQL
  • MySQL
  • SQL Server
  • Athena
  • Presto
  • DuckDB

What it is

It holds what your data means, and leaves the data where it is.

  • A vocabulary of your own

    Customer, Order, Total Revenue. Entities, Attributes, Relations and Metrics are named for what they mean to you, independently of the tables that hold the data.

  • Descriptions, not a mirror

    Futuremodel records what your data is, not a copy of it. A value is read from its Source when someone asks for it, so what you see is what is there now.

  • One definition, every query

    Say where revenue comes from in one place. The SQL for your warehouse is generated from the model, and every number that depends on it follows.

How it works

From a table to a meaning everyone shares, in four steps.

  1. Connect a Source

    A database, a warehouse, a file store or an API. Futuremodel reads its Catalogs, its Datasets and their Columns.

  2. Ingest it

    Each Dataset becomes a Draft Entity with an Attribute for every Column, and a Profile of each: how complete, how distinct, how fresh.

  3. Shape the model

    Name things, relate Entities, derive Attributes, define Metrics. Every change you save is kept as a Version you can read or restore.

  4. Publish and release

    A Release fixes one Version of everything Published. Queries are generated from it, and nothing live moves until the next.

Versions and Releases

Nothing live changes by accident.

Every edit you save writes a numbered, unchangeable Version. A Release is a set of them, one for each Published element, and it is what your queries are generated from.

Work on the next one for as long as it takes. What is live stays exactly as it was released, and any earlier Version can be read or restored.

The Version of three Model elements in Release 11, in Release 12, which is the current one, and in Draft.
Model elementRelease 11Release 12LiveDraftNot live
OrderEntityv4v5v6
revenueAttributev2v2No Draft
Total RevenueMetricv1v3v4

AI

An AI drafts.
A person publishes.

In Futuremodel an AI is a Party of its own, with the Roles your Governor grants it and nothing more. Whatever Role it holds, it works in Drafts, so a person always stands between an AI and anything live.

The Assistant inside the app answers from what things mean and how many there are, as the person asking and never with more. It is never given a row.

Or connect the assistant you already use, over the Model Context Protocol: it reads a Release, asks for the SQL of a Metric and drafts definitions for a Steward to review.

An AI may

  • View what its Roles allow
  • Shape Drafts
  • Offer Answers to Questions
  • Write Insights

An AI may never

  • Publish or Deprecate
  • Cut a Release
  • Change Visibility
  • Grant a Role

Vocabulary

A language the whole organization can read.

Futuremodel's own vocabulary is small and exact. These are the words you will use most.

Domain
Everything of interest to an Organization, versioned as one whole by its Releases.
Entity
A kind of thing in a Domain, such as Customer, Order or Region.
Attribute
A property of an Entity, held per Individual, such as an order's revenue or a customer's country.
Relation
A directed connection between two Entities, such as "Order has Customer", read from either end.
Metric
An aggregate over the Individuals of an Entity, such as Total Revenue or Count of Customers.
Individual
A particular thing belonging to an Entity: this customer, this region.
Source
A physical system a Domain's data comes from: a database, a warehouse, a file store or an API.
Release
An unchangeable set of Versions, from which a Domain's queries are generated.

Governance

Clear about who decides.

  • Roles

    A Governor speaks for the Organization. Stewards shape a Domain, publish its elements and cut its Releases. Members view and ask Questions. A Role reaches as far as the thing it was granted on.

  • Visibility

    Private, Internal or Public, chosen for each Domain and each Published element. A Draft is always Private, and nothing goes Public without the Governor.

  • Questions and Corrections

    Ask what something means where you are looking at it: a Steward can accept an Answer as its definition. Say a value is wrong without changing any data: a Steward confirms the Correction or dismisses it.

Start with one table.

Request access and model your first Domain. We will email you when your access is ready.