Nobody would accept a production database schema that any employee could change silently, with no history and no review. Somehow that is exactly how most companies manage their metric definitions.
The state of the art is a spreadsheet
Ask a data team where their metric definitions live and the honest answer is usually: partly in dbt, partly in a Confluence page that is eight months stale, partly in a Google Sheet the analytics lead maintains, and mostly in three people's heads.
None of these have change history worth the name. When a number moves and someone asks why, the investigation starts from zero.
What GitOps gives you here
OneClickBrain exports the entire knowledge layer as structured files. Definitions, scopes, permissions, integration configs — all of it, in YAML or JSON, in a repo you own.
Once it is a file, everything you already know how to do applies:
- Pull requests — a change to the churn formula gets reviewed by the finance owner before it ships
- Diffs — "what changed between Q2 and Q3 reporting" is a git log, not an archaeology project
- CI checks — validate that every verified metric has an owner, that no definition references a deprecated source, that scopes do not overlap in forbidden ways
- Rollback — revert a bad definition change the same way you revert bad code
- Environments — test knowledge changes in staging before agents in production see them
A CI check worth having
The single most useful check we have seen customers add is an ownership gate:
It refuses to merge a metric marked verified without a named human owner. That one rule does more for definition hygiene than any amount of documentation policy.
No lock-in, structurally. Because the export is complete and the format is plain, moving off OneClickBrain means keeping the repo. That is deliberate — a knowledge layer you cannot take with you is a liability, not an asset.
Where it fits with the dashboard
Not every change belongs in a pull request. Approving a proposed definition update is a two-click action in the UI, and that is the right interface for it. The repo is the source of truth for structural changes: new scopes, permission model shifts, integration configuration, anything a reviewer should see before it takes effect.
Both paths write to the same store. The distinction is about which changes deserve review, not about which tool you happen to prefer.
Mahari Kalau
Writes about context engineering, agent architecture, and the unglamorous parts of enterprise AI.