Analytics-as-Code
Analytics-as-code is Holistics' second structural foundation. Foundation #1 (the expressive semantic layer) is what lets AI and humans reason from real business definitions; analytics-as-code is what makes those definitions durable, evolvable, and useful inside modern engineering workflows.
For the full positioning argument, see Why Holistics.
What "analytics-as-code" means here
Every definition in Holistics is code, in a Git repository:
- Models, datasets, dashboards, relationships — written in AML, the typed declarative language
- Metrics — written in AQL, composable and reusable
- Permissions, user attributes, environments — also defined declaratively in code
You can edit through the GUI or write code directly in AML Studio. Both write to the same underlying code base. Two-way sync means data teams and analytics engineers don't have to choose one workflow over the other.
What treating analytics as code unlocks
Many BI tools offer "Git export" or YAML modeling as a developer-experience add-on. In Holistics, code is the substrate, which means several capabilities follow at once:
- Governance. Every definition has history, authorship, review, branches, environments, and rollback. The same engineering rigor that protects production code now protects business logic. (See below.)
- Composability and reuse. Many BI tools call themselves "analytics-as-code" but use YAML, which is schemaless, untyped, and forces Jinja-template workarounds for any reuse. AML is a typed language built for analytics: real types, real abstractions (modules, extends, partials, constants, string interpolation, conditionals), and real IDE tooling. See AML vs YAML for the full argument.
- Developer ergonomics. Type checking at compile time, autocomplete and go-to-definition in AML Studio, inspectable compiled SQL, and a CLI for local development against the editor of your choice.
- AI extensibility. AI agents can read, write, and edit structured code; that's far harder against opaque GUI configurations. Holistics AI generates AQL against the same code your team wrote, and external tools can drive the system through the MCP server or API.
- Automation. CI/CD validation, auto-publish on merge, programmatic deploys, and dynamic environments per branch.
Governance: durable, reviewable, traceable business logic
Governance is the most load-bearing benefit of analytics-as-code in a BI context, because business definitions drift faster than application code and the consequences of drift are silent. Code-as-substrate makes drift visible and reversible.
| Capability | What it enables |
|---|---|
| History & authorship | Every change has an author, a timestamp, and a diff. Disputes about "who changed the revenue definition?" are answered in seconds. |
| Pull request review | Wrong logic doesn't get merged silently. The same review discipline that protects production code now protects business definitions. |
| Branches | Experiment in isolation. Test a new metric definition on real data without affecting production users. |
| Environments | Develop in dev, validate in staging, deploy to prod through a real promotion workflow. |
| CI/CD validation | AML compiles. Type-check business logic before merge. Catch breaks before users do. |
| Inspectable compiled SQL | AQL compiles deterministically to SQL, and the output is visible. Trust in human-written and AI-written queries comes from being able to see exactly what runs. |
| Rollback | Reverting a problematic change is one Git operation, not a forensic exercise. |
The cumulative effect: the semantic layer gets stronger over time rather than drifting. Business logic improves through review. Metric definitions stay consistent across human and AI consumers. Embedded customer-facing analytics share the same governed substrate as internal dashboards.
How AI benefits from this
Holistics AI generates AQL, not raw SQL, against your governed semantic layer. That's only meaningful if the semantic layer is actually governed. Analytics-as-code is what makes "governed" real:
- AI reuses metric definitions you've reviewed and merged, not ad-hoc fragments
- AI's queries compile to inspectable SQL you can verify
- When you improve a metric definition through a PR, every AI answer that uses that metric improves with it instantly, without retraining
- Permission checks happen on the same code-defined access controls humans use
See Why Holistics AI is reliable for the mechanism in detail.
Where to go from here
The basics
- Version Control with Git — branches, history, rollback
- Quickstart — end-to-end: connect, model, develop, publish
- Code Deployment (Dev/Prod) — how dev and prod separation works
Code review
- Pull Request Workflow — the PR loop in Holistics
- GitHub PR Workflow — connect with GitHub
- GitLab MR Workflow — connect with GitLab
- Code Search — search across your analytics code base
CI/CD
- CI/CD Overview — automated validation and deployment
- Validation API — validate AML changes in your CI pipeline
- Auto-publish — automatic deployment after merge
Multi-environment
- Dynamic Data Sources — different warehouses per environment
- Dynamic Schemas — different schemas per environment
- Dynamic Environments — full env promotion patterns
Integrations
- dbt Integration — work alongside dbt for transformation
- Local Development — work in your editor with the Holistics CLI