Build a Digital Twin of Your SaaS Business
A digital twin is a governed model of the metrics your company has agreed on, each with an approved definition, a declared owner and its links to the others. AI agents read it to answer questions that currently take days of analyst time and three Slack threads to resolve.
The Cost of Flying Blind
- "Which cohort is driving the NRR decline?" An analyst pulls data manually, cross-references CRM and billing, builds a one-off notebook. Answer arrives in 3 to 5 days.
- New analyst joins Spends months building tribal knowledge about which tables matter and how metrics connect.
- Board prep Finance reports Net Revenue Retention (NRR) from one query and CS reports it from another, so the board sees two numbers and someone has to explain the gap.
- Source system migration Moving from Chargebee to Stripe breaks every dashboard and every query. Months of rework.
- Same question An agent traces the relationship graph from Feature Adoption Rate through Customer Health Score and Churned MRR to NRR, then to the exact warehouse tables. SQL generated in seconds.
- New analyst Explores the graph, sees how every metric connects, finds the adapter mapping to know exactly which table.column computes what.
- Board prep Finance and CS run the same canonical definition through the same SQL and bring the same number.
- Source migration Remap the affected fields in the adapter. Definitions stay the same. Dashboards keep working.
Three Layers, Zero Migration
The twin stacks on top of your existing infrastructure. Your warehouse, your dbt models and your BI dashboards all stay exactly as they are, until you're ready to update them or make new ones. The hardest part is the human work: agreeing on which metrics matter, who owns each definition and how they connect. GASP supplies the starting definitions, the relationship graph and the tools. Your team edits them into a model of your own business.
AI Agents
Read-only access to the twinMCP tools and custom integrations. Agents read the graph and your adapter to answer questions, generate SQL and trace relationships. They query the twin, which points them at the right warehouse columns. With protocols like A2A and OSSA (an open standard for AI agent manifests) a coordinator agent can spin up specialists on demand.
Your Adapter
Maps GASP fields to your warehouseA JSON mapping file. It names the warehouse table behind each GASP dataset and the column for each GASP field. Each metric can declare the team that owns its definition and each field mapping can name the team that owns its pipeline. This is the only file you write.
GASP Standard
313 definitions, formulas, relationshipsThe knowledge graph (69 metrics, 28 business entities, 7 concepts, 210 relationships), the ontology (280 canonical fields, 22 source categories) and 286 parameterised SQL templates compiled from the canonical formulas in four dialects (Postgres, Snowflake, BigQuery and Databricks). All of it ships with the MCP server, so your team starts from a full scaffold. The same model is published as Apache Ossie files for semantic-layer tools.
Your Warehouse
UnchangedSnowflake, BigQuery, Postgres, Redshift or Databricks. Your existing pipelines keep running. The twin generates SQL; you or your pipeline review it and run it against the warehouse.
Why It Matters
Metric Accountability
Your adapter names the team responsible for how each metric you track is calculated, and each field mapping can name the team that runs its pipeline. When NRR looks wrong you know exactly who to ask and exactly which table.column to inspect.
Source System Independence
When you migrate from Chargebee to Stripe or from Salesforce to HubSpot, you remap the affected fields in the adapter and every metric definition and agent workflow carries on against the new data. The switch is a remap of one file rather than a rewrite of every query.
Curated by Humans, Used by Agents
The twin is built from a one-time human curation of which metrics to track, how they connect and who owns them. Agents read this curated model, so they work from the approved definitions and governed relationships and reach your warehouse only through the columns your adapter maps.
Agentic Operating Layer
Any number of agents can read from the twin in parallel. Spin up a retention agent for a board meeting. Spin up a pipeline agent for a forecast call. Tear them down when the meeting ends. With protocols like A2A and OSSA a coordinator can discover and orchestrate specialist agents on demand.
See multi-agent patternsWhat You Can Ask
Each question below is hard to answer today because the data sits in several systems and the context sits with several teams. With a digital twin an AI agent answers it in seconds.
"Which customer cohort is driving the NRR decline and what did their product usage look like in the 6 months before they churned?"
Agent calls infer_drivers("nrr", "down") to rank upstream candidates, then explain_path("feature_adoption", "nrr") to walk forward from Feature Adoption Rate, with edge classifications. One of the chains it returns is Feature Adoption Rate → Customer Health Score → Logo Churn Rate → Churned MRR → NRR. It then generates cohort SQL from the adapter, cross-references product analytics data and returns a segmented analysis.
"Our CAC Payback went from 14 to 19 months this quarter. Break down exactly what changed."
Agent calls get_formula("cac_payback") to decompose CAC Payback = CAC / (ARPA × Gross Margin). It then generates SQL for each component from the adapter via generate_query, compares the two quarters and names the component that moved.
"We are switching from Chargebee to Stripe next quarter. Which metrics and data pipelines are affected?"
The agent reads the adapter template, where each field names its source system, finds every Billing field and lists the 119 metrics that depend on them, along with the field owners responsible for remapping.
"Show me every metric that goes into our board deck and flag any that are calculated differently than the GASP Standard. What other metrics should we be tracking?"
Agent calls lookup_metric on each board metric and compares the canonical formula against the SQL the board deck runs. Flags deviations and names the owner declared in your adapter. Then coverage_gap(board_metrics) surfaces direct upstream and downstream metrics not on the deck.
"If our three largest accounts by ARR churned tomorrow what would our NRR, GRR and Rule of 40 look like?"
Counterfactual "what if" simulation runs in the TWIN Modifier rather than the MCP server. Enter your baseline, move a lever such as Churned MRR and watch the change propagate through the core metrics in real time.
How to Build It
Install the GASP MCP server
One command installs 23 tools covering all 313 metrics.
claude mcp add gasp-standard -- npx -y gasp-standard-mcpDownload the adapter template
A slot for every GASP dataset and 418 mapping slots, one per field per dataset it lives on, each with its source system and the metrics that use it.
Download templateMap your warehouse
Name the warehouse table behind each dataset and the column for each field your warehouse provides. Start with Billing fields, which feed the revenue and retention metrics.
Assign metric owners
Declare which team owns each metric definition. The field is optional, though we recommend it. See the adapter guide for the format.
Validate
Run validate_adapter to see your coverage.
Fully covered metrics get SQL generation. Partial coverage shows exactly which fields to add next.
Query
Ask your AI assistant questions like the ones above. The agent uses the relationship graph to trace dependencies, the adapter to find the right columns and the query generator to produce SQL in your warehouse's dialect.
Architecture
How the pieces connect, for data engineers who want to see the whole stack.
Optional: Deploy the Knowledge Graph
The MCP server works standalone. For teams that want to explore the graph visually or run custom Cypher queries you can deploy to Neo4j:
cat gasp-knowledge-graph.cypher | cypher-shell -u neo4j -p passwordThe Cypher file includes 69 metric nodes, 28 entity nodes, 7 concept nodes, 54 dataset nodes, 280 field nodes and 22 source category nodes with full relationship edges and indexes. See the full schema.
Downloads and Quick Start
The standard is also published as Apache Ossie (incubating) files: the ontology, a reference semantic model and the mapping, validated against the upstream Apache Ossie validator in CI. More on the Ossie export.
Related pages:
Govern the Agents
The twin defines what your agents measure. GASP AICF covers how the agents themselves are governed, with 201 canonical controls mapped across SOC 2, ISO 27001, NIST AI RMF, the EU AI Act, ISO 42001 and 7 other frameworks, each with evidence requirements, assurance tiers and a full question bank.
An AI control library scoped by named profiles. Pick the profile that matches you (from SaaS AI provider to EU high-risk provider) and get the applicable controls, evidence checklist and question bank. Read-only from Claude Code or Claude Desktop via MCP.
- Controls
- 201
- Frameworks
- 12
- Profiles
- 9
- Mappings
- 2,989
Frequently Asked Questions
Does this require changes to our existing infrastructure?
No. The twin layers on top of what you already have. Your warehouse, pipelines and dashboards stay exactly as they are. The adapter is a JSON file that describes your existing schema. Installing the MCP server is a single command.
What is the real effort involved?
The technical setup is fast. Installing the MCP server takes one command. Mapping warehouse fields to the adapter template takes a data engineer an afternoon if your dbt project is well structured.
Most of the effort is organisational: getting Finance, Sales and CS to agree on which metrics matter, how each one is calculated and who owns the definition. Teams tend to put this conversation off because it surfaces years of inconsistency. We think it is also the part that pays back most. GASP provides the starting vocabulary, so your team edits a draft instead of writing definitions from scratch. The curation happens once. After that the twin is the reference agents, analysts and executives share, with each metric owner keeping their definitions current.
Do agents write to our warehouse or source systems?
No. Agents read from the twin, which is a read-only semantic layer. They generate SQL that a person or a CI pipeline reviews before it runs against the warehouse. Your CRM and billing system see only the pipelines you already have.
Can multiple agents use the twin simultaneously?
Yes. Any number of agents can read the shared model in parallel: one running retention analysis, another diagnosing pipeline, a third preparing the board pack. They work from the same canonical definitions and the same adapter mapping, so their numbers agree.
What if our definitions differ from the GASP Standard?
That is expected. Treat GASP as a starting point: your team reviews each definition. Where your business model needs a different calculation, it keeps the canonical formula, documents its variant beside it and uses the adapter's field transform and notes to record how your data differs. What matters is one agreed definition per metric, whether or not it matches GASP exactly. The standard gives you 313 definitions to react to rather than 313 blank pages to fill.
Who should own the curation process?
RevOps or Finance usually leads the initial curation because they sit where Sales, CS and Engineering data meet. The adapter records ownership: each metric has a declared owner team and each field can name a pipeline owner. After the first pass each team maintains the sections closest to its own data.
How does this relate to a semantic layer like dbt metrics or Cube?
The two work together. A semantic layer such as dbt metrics or Cube defines how to query your warehouse. The twin defines what those queries mean in business terms: which metrics connect, who owns them and what the canonical formula should be. If you already have a dbt metrics layer the adapter mapping is quicker, because your field references are already well structured.