Version Control Your Business Rules with Git and CI/CD

Most organizations have figured out how to version control their code. Source files live in Git, changes go through pull requests, and deployments run through a CI/CD pipeline. Engineers know exactly who changed what, when, and why — and if something breaks, rolling back is a single command.

Business logic in BI tools does not work this way.

Metric definitions, calculation rules, filter conventions, and semantic glossaries typically live inside SaaS platforms with no history, no review process, and no structured way to roll back. Someone updates how "active user" is calculated, and by the time anyone notices the charts shifted, there is no record of what changed or who approved it. These are not just analytics problems. They are governance problems.

MetricChat takes a different approach. Instructions — the rules that tell the AI agent how your business defines its data — are plain text files. They live on disk. And that means you can put them in Git.

The Problem with Business Logic Trapped in Tools

When business rules live only inside a SaaS interface, several things become impossible:

There is no history. If the definition of "churned customer" changes in October, there is no way to see what it was in September or who made the change. Audits require hunting through Slack messages or asking whoever was on the data team at the time.

There is no review process. Any analyst with access can modify a core metric definition. There is no pull request, no comment thread, no approval gate. A well-intentioned edit can silently break downstream reports.

Rollback is painful or impossible. When a bad change makes it to production, restoring the previous state often means manually reconstructing what the rules used to say.

Collaboration is friction. Engineers and data teams work in fundamentally different environments. Analysts work inside BI tools; engineers work in terminals and code editors. Without a shared medium, cross-functional review of business logic is awkward at best.

Instructions as Files

MetricChat instructions are Markdown files with YAML frontmatter. A simple one looks like this:

---
alwaysApply: true
references: ["revenue", "orders"]
status: approved
category: code_gen
---

# Revenue Definition

Revenue is calculated as `order_total - discounts - returns`.
Do not include tax in revenue figures unless the user explicitly asks for a tax-inclusive number.
Refunded orders should be excluded from all revenue calculations.

Because instructions are files, they can be committed to a repository alongside everything else your team already version controls. Your dbt models, your data catalog, your transformation logic — and now the semantic layer that sits on top of all of it.

Repository Structure

A typical MetricChat instructions repository might look like this:

metricchat-instructions/
  README.md
  instructions/
    core/
      revenue.md
      users.md
      churn.md
    sql/
      query-conventions.md
      join-patterns.md
    visualization/
      chart-defaults.md
      dashboard-layout.md
  .github/
    workflows/
      metricchat-ci.yml

You can organize instructions however your team finds natural. Group them by domain, by category, by the team that owns them. The structure does not matter to MetricChat — it reads all Markdown files in the configured directory.

The Pull Request Workflow

With instructions in Git, every change goes through code review. This is the same process engineers use for software changes, and it applies equally well to business rules.

A data analyst drafts a change to the churn definition. They open a pull request. MetricChat's CI job syncs the branch and runs the configured evaluation suite against it — testing that the AI agent answers benchmark questions correctly with the new instructions in place. Results post as a comment on the PR. The analytics lead and a product manager review the diff, leave comments, and approve when satisfied. The branch merges to main, and the deployment job publishes the new instruction set to production.

The entire history of that decision — the discussion, the rationale, the approval, the test results — lives in the pull request forever.

GitHub Actions Workflow

Here is a complete GitHub Actions workflow that implements this pipeline:

name: MetricChat CI/CD

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  sync-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Sync branch to MetricChat
        run: |
          curl -X POST "${{ vars.METRICCHAT_URL }}/api/git/${{ secrets.REPO_ID }}/sync" \
            -H "Authorization: Bearer ${{ secrets.MC_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{"branch": "${{ github.head_ref || github.ref_name }}"}'

      - name: Run evaluation suite
        if: github.event_name == 'pull_request'
        run: |
          curl -X POST "${{ vars.METRICCHAT_URL }}/api/tests/runs/batch" \
            -H "Authorization: Bearer ${{ secrets.MC_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{"suite_id": "${{ secrets.SUITE_ID }}"}'

      - name: Publish to production
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: |
          curl -X POST "${{ vars.METRICCHAT_URL }}/api/builds/${{ secrets.BUILD_ID }}/publish" \
            -H "Authorization: Bearer ${{ secrets.MC_API_KEY }}"

Add the following to your repository's GitHub secrets and variables:

Environment-Specific Instructions

Most teams maintain at least two environments — staging and production. With Git-based instructions, this maps naturally onto branches.

The main branch contains your production instructions. A staging branch (or a develop branch, depending on your workflow) contains instructions that are actively being tested. MetricChat can sync from any branch, so your staging MetricChat workspace reads from staging, and your production workspace reads from main.

main          → production MetricChat workspace
staging       → staging MetricChat workspace
feature/*     → PR previews, CI evaluation runs

This means you can test a new revenue definition in staging, validate it against real data patterns, and promote it to production with confidence — using the same branching strategy your engineering team already knows.

Rolling Back

When something goes wrong in production, reverting is a standard Git operation:

git revert <commit-hash>
git push origin main

The CI/CD pipeline picks up the push to main, syncs the reverted instructions to MetricChat, and publishes the build. Within minutes, the agent is back to the previous state — and there is a complete audit trail showing the revert, why it happened, and who triggered it.

Bridging the Gap Between Data Teams and Engineering

There is a cultural dimension to this approach that matters as much as the technical one.

Data teams often operate outside the engineering workflow. Analysts are not typically committing code, writing tests, or opening pull requests. That distance means the governance practices that engineering has refined over decades — peer review, automated testing, audit trails, staged deployments — rarely make it to the analytics layer.

Putting MetricChat instructions in Git is a low-friction way to close that gap. Analysts do not need to become engineers. But they do get access to the same tools: a reviewable history of every decision, a comment thread where business stakeholders can weigh in, and automated tests that catch regressions before they reach users.

The pull request becomes a shared space where an analyst, a product manager, and an engineer can all look at a proposed change to how "monthly active users" is defined — and have a structured conversation about whether it is correct.

What This Looks Like in Practice

Once the pipeline is in place, the workflow for changing a business rule becomes:

1. Create a feature branch and edit the relevant instruction file
2. Open a pull request — MetricChat syncs the branch and runs evals automatically
3. Reviewers see the diff, read the test results, and leave comments
4. Merge when approved — production updates within seconds

No tickets to file. No manual deployments. No wondering what the definition used to be. The entire lifecycle of every business rule is visible, reviewable, and auditable.

Takeaway

Business logic deserves the same discipline as application code. MetricChat instructions are plain text files precisely because that opens the door to every tool and practice that software engineering has built around plain text: Git, pull requests, code review, CI/CD, and automated testing.

If your team already has a Git workflow, you already have everything you need to bring that discipline to your analytics layer.