Skip to content
Dex

Self-building analytics, owned by your team

A harness for Dex, deployed on your infrastructure. Scope the question. Build the change. Catch the drift. Tested dbt changes arrive as draft pull requests, and your team decides what ships.

Book a DemoExplore open-source DexNew to Dex? Read the docs
  • ✓ Deployed on your infrastructure
  • ✓ Opens a draft pull request
  • ✓ Never merges it
Fig. 1 — Sources to reviewed change

Sources

SnowflakeDatabricksBigQueryRedshiftClickHousePostgreSQLTrinoDuckDB
DexEnterprise
  1. 1Scopegoal → scoping report
  2. 2Buildticket → draft PR
  3. 3Fixschedule → drift fix

□ staging/stg_orders.sql

□ semantic/metrics.yml

drift → automated PR

Governed semantic layer

Single source of truth

dbt Semantic LayerApache OssieSLayerCubeSnowflake Semantic ViewsDatabricks Metric Views
  • PII flagged
  • Reviewed diffs

Your agent

Claude CodeOpenAI CodexCursor

Grounds on the same governed layer

Your BI

TableauLookerMetabase

Dashboards on governed metrics

Your CI

GitHub

Draft pull requests, never merged by Dex

Scope
scope run 1841

DATA-410 · We need one way to measure net revenue

  1. Goal read· from the ticket
  2. Data and project explored· orders, refunds
  3. Open decision found· refund timing
Build
build run 1842

DATA-418 · Add net revenue metric

  1. Ticket received· refund rule settled
  2. Read the dbt project· 12 models · 3 sources
  3. Plan checked· refs and grain resolve
  4. Dev build passed· dev target only
Fix
fix run 1856

nightly check · against your accepted baseline

  1. Baseline accepted· 12 Aug
  2. Checked today· 4 axes
  3. schema· stripe_id dropped from raw.users
  4. grain· orders_daily no longer unique on (day, store_id)

Data work never arrives in one neat queue.

Some of it starts as a question nobody has scoped. Some sits in the backlog as a ticket. Some shows up as a broken model on Monday morning.

Queue 1no ticket yet

Questions nobody has scoped

Someone has to dig through the data before anyone can write the ticket.

  • How should we measure net revenue?
  • Can our data support a churn metric?
  • What would it take to track repeat purchases?
Queue 2arrives on their schedule

Tickets in the backlog

Each one waits for whoever knows that corner of the project.

  • DATA-418 Add net revenue metric 3d
  • DATA-402 fct_orders duplicated after backfill 6d
  • DATA-397 Align churn definition with finance 11d
Queue 3arrives without warning

Drift under your models

Usually found by whoever trusted the number.

  • schema stripe_id dropped from raw.users
  • grain orders_daily lost its unique key
  • semantic net_revenue no longer matches finance

Dex Enterprise works all three queues.

Every workflow runs open-source Dex, the same Apache 2.0 engine your engineers can install today. You can read it before you buy anything.

Dex Enterprise is the harness around it, deployed on your infrastructure: goals and tickets in, reports and draft pull requests out, drift checked on a schedule.

data-eng-bench hands the agent a ticket against a 2,356-model dbt project and checks whether the task's own tests pass afterwards. That is Build's job, scored by somebody who doesn't sell it.

Measured on somebody else's benchmark

80%
on ADE-bench with Claude Sonnet 5.5
57.3%
top published Sonnet 5 result at k=1 on Snowflake’s 103-task data-eng-bench
See the benchmarks

Scope. Build. Fix.

Three workflows, one for each kind of work. Run them in order, or start with the one you need.

1Scope · trigger: a goal

Figure out what the work is.

Describe what you want to measure. Dex explores your data and dbt project and posts a scoping report to the ticket: the data that exists, the decisions still open, the risks, and draft requests for the work. Your project stays untouched, and no data values end up in the report.

Scoping report · DATA-410
Decision for your team
Should refunds reduce revenue on the order date or the refund date?
What exists
fct_orders: one row per order. stg_refunds: one row per refund, joins to orders on order_id.
Risk
An order can have several refunds. Roll them up per order before joining, or revenue counts twice.
Draft requests
Roll refunds up to one row per order, with tests on the join. Define net revenue once the timing rule is set.

Observed 12 Aug · commit a7c91e2 · not explored: subscription revenue

Send a draft request to Build once the decision is made.

2Build · trigger: a ticket

Turn a ticket into a pull request.

Send Dex a ticket, or a draft request from Scope. It reads the project as it is right now, writes the change, builds it on your dev target, and opens a draft pull request linked to the ticket. If a business definition is missing, it asks on the ticket instead of guessing.

Draft · Add net_revenue to fct_ordersDraft

acme-analytics · dex/data-418-net-revenue

File+−
models/marts/fct_orders.sql+18−2
models/marts/schema.yml+24−0
models/semantic/revenue.yml+11−3
Read this run
12 models · 3 sources
Plan checked
every ref and grain resolves
Dev build
passed on the dev target
Ticket
DATA-418

Review required · Dex can't approve or merge

3Fix · trigger: a schedule

Fix drift before it reaches a dashboard.

Sources change under you. On a schedule, Dex checks your data against the baseline your team accepted, across schema, volume, grain, and semantics. Mechanical fixes arrive as draft pull requests. Anything that needs judgment becomes a ticket that names the decision. The baseline only moves when a person approves it.

Nightly drift check · 4 axes2 findings · 1 draft fix · 1 ticket

Against the baseline accepted 12 Aug

AxisFindingOutcome
schemastripe_id dropped from raw.usersdraft fix · 3 models
grainorders_daily lost (day, store_id)ticket · needs a decision
volumeno change—
semanticno change—

Findings you already know about aren't filed again.

Review it like any other pull request.

Dex Enterprise drafts the change. Your reviewers and branch rules decide what merges, same as for anyone on the team.

1

It reads before it writes

Every run starts from your project and data as they are right now, not from an old report. If the ticket leaves a business definition open, Dex asks. If a column or join it needs isn't there, it stops instead of making one up.

2

It builds before you see it

Every change is built on your dev target first, never in production. If the build still fails after one repair attempt, no pull request opens. You get a comment on the ticket saying why.

3

It stays inside your models

Dex writes analytics code: model SQL, tests, docs, and semantic definitions, in the paths your project already uses. Anything else gets flagged for a person or left alone.

4

It doesn't spam you

Drift findings are grouped, capped, and deduplicated. Close a fix without merging it and the same finding stays quiet instead of coming back the next night.

What Dex can change

Writes

Proposed in a draft pull request.

  • · Model SQL
  • · Tests and docs
  • · Semantic definitions

Flags for a person

Named on the ticket, never changed on its own.

  • · Definition decisions
  • · Project config
  • · Package dependencies

Never touches

Stays with your team.

  • · Branch and merge rules
  • · CI workflows
  • · Access and secrets

Deployed on your infrastructure. Your data stays with you.

The harness is deployed on infrastructure your team already governs and runs in your own CI, under identities and keys you own. Exmergo never receives your data and has no service in the run path.

Your environment
  1. Goal, ticket, or schedule
  2. Dex harness, on your infrastructure
  3. Report, draft PR, or ticket
  4. Your reviewers
Your identity
Dex runs as an app you register, with only the permissions you grant it.
Your data
It reads your sources and writes only to a dev schema you choose.
Your branch rules
Branch protection applies to Dex like anyone else. It can't approve or merge.
Your model provider
Your API key and account, so your region and retention settings apply.
Your secrets
Credentials stay in your CI's secret store. The model never sees them.
Your records
Every run leaves a record, and it stays in your environment.
  • Exmergo never receives your data.
  • No Exmergo service sits in the run path.

What we don't claim: that every change is right, that every secret gets caught, or that a required review makes a diff safe to merge. Review is a control, not a proof.

Frequently asked questions

Q01What is Dex Enterprise?

Dex Enterprise is a harness that runs open-source Dex for a whole data team, deployed on your infrastructure. It has three workflows: Scope turns an analytics goal into a scoping report, Build turns a ticket into a draft pull request with the dbt change, and Fix checks for drift on a schedule. It runs in your CI, and nothing merges without your team’s review.

Q02How is Dex Enterprise different from open-source Dex?

Open-source Dex gives one analytics engineer the Explore, Transform, Maintain loop on demand, inside their coding agent. Dex Enterprise is the harness that runs the same engine for the team, deployed on your infrastructure: it picks up goals and tickets, opens draft pull requests, and checks for drift on a schedule, all in your CI. The engine that reads your data and writes the dbt change is the same in both.

Q03What do Scope, Build, and Fix do?

Scope takes an analytics goal, explores your data and dbt project, and posts a scoping report to the ticket: the data that exists, the decisions still open, the risks, and draft requests for the work. It never changes your project and never puts data values in the report. Build takes a ticket, writes the dbt change, builds it on your dev target, and opens a draft pull request. Fix compares your data with the baseline your team accepted, on a schedule, and turns each finding into a draft fix or a ticket that names the decision.

Q04Do I have to start with Scope?

No. Scope is for when you know the goal but not the work yet. If a ticket is already clear, send it straight to Build. Fix runs on its own schedule against any project with an accepted baseline. Scope never opens tickets or starts work by itself: a person reads the report and decides what goes to Build.

Q05What can Dex Enterprise change in my repository?

Model SQL, tests, docs, and semantic definitions, always as a draft pull request. Project config and package dependencies get flagged on the ticket for a person to decide. Branch and merge rules, CI workflows, and access settings are off limits. Scope changes nothing at all.

Q06Can Dex Enterprise merge changes on its own?

No. It opens draft pull requests and stops there. Branch protection applies to Dex like anyone else, and it can’t approve or merge. Your reviewers decide what becomes part of the project.

Q07How does Dex Enterprise avoid flooding my team with pull requests and alerts?

Drift findings are grouped into one check, capped, and deduplicated, so a recurring problem doesn’t become a recurring alert. If you close a fix without merging it, the same finding stays quiet instead of coming back the next night. The baseline only moves when a person approves it, so a scheduled run never quietly redefines what good looks like.

Q08Where does Dex Enterprise run, and does Exmergo see our data?

The harness is deployed on your infrastructure and runs in your CI, as an app you register, with your own data credentials and model provider account. Exmergo never receives your data, and no Exmergo service sits in the run path. Because the model is reached through your provider account, your region and retention settings apply, and your credentials stay in your secret store where the model can’t see them. Every run leaves a record that stays in your environment.

Q09How are query and model costs controlled?

Each run has a spending limit, and queries are estimated before they run, using the same cost guard as open-source Dex. If Scope hits its limit, it reports what it found and names what it didn’t get to. Your own data platform limits and billing controls still apply.

Q10What happens when a reviewer wants changes?

Treat it like any other pull request. Edit it yourself, or update the ticket and resubmit it, and Dex starts a fresh run from the current state of the project.

Q11What does Dex Enterprise work with?

A dbt project in Git, the data platform that project already targets (a data warehouse, a lakehouse, or a database), and the CI you already run. It uses the same connectors as open-source Dex. We work with design partners to fit it into the tools their teams already use.

Q12Is Dex Enterprise available today?

Not yet. Dex Enterprise is in development with a small group of design partners. If your team runs dbt in production, you can apply to be one.

Design partners

Become a Dex Enterprise design partner

We're building Dex Enterprise with a small group of data teams who run dbt in production. If your team is buried in tickets and drift, we'd like to hear how you work.

What we'll talk about

  • — The goals, tickets, and drift your team handles today
  • — How a change gets reviewed and merged in your repo
  • — Where you'd want Dex to stop and ask

Who it's a fit for

  • — A dbt project in Git, with review required to merge
  • — A data platform and CI your team already runs
  • — Someone who owns what your metrics mean
Apply as a design partnerNot ready? Start with open-source Dex