Git-Backed Modeling

Git-backed modeling lets analysts, domain experts, engineers, and AI agents work on the same data model, with a record of every change and an optional review before it goes live. It is turned on per environment. Without it, a modeler builds and publishes straight from the app, which is usually enough for one person or a small team.

An analyst asks for a change in plain language, the agent makes it in a draft, a reviewer your team chooses — or the author — approves it, and the new version is published to every dashboard, agent, and data app that uses the model.

How a Team Works on One Model

Business rules live in the model rather than in pipeline code (see What Goes in the Model), so each group can work on it directly:

• 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; we recommend a dedicated modeling repository rather than your monorepo, for isolation.

For Engineers: How It Works

Under the hood this is ordinary git. 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