Git-Backed Modeling

Git-backed modeling is a way of working for larger organizations, where analysts, domain experts, engineers, and AI agents across several functions all work on the same data model. It is turned on per environment. Out of the box, a modeler builds and publishes straight from the app, and for one person or a small team that is usually all you need.

The case for it starts when a model has many hands on it. Metrics get redefined, new tables arrive, an edge case turns out to matter, and the people who notice first are rarely the engineers who maintain the model. When every change has to be handed to one team and wait its turn, the model falls behind, and people start working around it. When anyone can change it with no record, nobody trusts it.

Git-backed modeling lets the whole team change the model directly, wth a record of every change and a chance to review it before it goes live. An analyst asks for a new metric in plain language. The agent makes the change in a draft. Whoever your team has chosen looks it over, or the author approves it themselves, and the update is published to every dashboard, agent, and data app that uses the model. Every published version shows who changed what and when.

How a Team Works on One Model

Each group does the part it is good at, and the model stays one governed thing.

• Engineers own the model and decide how changes get in. When the team wants a review step, every proposed change comes to them as something they can read line by line, already checked for errors, with the name of the person who asked for it.
• Analysts and domain experts ask for what should change, in plain language: a new metric, a corrected definition, a business rule the data alone cannot settle. The agent makes the change in a draft, and it goes through the same path as any other. No Malloy coding experience required to contribute.
• AI agents notice what people actually ask for and suggest improvements, such as a clearer description on a field or a view worth adding, as proposals for a person to approve rather than changes that land on their own.

What You Get

• Every change is a proposal. Work happens in a draft that belongs to the person who opened it. The draft has an author, a description of what it changes, and a record of every edit the agent made along the way. Nothing in it touches the published model until it is approved.
• You decide who approves. Approving a proposal is what publishes the new version, and your team decides who may approve. Require an engineer's sign-off on every change, or let the person who owns a model approve their own. Either way there is no side door: the published model only changes through an approved proposal, so what your dashboards and agents serve is always something a person signed off on.
• Changes are checked before they can land. The agent checks the model as it works, so a change that would break it is caught while it is being written. Reviewers see the result beside the proposal, and a failing change cannot be approved by accident.
• A complete history. Every published version records the proposal that produced it, who asked for it, and when. When a number on a dashboard changes, you can trace it to the change and the person behind it.
• Two people can change the same model without coordinating. The agent keeps each draft up to date with the shared model as it goes. Most of the time the other person's work does not touch what you touched, and it is absorbed without anyone being asked anything. When it does overlap, the agent reads your version, theirs, and the version you both started from, reconciles them in the chat, and tells you what it did. Nobody is sent to GitHub to untangle a conflict by hand, and if a change breaks the model the agent fixes that in the same conversation.
• Engineers work where they already work. Every proposal is also a pull request in GitHub, so engineers review, comment, and approve with the tools they already use. They can pull a draft branch down, edit it in their own editor, and push it back, or start a branch of their own and open their own pull request. Whatever merges to the base branch publishes the same way. Nobody else has to open GitHub.

Hosted by Credible, or Your Own Repository

The repository is your choice. Credible can host one for you in its managed GitHub organization, so nobody on your team needs a GitHub account and your side of the setup is one toggle. Or bring your own repository and keep models next to the rest of your code. However, we do advise using a dedicated modeling repository, not your monorepo, to keep good isolation.

Why It Is Different

Most analytics tools that connect to git make it an engineering project before anyone can start: accounts to create, permissions to grant, a repository to set up. Credible makes that a choice rather than a prerequisite. Take the hosted repository and setup is one toggle, or bring your own and get the same way of working on it.

Two things matter more. First, review is a real gate, not a permission. In most tools the only control is who may press publish, which answers "who may ship" but never "should this ship." Here a team can require a person's sign-off on every change, and a team that does not still gets the record and the checks. Second, the people asking for changes never touch the mechanics. The agent writes the code, keeps drafts current, resolves collisions, and fixes errors, so a domain expert improves a governed, versioned model with nothing but a sentence.

For Engineers: How It Works

Under the hood this is ordinary git, and that is the point. Once an environment is enrolled, every new draft package is backed by a git repository rather than by Credible's document store:

1. A draft is a branch. Asking the agent to build or edit a package cuts a branch from the repository's base branch (usually main). The package is a top-level directory in the repository; one repository serves the whole environment.
2. Every turn is a commit. As the agent edits, each turn lands as a commit attributed to the modeler, so the history reads like a conversation: what changed, who asked for it, when.
3. Compile on every edit. The agent compiles as it goes against your live connections, so a draft that will not publish is caught while it is being written, not at merge time.
4. A pull request carries the change. When the draft is ready, Create pull request opens a PR whose title names what changed. The compile verdict is posted onto its head commit as a check, and the draft panel mirrors the PR's state.
5. Merge is the publish. When a pull request merges to the base branch, the package publishes from that merge commit, and the new version records the commit it came from. It does not matter whether the app raised the pull request or an engineer did. For a git-backed package, this is the only way a version gets made.

The loop repeats. After a merge the draft re-cuts from the new base tip, ready for the next change. Fall behind main and Update from main absorbs the base branch, showing what it brought in. A direct upload over a git-backed package is refused, so a version can never exist without the commit that produced it.

What to Know Before Enrolling

• One repository per environment. Each package is a top-level directory in it. You do not choose or create repositories per package.
• Text files only. A package containing a binary file, or a file larger than about 1 MB, is refused up front with the files named. Keep large data in embedded data or your warehouse.
• A git-backed package publishes only through a proposal. Once a package has published from a merged proposal, cred publish and CI uploads to it are refused, so a reviewed version is never replaced by one nobody looked at. In environments that are not enrolled, nothing changes.
• Attribution is permanent. Each change records the name and email of the person the agent was working for, and history is not rewritten afterwards.

Set It Up

Start by telling your account team or support which environment you want on git-backed modeling and whose repository it will use. What happens next depends on the answer.

Credible-hosted. Nothing to do until we write back. We create a private repository for the environment in Credible's managed GitHub organization, install our GitHub App on it, and send you the details to enter.

Your own repository. Four steps.

Either way, you finish in the Credible App. Once we have confirmed, open Manage environment, turn on Git-backed modeling, enter the owner, repository name, and base branch, and save. From then on every new draft in that environment is a proposal. Drafts that already exist keep working the way they were created.

If you brought your own repository, you can require review before anything publishes: protect the base branch and require the Credible / draft compiles check. That is a setting on your repository, not ours.

Next Steps