Why FeatureMesh?

FeatureMesh is a set of foundations and tools for business logic. You define named, typed, composable calculations, called features, in a language called FeatureQL. A compiler turns the definitions into SQL for your warehouse or for a real-time serving engine. A registry stores the definitions and validates every change against what depends on it.

The gap

Data has SQL. Applications have backend code. The rules in between have no language of their own: customer segments, eligibility, pricing thresholds, KPIs. They live in views, semantic-layer configuration, backend if statements and wiki pages, often in several of those at once. Each copy has its own owner and its own release cycle.

FeatureMesh gives that layer a language, a compiler that refuses a class of mistakes, and one place where definitions live.

Why now

Two changes point at this layer.

Who writes the logic. The cost of a new language used to be teaching people to write it. A model that has the documentation, the vocabulary and the diagnostics in its context lowers that cost. A language that refuses mistakes also becomes more useful, because a model acts on a precise error message and does not notice a plausible wrong number. See FeatureQL and language models .

What AI is asked to do. Models first answered questions about business data. They are now asked to act on it: adjust a threshold, target a segment, change a rule. That needs a surface that is typed, versioned, testable against history and reversible.

How it works

A feature is one named calculation on an entity: "customer lifetime value", "eligible for discount", "days since last order". An entity is what the calculation is about, such as a customer or an order. Features reference other features by name, and the compiler resolves dependencies and data access. A spreadsheet is a close analogy: a feature is a formula with no data in it, and a query binds it to keys.

Three properties carry the design:

Composition. The unit of reuse is a single calculation. A feature is reused by name at another grain, as an API, or in a what-if, without restating the rule. See Composition and substitution .
Semantics in the type. Entity, unit, multiplicity and additivity are declared once, where data enters. Derived features inherit what the compiler can prove. See Semantic contracts .
Decoupled from execution. The compiler emits SQL that runs on your backend. Row data does not pass through FeatureMesh. Across backends, behavior is identical where the engines agree, and a compile-time error names the gap where they do not. A conformance suite tests this. See Decoupled from execution .

The language design overview covers the full model.

Three stages

Each stage is useful without the next one.

1. Answers a person can review

A model that answers a business question composes published features. It does not write SQL against a wide schema.

RETURN CUSTOMER_ID, CUSTOMER_SEGMENT, CUSTOMER_AT_RISK, CUSTOMER_LTV
FROM FM.ECOMM
FOR CUSTOMER_ID := BIND_COLUMNS(...)
WHERE CUSTOMER_AT_RISK

The query is four named features and a binding. The equivalent SQL is around a hundred lines of joins and window functions. The model writes no join and sees no row, and the engine computes the number. Review moves from "is this SQL correct" to "is this the right definition".

Given correct source declarations, a wrong join, a unit mix or an illegal rollup fails to compile.

This stage needs one person, a notebook and a pip install .

2. One definition from analysis to production

The same compiler targets a serving engine, so a validated rule is served and not reimplemented:

CREATE FEATURE HEALTH_PS AS PREPARED_STATEMENT(HEALTH_STATUS USING CUSTOMER_ID)

The definition can be backtested on history in batch and then served at request latency. Heavy aggregations are precomputed in batch and bound as a source. You run and monitor that job. See What you run .

3. Decisions that improve within set limits

Experimentation usually spans three systems: one assigns users, backend code implements the treatment, and a warehouse measures the outcome. Here it is one loop over the same definitions:

Propose an alternative with VARIANT(), which replaces one dependency and leaves the original in place.
Backtest it in batch.
Roll out with GRADUAL_ROLLOUT(), with assignment by HASH01(), which reruns identically.
Measure with the same feature definitions.
Promote or drop. A promoted result is a registered feature that the next experiment can build on.

An agent can drive this loop. The condition is that it may change what is decided and not how it is judged: metrics, guardrails, rollout limits and the override stay outside its write scope. FeatureMesh provides the primitives and the audit trail. The policy around them is configured by you. See A loop for improving the business .

Limits

Intent is not checked. A feature can compile, run identically on every backend, and encode the wrong rule. Whether a definition means what the business means is reviewed by people.
Declarations are trusted. The compiler does not read your data, so its guarantees follow from the source declarations. Those are tested on your side. See Data contracts and What the compiler cannot check .
Backends. DuckDB and Trino for batch, DataFusion for serving.

The FAQ for the skeptical covers these and other objections in detail.

When it fits

If one or two people own the analytics and nothing is reused, SQL files are enough. The case gets stronger as more of these apply:

The same rule feeds more than one dashboard, model or service.
A rule is needed both in analytics and in a request-latency service.
Several people write logic that others build on.
Definitions change often enough that keeping copies aligned takes real work.
Two teams have recently produced two numbers for the same metric.
An assistant should answer business questions, and its output cannot currently be reviewed.