Keeping a data model as code, under version control, is the right way to build one. Every definition is written down, every change is reviewed before it goes live, and every old version is there to compare against or go back to. Engineers settled this years ago, and the best data teams followed.
It also left most of the business behind, on two fronts. First the code: to change what net revenue means, you had to write it in a modeling language. Then the tools that version the code: branches, commits, pull requests, and merges. The people who know what the numbers should mean ended up filing a ticket and waiting for someone who spoke both.
Coding agents closed the first of those gaps. An agent writes the data model from a description in plain language, and we open-sourced the skills that teach it how, so anyone can use one wherever they already work.
This post is about the second. The Credible app takes care of version control, and the person who asked for the change never has to learn to code -- and better yet, Git. Business and technical people collaborate on the same data model in the tools they each prefer, a conversation in the app for one and a branch in their own editor for the other, and ship it together to the agents and apps that run on it.
Here's what that looks like in the real world. A CFO notices that net revenue in the board deck doesn't match the books. Today, the CFO emails the data team, the request waits in a queue, and someone patches the deck by hand. The definition behind the number often stays wrong, so next quarter it comes back, in a different deck, from a different agent.
With Credible, the CFO asks an agent why the numbers don't match. The agent finds the problem in the data model: the definition the deck uses doesn't subtract returns, and the one finance closes the quarter on does. The CFO confirms it's wrong, tells the agent to fix the data model, and updates the deck. In the background, the agent sends the edit to Git as a pull request. The data team reviews and approves it on their own schedule, and every person and agent gets the right definition from then on. Nobody waits on it, and nobody needs a technical background to make the fix.
A chat fixes the definition, the data team reviews the pull request, merge reaches everyone.
What happens underneath
On the CFO's side, the agent works in a draft that belongs to the CFO, so nothing anyone else sees changes until the fix is approved. As it edits, it compiles the data model against the live schema, so a renamed column or a broken definition shows up in the chat, not in the board meeting. Every step is recorded under the CFO's name. The CFO never opens GitHub, and never sees a branch or a commit.
On the data team's side, the pull request shows what changed, who asked for it, and whether it compiled. The compile result sits beside it, so a failing change can't be approved by accident. Your team decides who reviews: a data engineer on every change, or the owner of the finance model. Once it merges, the corrected definition reaches every agent, app, and dashboard built on the data model.
Every published version records the change that produced it and the person the agent was working for, and history is never rewritten. A quarter later, when the auditor asks why net revenue changed in October, the answer is in the history: what changed, who asked for it, and when.
Everything ships together
The data model doesn't travel alone. A package holds the model, its access rules, and the dashboards, notebooks, and data apps built on it, and every version is published as one unit that can't change afterward. So if the fix also touches a dashboard tile or a data app, it ships in the same review as the definition behind it. The rules about who can see finance numbers ride along too, reviewed and published with the model they protect.
That also makes a bad change cheap to undo. If the fix turns out to be wrong, re-pin the previous version as latest. Nothing rebuilds, every agent and app follows the pin, and the model, apps, and rules roll back together. The history shows what was replaced and who changed it.
At agent scale
An agent changes a data model in minutes, and more people can ask for changes, so many can be in flight at once. Version control is what lets all of them land on one data model and leave it right at the end of the day.
The CFO's fix doesn't stop anyone else's work. An analyst may have a draft open that builds a margin report on net revenue. The agent keeps each open draft current with the shared data model, so the report picks up the corrected definition before anyone sees its numbers. When two changes overlap, the agent reads both versions and the one they started from, reconciles them, and says in the chat what it did. Nobody is sent to GitHub to untangle a conflict by hand.
For the data team: it's just Git
If you keep your data model in Git already, none of this will surprise you. A draft is a branch cut from your base branch. Each agent turn is a commit attributed to the person the agent was working for. The compile result posts on the head commit as a check. Merging to the base branch publishes, and the published version records the commit it came from. Once a package has published this way, direct uploads to it are refused, so a reviewed version is never replaced by one nobody looked at.
You can pull the CFO's draft branch down, edit it in your own editor, and push it back, or open a pull request of your own. Whatever merges publishes the same way. If you bring your own repository, protect the base branch and require the Credible / draft compiles check, and nothing publishes without review. Or let Credible host the repository in its managed GitHub organization, so nobody on your team needs a GitHub account. Git-backed modeling is turned on per environment; the docs cover setup.
The mechanism is the one engineers already use. The difference is that the CFO goes through the same path, and never has to learn a coding language or version control jargon. Agents made the data model easy to write. Version control keeps it right as it changes, and now everyone who knows what the numbers should mean can use it.
