Self-building analytics, owned by your team
Scope the question. Build the change. Catch the drift. Your team decides what ships. Runs in your CI, with tested dbt changes delivered as draft pull requests.
- Runs in your CI
- Opens a draft pull request
- Never merges it
We need one way to measure net revenue
Scoping report posted to DATA-410
Decision for your team
Should refunds reduce revenue on the order date or the refund date?
Draft requests
Roll refunds up to one row per order, then define net revenue once the timing rule is set.
You decide what goes to Build
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.
Questions nobody has scoped
Someone has to dig through the warehouse 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?
Tickets in the backlog
Each one waits for whoever knows that corner of the project.
Drift under your models
Usually found by whoever trusted the number.
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 connects it to your team: 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.
- 76%
- on ADE-benchwith Claude Sonnet 5
- 57.3%
- top published Sonnet 5 resultat k=1 on Snowflake’s 103-task data-eng-bench
Scope. Build. Fix.
Three workflows, one for each kind of work. Run them in order, or start with the one you need.
Figure out what the work is.
Describe what you want to measure. Dex explores your dbt project and warehouse 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 warehouse values end up in the report.
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.
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.
Add net_revenue to fct_orders
Run evidence
- Read this run
- 12 models · 3 sources
- Plan checked
- every ref and grain resolves
- Dev build
- passed on the dev target
- Ticket
- DATA-418
Fix drift before it reaches a dashboard.
Warehouses change under you. On a schedule, Dex checks the warehouse 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.
Against the baseline accepted 12 Aug
2 findings · 1 draft fix · 1 ticket
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.
It reads before it writes
Every run starts from your project and warehouse 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.
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.
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.
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
Runs in your CI. Your data stays with you.
Every run happens in CI your team already governs, under identities and keys you own. Exmergo never receives your data and has no service in the run path.
Your identity
Dex runs as an app you register, with only the permissions you grant it.
Your warehouse
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
- What is Dex Enterprise?
- Dex Enterprise runs open-source Dex for a whole data team. 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.
- How 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 runs the same engine for the team: 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 the warehouse and writes the dbt change is the same in both.
- What do Scope, Build, and Fix do?
- Scope takes an analytics goal, explores your dbt project and warehouse, 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 warehouse 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 the warehouse with the baseline your team accepted, on a schedule, and turns each finding into a draft fix or a ticket that names the decision.
- Do 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.
- What 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.
- Can 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.
- How 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.
- Where does Dex Enterprise run, and does Exmergo see our data?
- It runs in your CI, as an app you register, with your warehouse credentials and your own 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.
- How are warehouse 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 warehouse limits and billing controls still apply.
- What 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.
- What does Dex Enterprise work with?
- A dbt project in Git, the warehouse that project already targets, and the CI you already run. It uses the same warehouse connectors as open-source Dex. We work with design partners to fit it into the tools their teams already use.
- Is 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.
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 warehouse and CI your team already runs
- Someone who owns what your metrics mean