mbfinotti/revops-skillsCheck passed
SKILL DETAIL
revenue-data-governance-strategy
mbfinotti/revops-skills/revenue-data-governance-strategy
Set org-wide revenue data governance policy - which system is source of truth per object class (account, contact, opportunity, subscription, usage event, revenue metrics), how cross-team data contracts bind producers to consumers, where revenue metric definitions live, and who arbitrates disputes. Produces a per-object SOR/SOT designation table, an identity-resolution spine, a data-contract register, and a federated ownership model. Use whenever the user mentions source of truth, "two ARR numbers", GTM data contracts, revenue data governance, metric definition ownership, or "finance and sales report different numbers" - even if they never say "governance". Covers B2B, PLG/B2C, hybrid. Do NOT use for CRM field-level rules - use mbfinotti/revops-skills@crm-data-governance instead.
Installs · 163View source
Installation
npx skills add https://github.com/mbfinotti/revops-skills --skill revenue-data-governance-strategy
Skill files
SKILL.md
Last synced · Sep 15, 2026
evals/evals.json›
{
"skill_name": "revenue-data-governance-strategy",
"evals": [
{
"id": 1,
"prompt": "I run RevOps at Meridian Layer, a B2B SaaS company, 180 employees, about $24M ARR, seat-based annual contracts. Our stack is Salesforce, HubSpot for marketing automation, Chargebee for billing, Amplitude for product analytics, and Snowflake. Two weeks ago our CEO stood up at the all-hands and declared that Salesforce is our single source of truth and everyone should treat it as authoritative for customer data. Nothing has changed. Sales ops, the CS dashboard, and the finance pack all report a different active customer count, and each team can walk you through why theirs is correct. We have a quote on the table for a metrics layer product and the CFO wants to sign it this quarter so we stop arguing. Write me the governance policy that ends this.",
"expected_output": "A revenue data governance policy that replaces the per-system truth declaration with a per-object-class designation table separating authoring system from read-side truth, each row with a named owner, sequenced ahead of any tool purchase, and validated against the QBR test.",
"files": [],
"expectations": [
"Rejects the per-system declaration that Salesforce is the single source of truth, and states that truth must be designated per object class rather than per system",
"Defines system of record as the operational store that authors a record on the write path, and source of truth as the derived reconciled value decisions read on the read path",
"States that forcing one system to serve both the write path and the read path is the recurring design mistake because the two paths want opposite properties",
"Produces a designation table with one row per object class covering at minimum account, contact or person, opportunity, subscription or contract, usage event, and revenue metrics",
"Every designation table row names an authoring system, a read-side truth, and a named owner or owning role",
"Designates the billing platform, not Salesforce, as the authoring system for the subscription or contract object class",
"Treats the revenue metrics row as derived with no single authoring system rather than inventing one for it",
"Instructs the user to publish the designation table before purchasing the metrics layer product, and gives the reason that a tool bought first renders the same dispute in a new interface",
"Applies the QBR test as the enforcement check: no two teams can present conflicting ARR numbers and both be defensible",
"Labels the per-object-class designation table as the dominant pattern in practice rather than a published standard or canon",
"Asks clarifying questions one at a time about motion, systems, scale, deadline, and effort ceiling before drafting the deliverable",
"Does not propose Salesforce validation rules, required fields, or a record deduplication pass as the fix for the conflicting customer counts"
]
},
{
"id": 2,
"prompt": "Halverson Grid, 310 employees, roughly $41M ARR, B2B subscription software. At last week's board meeting our CRO presented $41.2M ARR and twenty minutes later our CFO presented $36.8M. The CEO was visibly angry and has told me to, and I quote, run a data cleanup sprint on Salesforce and dedupe everything so this never happens again. He also asked me to price a data quality tool. I have four weeks and two analysts. Give me the plan.",
"expected_output": "A plan that reframes the gap as a definitional dispute rather than a hygiene problem, runs a signed metric taxonomy workshop across Finance, Sales, and Marketing before any encoding, stores definitions in a diffable home with change review, and measures success by conflicting-number incidents.",
"files": [],
"expectations": [
"Diagnoses the two numbers as a definitional dispute rather than a data quality or duplicate record problem",
"Names bookings, billings, recognized revenue, and ARR/MRR as four distinct numbers that are not expected to match",
"States that no amount of CRM cleanup or deduplication resolves a taxonomy dispute",
"Prescribes a metric definition workshop producing one shared taxonomy signed by Finance, Sales, and Marketing",
"Requires the cross-functional definition agreement to be reached before any definition is encoded in a tool or semantic layer",
"Requires the signed definitions to live somewhere diffable or version-controlled with a documented change-review process",
"States that ARR and MRR are normalized from active subscriptions rather than read off raw billings",
"States that a CRM figure and a general ledger figure diverge by design rather than because one of them is wrong",
"Advises against reporting ARR or MRR straight out of the CRM",
"Uses conflicting-number incidents per executive review cycle, target zero, as the success measure",
"Rejects counting documented definitions or written contracts as a success metric because both count artifacts rather than enforcement",
"Marks any signature that cannot be collected inside the four weeks as pending with a date and a named signer rather than leaving the signer unnamed",
"Does not present the cleanup and dedupe sprint or the data quality tool purchase as the primary remedy"
]
},
{
"id": 3,
"prompt": "I am Head of Data at Corvid Analytics, about $60M ARR, and I own the Q3 data plan. The plan I have drafted is: data contracts on all 46 GTM pipelines, each producing team documents its schema in a shared YAML template by end of month, and my team reviews the whole library quarterly. We run dbt on Snowflake and I have four analytics engineers. I need a rollout plan and the contract template to hand out at the kickoff.",
"expected_output": "A narrow contract register scoped to named revenue-critical producer-consumer boundaries, each with producer, consumer, bundle, and an enforcement rung with a named actor, starting consumer-defined, with the practitioner debate stated both ways and org-wide coverage removed from the menu.",
"files": [],
"expectations": [
"Rejects contract coverage across all 46 pipelines and narrows the register to a named handful of revenue-critical producer-consumer boundaries",
"Gives the reason that broad coverage produces contracts that are written but never enforced",
"States that every register entry must name a producer, a consumer, and an enforcement action",
"Names the four elements a contract bundles: schema, quality checks, SLA, and ownership",
"Recommends starting consumer-defined rather than producer-defined, as the mechanism that builds awareness first",
"Presents enforcement as ranked rungs running from consumer-defined monitoring checks through scheduled contract tests to producer-side CI or pre-merge validation",
"States the condition for promoting a boundary to producer-enforced CI: its breakage has already taken down revenue reporting once, or a single stale sync cycle changes an action rather than a report",
"Presents the data contract debate as genuinely unsettled and states both sides rather than presenting contracts as settled practice",
"Attributes the coining of the term and the GoCardless experience to Andrew Jones, including his framing of contracts as a large culture shift",
"Cites Chad Sanderson's measured position that contracts work on the handful of boundaries everyone already agrees are critical",
"Notes the conflict of interest that vendors selling contract tooling have an incentive to claim broader efficacy than the evidence supports",
"Rejects a quarterly documentation review as enforcement, stating that a contract with no enforcement action is documentation",
"Removes org-wide contract coverage from the option menu entirely rather than listing it as a lower-ranked option"
]
},
{
"id": 4,
"prompt": "Tessellate Cloud, RevOps lead here. Snowflake computes three things for every account: a health tier, a computed ARR figure, and a 30-day usage summary. Census pushes all three into Salesforce every night at 2am. Reps routinely overwrite the health tier when they disagree with it. Our enrichment vendor overwrites employee count on the account object on its own schedule. And there is a Zapier automation someone built last year that writes the ARR field when a renewal closes. The result is that numbers flip back and forth between Monday and Wednesday and the exec team has stopped trusting the account page entirely. What is the rule I should write?",
"expected_output": "A sole-author rule naming the warehouse as the only writer of every reverse-ETL'd field, written into the designation table, with each competing writer ruled on, a non-writeback feedback path for rep disagreement, and operational systems retained as SOR for what they author.",
"files": [],
"expectations": [
"Names the warehouse as the sole author of every field it syncs outward into the CRM",
"Explains the failure as circular lineage: the value re-exports until there is no truth left to point at",
"Requires that no governed value have two writers without a declared winner named in the policy",
"Rules individually on all three competing writers: the reps' manual overrides, the enrichment vendor, and the renewal automation",
"Writes the sole-author rule into the designation table itself rather than leaving it as loose prose advice",
"Keeps the operational systems as system of record for what they author while the warehouse remains source of truth for the modeled values",
"Provides a non-writeback path for rep disagreement with the health tier, such as an override request or feedback routed to the model owner, instead of allowing direct field edits",
"Names an owner for each synced field",
"Identifies the setup as warehouse-as-hub federated and says which described facts support that operating model",
"Does not resolve the flipping by making the CRM authoritative for the computed values",
"States that field-level write precedence inside the CRM is a narrower, different problem from the cross-system authority question this policy settles",
"Ties success to each governed value having exactly one author rather than to the nightly sync completing without errors"
]
},
{
"id": 5,
"prompt": "Nimbleford runs a hybrid motion: self-serve signup with a sales team that works expansion. Roughly 40,000 monthly anonymous visitors, 9,000 self-serve workspaces, and 400 accounts in Salesforce that sales actually touches. Our identity match rate sits at 28% and the board has set a 90% target for end of year. I have a $220k per year quote from an identity resolution vendor that claims it can close most of that gap. Separately, churn events fire in Stripe and never make it onto the account record in Salesforce, so CS finds out about cancellations from the customer. I need an identity and ownership policy.",
"expected_output": "An identity spine with canonical account and person IDs, an alias table, exact-then-review resolution, coverage measured against the linkable population rather than all traffic, the 90% target renegotiated, the hybrid workspace-to-account seam named, and billing designated SOR for churn events.",
"files": [],
"expectations": [
"Reframes the coverage measure: resolution coverage must be measured against the linkable population, never against all traffic or all visitors",
"States that anonymous behavioral identity is largely unresolvable and that no tool closes that seam",
"Advises against funding the large vendor spend on the premise that anonymous identity is fully resolvable",
"Prescribes exactly one canonical account ID and one canonical person ID",
"Prescribes an alias table mapping every system's native keys back to the canonical IDs",
"Specifies automatic resolution for exact matches with fuzzy cases routed to human review",
"Identifies the hybrid seam, reconciling the user-to-workspace graph against the account hierarchy, as where most identity failures originate",
"Names domain clustering of self-serve signups into workspaces as the standard bridge for the hybrid motion",
"States that domain matching and using the CRM ID as a universal key both break on M&A, subsidiaries, and self-serve signups, and that the alias table absorbs those breaks",
"Treats the Stripe churn events not reaching Salesforce as a join-key problem and designates the billing platform as the authoring system for subscription and churn events",
"Expresses the coverage target against the linkable population rather than accepting a single blended percentage across all traffic",
"Does not accept the 90% match-rate target as the board stated it"
]
},
{
"id": 6,
"prompt": "Bracken Type Co, 62 employees, $6.4M ARR, seat-based annual plans only. We run HubSpot and Stripe Billing. No warehouse, no data engineer, no analytics engineer. I am the entire RevOps function and I can realistically spend about six hours a week on this. Our CTO read a long article about data mesh over the weekend and now wants each GTM team to own its data as a product behind contracts. I have a board meeting in five weeks where I need to present a governance architecture. Design it.",
"expected_output": "A CRM-centric hub recommendation justified against the practitioner threshold, with the operating-model options ranked explicitly, data mesh's value-versus-effort position and promotion condition named, options deleted by the capacity and deadline constraints recorded with their cause, and the designation table plus definition workshop sequenced for the five-week window.",
"files": [],
"expectations": [
"Recommends the CRM-centric hub operating model rather than data mesh or warehouse-as-hub",
"Justifies the recommendation against the roughly $10M ARR and seat-based billing threshold for staying CRM-centric",
"Labels that threshold explicitly as a practitioner benchmark rather than audited research",
"Presents two or three candidate operating models with trade-offs, recommends one, and asks for approval before drafting the designation table",
"States the efficiency ordering of operating models explicitly, with CRM-centric hub ahead of warehouse-as-hub federated ahead of data-mesh domain ownership",
"States that data mesh ranks highest on value and loses every efficiency round because its effort is organizational rather than technical",
"Names the condition that would promote data mesh anyway: multiple domain teams already producing governed datasets plus a sponsor mandate covering operating-model change",
"Deletes CI-enforced producer contracts and warehouse-as-hub from this cycle's menu on the grounds that there is no data engineering capacity",
"Records each deleted option together with the specific constraint that deleted it, inside the deliverable",
"Promotes the designation table and the definition workshop because of the five-week board deadline and queues contract engineering for a later cycle",
"Names the point at which CRM-centric stops scaling: when usage events or billing reconciliation start to matter, because a CRM cannot hold an event log",
"Does not recommend purchasing a warehouse, reverse-ETL tooling, or a semantic layer product in this cycle"
]
},
{
"id": 7,
"prompt": "Straylight Compute bills purely on consumption, per gigabyte processed. Our application emits usage events into Segment, which fans them out to Amplitude and to Snowflake. A nightly script reads Snowflake and generates the invoices. Last month Finance found a customer who was billed twice for the same processing job in March, and a second customer whose March usage was understated because a late-arriving batch landed after invoicing. My plan was to declare Snowflake the source of truth for usage and add a pile of dbt tests on the usage model. My VP Eng thinks that is fine. Tell me what the governance call should be.",
"expected_output": "A designation making the metering platform SOR and SOT for billable usage events, with the structural reason the warehouse and product analytics are excluded, idempotency-keyed ingestion, a bounded correction window, a void-and-regenerate path, and the ingestion boundary written into the contract register.",
"files": [],
"expectations": [
"Designates a metering or billing platform as both the authoring system and the read-side truth for billable usage events, rather than the warehouse or product analytics",
"Rejects the plan to declare Snowflake the source of truth for billable usage",
"Explains the exclusion structurally: billing needs row-level correctness guarantees while warehouses and analytics tools are built for aggregate, eventually consistent analysis",
"States that a warehouse can join CRM, billing, telemetry, and support data but has no opinion about what any of it means for a single invoice line",
"Names an event-level idempotency key or transaction identifier as the dedup mechanism that prevents the observed double billing",
"Names a bounded backfill or resubmission window as part of the contract, citing a documented vendor example such as the 34-day correction window",
"Names a documented void-and-regenerate procedure for invoices finalized before a correction landed, covering the understated customer",
"Writes the metering ingestion boundary into the contract register with its schema, quality, SLA, and ownership elements",
"States that the metering vendor landscape has consolidated into payments and CRM incumbents while the designation itself holds regardless of which company operates that layer",
"Notes that product analytics or the application database can author usage events only before that usage becomes billable",
"States that usage-based billing raises event data to revenue-grade and moves the warehouse question forward in the operating-model decision",
"Does not accept dbt tests on the warehouse model as sufficient enforcement for the billing boundary",
"Separates the warehouse's reconciliation and reporting role from the metering platform's authoritative billable-usage role instead of assigning both jobs to one system"
]
},
{
"id": 8,
"prompt": "Lattimer Row, B2B software, about $55M ARR. Our CFO wants one revenue number and has asked me to build revenue recognition logic in Snowflake so that CRM ARR and the NetSuite revenue number reconcile exactly every month. Concrete example that set him off: a $1.2M annual contract signed on 18 December shows as $1.2M in Salesforce and about $34k in NetSuite for December. He says something is broken and wants it fixed before the Q1 close. We run Salesforce, Zuora for billing, and NetSuite as the GL. Tell me how to respond and what policy to write.",
"expected_output": "An explanation of the divergence as structural, a four-layer CRM to billing to RevRec to GL chain with recognized revenue authored in the GL under Finance, a refusal to rebuild revenue recognition in the warehouse, named divergence categories, a bookings-to-recognized bridge, and both architectural schools stated.",
"files": [],
"expectations": [
"States that the CRM figure and the general ledger figure are two different objects and are not expected to match",
"Explains the December gap as ratable recognition with the remainder sitting in deferred revenue, not as a defect",
"Names the four-layer chain of CRM, billing, revenue recognition engine, and general ledger, and what each layer is authoritative for",
"States that the general ledger is a system of record and explicitly not a data warehouse",
"Designates recognized revenue as authored in the general ledger under Finance ownership",
"Declines to redesign revenue recognition itself, scoping the work to designating the boundary",
"Rejects building revenue recognition logic in Snowflake as the fix",
"Names structural divergence categories such as timing differences, allocation differences, and modification differences",
"Names at least one billing-to-RevRec seam failure, such as invoices generated before service activation, credits that never flow into a RevRec adjustment, usage billed in arrears against ratably recognized fixed fees, or refunds processed outside billing",
"States that the RevRec engine posts a summarized journal entry per period into the GL rather than raw transaction detail",
"Presents the emerging native-GL or unified-ledger architecture as a second school alongside the traditional separate-and-reconcile school, without silently picking a winner",
"Labels the unified-ledger position as vendor positioning documenting a real trend rather than as established practice",
"Proposes a reconciliation or bridge artifact between bookings and recognized revenue instead of forcing the two numbers to be equal"
]
},
{
"id": 9,
"prompt": "Aldergrove Systems, 900 employees, VP RevOps speaking. Three asks. First, place us on Forrester's RevOps maturity stages so I can show the exec team exactly where we sit and what the next stage requires. Second, I want to stand up a data governance council. I can get one hour a month from directors in Sales Ops, Marketing Ops, and FP&A. Our CFO and CRO have both declined to join and have not committed to backing whatever the council decides. Third, we have 140 quota-carrying sellers and I need a defensible RevOps headcount number to take into planning.",
"expected_output": "A refusal to restate paywalled Forrester maturity stage names, the public Opportunity Lifecycle framework offered instead, a blunt call that a council without CFO/CRO backing is worse than none, a charter specification with decision rights and escalation, and a staffing figure carried as a benchmark range.",
"files": [],
"expectations": [
"States that the stage names of Forrester's RevOps maturity assessment sit behind a paywall and that any restatement of them is unverified",
"Declines to place the company on named Forrester maturity stages, or does so only with that unverified label attached",
"Offers Forrester's public Opportunity Lifecycle framework as the citable alternative and names its four tenets",
"States that a council without executive sponsorship is a council in name only and is worse than not having one",
"Names the missing CFO and CRO backing as the specific defect, because escalation must run to the council first and then to the CFO or CRO",
"Requires the council charter to carry named members, a cadence on a calendar, documented decision rights, and enforcement actions naming who acts when each fires",
"States that a council holding authority without an enforcement mechanism becomes a tax on the organization",
"Gives a staffing figure anchored on roughly 12 sellers to 1 RevOps headcount, flagged as a practitioner benchmark rather than audited research",
"States that ratios across sources range from 10:1 to 50:1 rather than presenting a single precise number",
"Notes that the seller-to-RevOps ratio thins past roughly 1,000 employees",
"Does not attribute a $4-8M ARR first-RevOps-hire trigger to Stage 2 Capital",
"Picks one decision-rights vocabulary, either data owner and data steward or domain owner, and uses it consistently throughout",
"If any maturity claim is used, cites the verified Gartner findings that advanced-maturity RevOps organizations are twice as likely to exceed revenue goals and 2.3 times as likely to exceed profit goals",
"Does not cite a Clari RevOps maturity model and does not present RevOps Co-op's four pillars as a staged maturity model"
]
},
{
"id": 10,
"prompt": "Kestrel Health Data closed its acquisition of Pallas Analytics four months ago. We now run two CRMs, Salesforce on our side and Dynamics on theirs, two billing systems, and two separate warehouses. We wrote a source-of-truth document about 18 months ago, before the deal, and every page of it is now wrong. Our CEO keeps telling the exec team that we should just run our revenue data the way Stripe and Figma do and asks me every week why we have not copied them yet. I need a policy I can actually defend in the integration steering committee on Thursday.",
"expected_output": "A policy that refuses the lore-based model, starts from GitLab's public handbook structure, re-designates per object class across the merged stack, absorbs the join-key breaks in an alias table, and makes designation review a standing M&A integration step with the QBR test re-run.",
"files": [],
"expectations": [
"States that public claims about how Stripe, Figma, Atlassian, Notion, or Datadog run internal revenue data governance are industry lore, because none of them documents it publicly",
"Declines to model the policy on Stripe or Figma practices",
"Recommends GitLab's public handbook as the documented exception to start the structure from",
"Names verifiable GitLab elements such as a central enterprise data team with embedded function analytics teams, a data quality program, or KPI definitions required to state their canonical data source and calculation formula",
"Makes designation-table review a standing step in M&A integration rather than a one-off cleanup",
"States that the designation table is only current until the next system of record arrives",
"Requires re-running the QBR test after the merger and after every new system entering the stack",
"Resolves the two-CRM situation by designating authority per object class rather than declaring one CRM the winner for everything up front",
"Uses the alias table to absorb the M&A join-key breaks instead of relying on domain matching or a universal CRM ID",
"Names the failure mode in which systems of record multiply faster than the designation table consolidates them",
"Asks which systems the merger duplicated, and the rest of the intake questions, before proposing the consolidation",
"Separates tool ownership and consolidation decisions from data authority, and does not present a CRM migration choice as the governance deliverable"
]
}
],
"trigger_queries": [
{
"query": "Finance and Sales presented two different ARR numbers to the board again. How do I make one of them authoritative?",
"should_trigger": true
},
{
"query": "We need a source of truth map across Salesforce, our billing platform, and Snowflake.",
"should_trigger": true
},
{
"query": "Set up revenue data governance for our GTM stack.",
"should_trigger": true
},
{
"query": "Which system should win when the CRM opportunity and the billing subscription disagree?",
"should_trigger": true
},
{
"query": "Nobody has ever written down which system is authoritative for what. Can you build that?",
"should_trigger": true
},
{
"query": "Design a system-of-record and source-of-truth designation table for our revenue objects.",
"should_trigger": true
},
{
"query": "Our CEO declared Salesforce the single source of truth and it has not stopped the dashboard fights.",
"should_trigger": true
},
{
"query": "We have three dashboards showing three different customer counts and every team insists theirs is right.",
"should_trigger": true
},
{
"query": "Who should own the definition of ARR at our company?",
"should_trigger": true
},
{
"query": "I need a data contract register for the pipelines that feed our revenue reporting.",
"should_trigger": true
},
{
"query": "Where should our metric definitions live and who signs off when one changes?",
"should_trigger": true
},
{
"query": "Our self-serve signups never match the accounts sales works. Design the identity and ownership policy.",
"should_trigger": true
},
{
"query": "help me figure out who owns what data across our revenue systems",
"should_trigger": true
},
{
"query": "two teams, two ARR numbers, one very angry CEO. fix it",
"should_trigger": true
},
{
"query": "Should the warehouse or the CRM be authoritative for computed ARR?",
"should_trigger": true
},
{
"query": "We are standing up a governance council for revenue data. What should its charter say?",
"should_trigger": true
},
{
"query": "Post-merger we have two CRMs and two billing systems and no rule for which one wins.",
"should_trigger": true
},
{
"query": "Our warehouse syncs values back into Salesforce but reps also edit those fields. What is the policy?",
"should_trigger": true
},
{
"query": "Write the org-wide policy for which system authors each revenue object.",
"should_trigger": true
},
{
"query": "How do I stop bookings, billings, and recognized revenue from being used interchangeably around here?",
"should_trigger": true
},
{
"query": "Do we need data contracts between our GTM teams, and if so, where exactly?",
"should_trigger": true
},
{
"query": "Build the identity spine for our accounts and users across CRM, billing, and product analytics.",
"should_trigger": true
},
{
"query": "Churn fires in Stripe and never shows up on the account record. What is the governance fix?",
"should_trigger": true
},
{
"query": "Our board wants one revenue number and we currently have four. Where do I start?",
"should_trigger": true
},
{
"query": "I want a policy document that says which system decides what, and who arbitrates disputes.",
"should_trigger": true
},
{
"query": "what is the right way to decide who owns a metric definition",
"should_trigger": true
},
{
"query": "We are moving to usage-based billing. Which system should be authoritative for usage events?",
"should_trigger": true
},
{
"query": "Everyone builds their own ARR query. How do we make one of them the official one?",
"should_trigger": true
},
{
"query": "Design the federated ownership model for our revenue data.",
"should_trigger": true
},
{
"query": "Can you help me write the escalation path for when two teams disagree about a number?",
"should_trigger": true
},
{
"query": "My analytics engineer and my RevOps lead both think they own the pipeline metrics. Who actually does?",
"should_trigger": true
},
{
"query": "We bought a semantic layer tool six months ago and the arguments have not stopped.",
"should_trigger": true
},
{
"query": "How should we govern revenue metric definitions across Finance, Sales, and Marketing?",
"should_trigger": true
},
{
"query": "I need to decide whether we go warehouse-as-hub or keep everything in the CRM.",
"should_trigger": true
},
{
"query": "Is data mesh the right model for our GTM data, or is it overkill for us?",
"should_trigger": true
},
{
"query": "Our CRM says $41M ARR and NetSuite says $37M. Which one is wrong?",
"should_trigger": true
},
{
"query": "set the rules for which tool authors which customer record",
"should_trigger": true
},
{
"query": "Our quarterly business reviews always devolve into arguing about whose number is right.",
"should_trigger": true
},
{
"query": "Draft a revenue data governance policy for a hybrid PLG and sales-led company.",
"should_trigger": true
},
{
"query": "We keep buying tools to fix reporting disputes and the disputes keep coming back.",
"should_trigger": true
},
{
"query": "How do I get Finance, Sales, and Marketing to sign one metric taxonomy?",
"should_trigger": true
},
{
"query": "What should the arbitration process look like when data definitions conflict across teams?",
"should_trigger": true
},
{
"query": "I need to document, per object, which system authors it and which one we report from.",
"should_trigger": true
},
{
"query": "Who owns the account hierarchy, sales or the data team?",
"should_trigger": true
},
{
"query": "Our identity match rate is 30% and the board wants 90%. What do I tell them?",
"should_trigger": true
},
{
"query": "Can you write the rule for our reverse-ETL fields so we stop having two writers?",
"should_trigger": true
},
{
"query": "Should product analytics or the billing platform be the truth for consumption data?",
"should_trigger": true
},
{
"query": "Every system in our stack claims to be the customer master. Sort it out.",
"should_trigger": true
},
{
"query": "We need a governance operating model for revenue data that survives adding new systems.",
"should_trigger": true
},
{
"query": "Help me scope a metric definition workshop with Finance and Sales.",
"should_trigger": true
},
{
"query": "explain how to split system of record from source of truth for our revenue objects",
"should_trigger": true
},
{
"query": "What enforcement plan keeps the governance doc from just rotting in a drive folder?",
"should_trigger": true
},
{
"query": "Our recognized revenue and our CRM bookings never tie out and nobody knows whose job that is.",
"should_trigger": true
},
{
"query": "I am the new VP RevOps and there is no data authority policy at all. Where do I start?",
"should_trigger": true
},
{
"query": "Make a plan so no two teams can present conflicting revenue numbers and both be defensible.",
"should_trigger": true
},
{
"query": "Who arbitrates when the pipeline number in the dashboard disagrees with the CRM?",
"should_trigger": true
},
{
"query": "Who should own the Industry picklist field in Salesforce and how often must it be refreshed?",
"should_trigger": false
},
{
"query": "Write validation rules so reps cannot leave the close date blank on an opportunity.",
"should_trigger": false
},
{
"query": "Build a CRM field dictionary with write precedence and conflict rules for each field.",
"should_trigger": false
},
{
"query": "Our CRM has 400 custom fields and nobody knows which are still used. Audit them.",
"should_trigger": false
},
{
"query": "Set freshness SLAs for the contact fields in our CRM.",
"should_trigger": false
},
{
"query": "Design a field lifecycle process for deprecating unused CRM fields.",
"should_trigger": false
},
{
"query": "Which revenue KPIs should the board see versus the frontline AE?",
"should_trigger": false
},
{
"query": "Build a metric tree that rolls up from rep-level activity to company ARR.",
"should_trigger": false
},
{
"query": "What guardrail counter-metric should ride alongside pipeline coverage?",
"should_trigger": false
},
{
"query": "Pick the right KPI set for a Series B product-led company.",
"should_trigger": false
},
{
"query": "Structure our monthly board revenue deck so a miss does not blindside anyone.",
"should_trigger": false
},
{
"query": "What narrative order should an executive revenue report follow?",
"should_trigger": false
},
{
"query": "Set the cadence for weekly versus monthly versus quarterly revenue reporting.",
"should_trigger": false
},
{
"query": "Find where deals are silently dying between MQL and SQL and size the loss in recoverable dollars.",
"should_trigger": false
},
{
"query": "We think we are losing money on renewals but cannot prove it. Trace the leak.",
"should_trigger": false
},
{
"query": "We have 47 GTM tools and a renewal coming up. What do we cut?",
"should_trigger": false
},
{
"query": "Score our sales tech stack with TIME and tell me what to consolidate.",
"should_trigger": false
},
{
"query": "Our MQL threshold is producing garbage leads. Recalibrate the scoring model.",
"should_trigger": false
},
{
"query": "Design the round-robin rules for assigning inbound leads to reps by territory.",
"should_trigger": false
},
{
"query": "Build a weighted customer health score from product usage and support tickets.",
"should_trigger": false
},
{
"query": "Rank the leading indicators of churn for our enterprise accounts.",
"should_trigger": false
},
{
"query": "Our forecast has missed four quarters running. Diagnose why.",
"should_trigger": false
},
{
"query": "Audit our pipeline stage exit criteria against buyer-verifiable milestones.",
"should_trigger": false
},
{
"query": "Flag every stale deal in the pipeline and give me a disposition for each one.",
"should_trigger": false
},
{
"query": "Design what data transfers from Sales to CS when a deal closes.",
"should_trigger": false
},
{
"query": "Build the discount approval matrix for non-standard deals.",
"should_trigger": false
},
{
"query": "Design our funnel stage set and decide whether the unit of analysis is the lead or the buying group.",
"should_trigger": false
},
{
"query": "What does a Director of RevOps need on their resume to get promoted to VP?",
"should_trigger": false
},
{
"query": "Write the interview loop and scorecard for a RevOps manager hire.",
"should_trigger": false
},
{
"query": "Give me a list of RevOps podcasts and newsletters worth following.",
"should_trigger": false
},
{
"query": "Set up a data quality testing framework for our dbt models.",
"should_trigger": false
},
{
"query": "Write our GDPR data handling and retention policy for customer personal data.",
"should_trigger": false
},
{
"query": "Design the schema for our event ingestion pipeline into the data lake.",
"should_trigger": false
},
{
"query": "Build a data catalog so analysts can find the right tables in Snowflake.",
"should_trigger": false
},
{
"query": "How do I set up column-level lineage tracking in our warehouse?",
"should_trigger": false
},
{
"query": "Write an OpenAPI contract for our public REST endpoints and version it properly.",
"should_trigger": false
},
{
"query": "Design a master data management approach for our product catalog SKUs.",
"should_trigger": false
},
{
"query": "Our Airflow DAGs keep failing silently. Add alerting and retries.",
"should_trigger": false
},
{
"query": "Define governance rules for which AI agents can access which internal tools.",
"should_trigger": false
},
{
"query": "Normalize our Postgres schema for the orders table.",
"should_trigger": false
},
{
"query": "Which data warehouse should we buy: Snowflake, BigQuery, or Databricks?",
"should_trigger": false
},
{
"query": "Set up row-level security in Snowflake so each department only sees its own rows.",
"should_trigger": false
},
{
"query": "Write a data retention and deletion policy to satisfy our SOC 2 audit.",
"should_trigger": false
},
{
"query": "We are migrating reporting from Looker to Tableau. What breaks?",
"should_trigger": false
},
{
"query": "Build a dbt semantic model for our orders and revenue tables.",
"should_trigger": false
},
{
"query": "How do I implement ASC 606 recognition rules for multi-element arrangements?",
"should_trigger": false
},
{
"query": "Reconcile last month's Stripe payouts against our bank statement.",
"should_trigger": false
},
{
"query": "What should our sales commission plan pay out on multi-year deals?",
"should_trigger": false
},
{
"query": "Write a privacy notice for our website covering cookies and tracking.",
"should_trigger": false
},
{
"query": "Set naming conventions for our product event tracking plan in Segment.",
"should_trigger": false
},
{
"query": "Our Salesforce-to-HubSpot sync keeps creating duplicate contacts. Debug the integration.",
"should_trigger": false
},
{
"query": "Build a customer 360 dashboard in Looker.",
"should_trigger": false
},
{
"query": "Choose a CDP for us: Segment, RudderStack, or mParticle?",
"should_trigger": false
},
{
"query": "Write the incident runbook for when our nightly ETL job fails.",
"should_trigger": false
},
{
"query": "Draft a vendor security questionnaire for our data processors.",
"should_trigger": false
},
{
"query": "Explain how a star schema differs from one big table for analytics modeling.",
"should_trigger": false
}
]
}
references/data-contract-register.md›
# The Data-Contract Register
## One term, two meanings
"Data contract" names both a technical artifact (a versioned schema spec enforced in CI) and an organizational agreement between a producer team and its consumers. Andrew Jones, who coined the term at GoCardless in 2021, treats it as both at once; Chad Sanderson treats it primarily as an enforced technical boundary. Keep both meanings visible in the register: every entry is an agreement first and an artifact second.
## What a contract bundles
Four elements recur across every source that defines the term: **schema, quality checks, SLA, and ownership** - plus how consumers access the data. The dominant open standard is ODCS (Open Data Contract Standard, Bitol project, Linux Foundation AI & Data - descended from PayPal's internal data-contract template): one versioned YAML file covering fundamentals, schema, quality, SLA, security/stakeholders.
Adjacent mechanisms that express the same bundle: transformation-tool model contracts (enforced column types, versioned models) and schema registries for event streams. Name the bundle in the register; the specific format is the org's choice.
The RevOps ownership split around contracts (Pedowitz Group): **RevOps owns the shared models, the contracts, quality, and canonical IDs; each department owns its own domain data and usage.** Their starting artifact set is worth copying: an object dictionary, a contract library, and lineage diagrams linked directly from dashboards - so a reader traces a number to its source without asking anyone.
## The debate - state both sides in the deliverable
This is unsettled, and the deliverable must say so rather than picking a winner silently:
- **Andrew Jones** reports real success at GoCardless but frames contracts as "a big culture shift that is going to take some time," needing constant communication.
- **Chad Sanderson** - who built a contracts company - is now notably measured: "Contracts are genuinely good at one thing... They take a boundary everyone already agrees is critical and turn it into an agreement that gets enforced automatically on every change. For the handful of fields where everyone knows that if this breaks the business goes down, that is exactly the right control." He also argues producer-defined contracts fail without top-to-bottom buy-in - producers "will change contracts however they need to when shipping new features as they have no accountability for data outages downstream" - and advocates starting **consumer-defined**, as the awareness mechanism. The recurring failure he names: contracts written but not enforced, catching breakage downstream, "definitionally reactive."
The working conclusion for this skill: contracts succeed as narrow, automated circuit breakers on the handful of producer boundaries whose breakage takes down revenue reporting, and fail as a broad governance layer - the emerging consensus among the practice's own inventors. Note the conflict of interest both ways: vendors selling contract tooling have an incentive to claim broader efficacy than the evidence supports.
## Enforcement actions, weakest to strongest
1. **Consumer-defined monitoring check** - a scheduled query on the consumer side that fails loudly on drift. Cheapest; builds the awareness Sanderson says producer-side contracts need first.
2. **Scheduled contract tests** - the contract's quality checks run on a schedule against the produced data; violations page the producer's owner.
3. **CI/pre-merge validation on the producer** - contract tests fail the producer's build, comment on the offending change, and tag subscribed consumers; the strongest tools add circuit breakers. This is "shift-left": enforcement at the point of code change, not detection after breakage.
Every register entry names its rung and who acts when it fires. A contract with no enforcement action is documentation, and documentation is the documented failure mode.
## A real-world instance: usage-metering ingestion as a data contract
Unlike the illustrative composite below, this boundary is real and named. Usage-metering platforms (Orb, Metronome) document the exact contract bundle this section describes, enforced in their own ingestion API rather than proposed as a pattern: an idempotency or transaction identifier on every event (schema), ingestion-time payload and timestamp validation plus deduplication (quality), a bounded grace or resubmission window such as Metronome's 34-day correction path (SLA), and a documented void-and-regenerate procedure for invoices that finalized before a correction landed (ownership of the fix). This is rung-1/2 enforcement (see below) already running in production at the vendor layer - a producer boundary this skill would otherwise have to specify from scratch is already specified, which is worth citing to a user standing up their own usage-based billing contract register rather than reinventing the bundle.
## Worked register entry - done right
Illustrative composite; the boundary pattern is sourced, the company is not real.
```
Boundary : billing platform -> warehouse subscription model (feeds ARR)
Producer : billing platform integration, owned by Finance systems owner
Consumer : analytics engineering (ARR model); downstream: exec reporting
Why critical : a schema or semantics change here silently corrupts the
company's ARR number - the QBR test fails within one cycle
Bundle : schema (subscription id, account alias key, plan, seat count,
MRR amount, start/end/cancel dates); quality (no null account
keys, amounts reconcile to invoiced totals within the agreed
tolerance); SLA (loaded by 06:00, gaps flagged within 1h);
ownership (producer owner named above)
Defined by : consumer (analytics engineering) - first cycle
Enforcement : rung 2 now (scheduled contract tests paging the producer owner);
promote to rung 3 producer CI once the billing integration has
a deploy pipeline the tests can gate
```
## Negative example - done wrong
> "Q3 initiative: data contracts on all 40 GTM pipelines. Each team documents its schemas in the contract template by end of month. The data team will review quarterly."
Every failure mode, in one register entry:
- Coverage is org-wide instead of critical-boundary-only, so most contracts protect nothing worth the maintenance.
- The contracts are documents with a quarterly review, not enforced checks, written but never enforced.
- Producers document their own boundaries with no consumer pull and no accountability for downstream outages.
- By the quarterly review, half the schemas have drifted, teaching everyone the register is fiction.
Forty stale contracts govern less than three enforced ones.
references/frameworks-and-benchmarks.md›
# Frameworks, Benchmarks, and Citation Rules
Read this before citing any framework, maturity model, staffing figure, or case study in the deliverable. Every claim below carries its verification status; carry that status into the output.
## Competing frameworks, none canonical
No trademarked methodology covers CRM + billing + product analytics governance under one proper-noun title. Several models recur; treat each as a lens, never as the standard.
| Framework | Origin | What it governs | Status |
| ------------------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Data Mesh (4 principles) | Zhamak Dehghani, Thoughtworks, 2019 | Domain ownership, data as product, self-serve platform, federated computational governance | Verified; GTM/revenue as a domain is an application, not its origin |
| DAMA-DMBOK2 | DAMA International | Reference body of knowledge, 11 areas | Vocabulary/reference, not a maturity scale |
| DCAM / CDMC | EDM Council | Capability + cloud-controls models | Financial-services origin; assessment use |
| Gartner RevOps maturity | Gartner | Developing → Intermediate → Advanced | Verified directly from Gartner |
| Forrester RevOps maturity + Opportunity Lifecycle | Forrester | Two separate assets: _Forrester's B2B Revenue Operations Maturity Assessment_ (2023, RES179320) and the Opportunity Lifecycle framework (announced at B2B Summit North America, May 2024) | Maturity Assessment's stage names sit behind Forrester's client paywall - treat secondhand descriptions as unverified. Opportunity Lifecycle's four tenets are public (Forrester press release, 2024-05-06): share signals for a unified customer view; shift from leads to opportunities and buying groups; set shared customer-aligned goals across marketing, sales, and customer success; design experiences around when each function delivers the most buyer value |
| Winning by Design Revenue Architecture / Bowtie | Jacco van der Kooij | Recurring-revenue data model | A GTM data model, not a maturity model |
Verified Gartner figures safe to cite:
- Companies with advanced-maturity RevOps are "twice as likely to exceed revenue goals and 2.3 times as likely to exceed profit goals".
- "by 2026, 75% of the highest-growth companies will adopt a RevOps model, up from less than 30% today" (the original 2021 release said 2025; the date has slipped in Gartner's own restatements - note that when citing).
Do **not** cite:
- A "Clari RevOps maturity model" (Clari's published content is a lifecycle framing, not a staged model).
- RevOps Co-op's "four pillars" as a maturity model (it is not staged).
Four recurring practitioner models, all vendor-published - use as lenses, and flag their figures as cited-not-verified:
- The RevOps four-layer framework (Prometheus Agency: data → process → technology → governance; its 24% and 19% growth figures are citations of citations).
- The unified revenue taxonomy (Durity: define sourced/contracted/recognized stage names both Sales and Finance report against, before automating anything).
- The governed system of record (CRM Forge: governance as defining, enforcing, and evolving capture/maintenance/usage standards).
- Cross-platform coverage (RevenueBase: a framework covering only one platform leaves duplication alive in the others).
## Semantic layers and their critics
The technical instrument for metric-definition governance, distinct from data contracts (which govern a producer-consumer boundary, not business definitions). Named implementations, documented in depth by the engineering teams that built them:
- Airbnb Minerva: "define once, use everywhere" - declarative definitions in version control with peer review and CI.
- Uber uMetric: full metric lifecycle with an independent quality pillar.
- LinkedIn UMP: a specification plus tooling, supporting over 300 data pipelines and hosting more than 8,000 metrics, per LinkedIn Engineering.
State the contrarian view alongside, never as a footnote: Benn Stancil - "the metric layer is the Holy Grail that nobody can find"; a centralized metrics SOT "has proven incredibly difficult to implement and maintain in practice." Prukalpa Sankar titled a piece "Semantic Layers Failed."
Both critics converge on the same diagnosis this skill builds on: the hard part is the cross-functional definition agreement, not the technology. A team that buys the tool before settling the definition fight gets the same dispute rendered in YAML.
## The semantic layer reframed as an "AI context layer"
This is a real, named, dated 2025-2026 reframing, not speculative discourse - Prukalpa Sankar's own successor title to her semantic-layer critique above, "Context Graphs Are Next," is exactly the direction that materialized. It runs predominantly at the general enterprise-analytics level rather than as a RevOps-native discipline, with one clear GTM-specific exception.
- **Cube**: its own product framing states it gives AI agents "a governed context layer... the context they need to answer correctly," positioning the context layer as the superset and the semantic layer as the one part of it that actually executes.
- **dbt Labs**: CEO Tristan Handy, announcing dbt's MCP server, frames agents as running "on the dbt structured context layer." Post-Fivetran-merger (2026), the joint framing splits responsibility: Fivetran for complete/synced/reliable data, dbt for governed business logic, plus an open **Agents Schema** standard designating one warehouse schema as the shared AI-agent context layer.
- **AtScale**: its SVP GTM frames the semantic layer as an "action service" letting agents "understand revenue, churn, attribution, margin... not raw data structures" - the one vendor quote that names revenue metrics as the explicit worked example. AtScale hired a former DataRobot CRO specifically to lead this AI/GTM pivot.
- **ZoomInfo**: the one vendor framing this natively for GTM/revenue data rather than general BI - its "GTM Context Graph" fuses contact, company, intent, CRM, and conversation data, exposed to any agent as "GTM AI... ZoomInfo's context layer for AI tools" via MCP or API.
- **Gartner** (from Gartner's own newsroom): Distinguished VP Analyst Rita Sallam states ungoverned semantics leave agents "far more likely to hallucinate, introduce bias, and produce unreliable results," projecting that by 2027 organizations prioritizing semantics in AI-ready data will raise agentic accuracy up to 80% and cut costs up to 60%. Analyst Andres Garcia-Rodeja's named prediction: by 2028, 60% of agentic analytics projects relying solely on MCP will fail absent a consistent semantic layer.
Practical read for this skill: the recommendation to force the cross-functional definition agreement before encoding it does not change - it gets higher-stakes, since an ungoverned semantic layer now also feeds agent hallucination risk, not just dashboard disputes.
## Ownership and staffing benchmarks
The federated / hub-and-spoke model is the convergence point across dbt Labs, Alation, Atlan, and data mesh's own fourth principle, independently: central standards and a council, domain execution delegated.
Decision-rights split:
- RevOps owns business definitions and GTM process.
- Data/analytics engineering owns models, semantic layer, pipelines.
- Finance owns recognized revenue and ASC 606 compliance.
- A council (chaired by a CDO at large orgs) coordinates and arbitrates, escalating to CFO/CRO what it cannot resolve.
Staffing by stage - **practitioner benchmarks, not audited research; ratios across sources range 10:1 to 50:1**:
| Stage | ~50 employees | ~500 employees | ~5,000 employees |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Policy owner | Founder / Head of Sales, ops generalist | VP RevOps + specialist pod + data/analytics lead | CDO + governance council |
| First hires | First RevOps hire around 10-15 quota reps, Director-level; first data hire at ~20-50 employees - an analytics engineer, not a data scientist | Dedicated analytics engineering; governance formalized with ownership and standards | Platform team + domain pods; council meets monthly/quarterly |
The most empirically grounded single ratio: Adam Schoenfeld's PeerSignal analysis of ~2,500 companies - a 12:1 overall ratio of sellers (AE+SDR) to RevOps, thinning past 1,000 employees. The "$4-8M ARR" first-RevOps-hire trigger circulated by vendors is **not corroborated** in Stage 2 Capital's own writing (Liz Christo frames the need around the 10-30 employee range instead) - do not cite the ARR trigger as hers.
## Case studies: GitLab, and lore
**GitLab documents its own revenue data governance end to end in its public handbook - recommend starting from that structure rather than inventing a governance document from scratch.**
Verifiable elements:
- A central Enterprise Data Team plus function analytics teams embedded in Sales, Marketing, Product, Engineering, Finance.
- A Data Quality Program and governance section.
- "single source of truth" codified as an operating subvalue.
- KPI definitions required to name their canonical data source and calculation formula.
- A public issue tracking replacement of CRM-account-ID references on the customer object, the join-key problem, live and citable.
Atlassian, Figma, Notion, Datadog, Snowflake's internal GTM stack, Stripe: widely referenced in conversation, **none of them documents its internal revenue data governance in public**. Treat any claim about them as industry lore unless one of their own engineering blogs is cited.
references/sor-sot-designation.md›
# SOR/SOT Designation and the Identity Spine
Contents: Definitions; the typical per-object-class pattern; the revenue-recognition pipeline in detail; usage-metering platforms as SOR/SOT; warehouse-as-hub mechanics; the identity spine; worked examples.
## Definitions
- **System of record (SOR):** the operational store that authors and masters a record - the write path. It wants strict transactional behavior.
- **Source of truth (SOT):** the derived, reconciled, authoritative value used for decisions - the read path. It wants broad integration and history.
- **Golden record:** the MDM-specific term for the deduplicated master entity produced by reconciling multiple SORs.
Vendors use all three interchangeably; practitioners do not, and neither should the policy. The design principle (Digna, with Nutrient and Kohezion converging independently): forcing one system to do both jobs is the mistake, because the write path and the read path want opposite properties.
IBM's formulation of the same split: an SOR is authoritative for one business domain; an SOT aggregates and harmonizes across SORs. That is enterprise-data-architecture terminology applied to GTM by analogy rather than a RevOps-native formulation - present it as a lens, not as a RevOps standard.
## The typical per-object-class pattern
**This table is the dominant pattern in practice, not a published canon. Individual orgs vary - adapt it, never copy it unexamined.**
| Object class | Typical SOR (authors) | Typical SOT (decisions read) | Note |
| -------------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Account | CRM | Warehouse account dimension, often MDM-resolved | Parent/child hierarchy usually reconciled in the warehouse against a firmographic provider |
| Contact / Lead / Person | CRM + marketing automation | CDP or warehouse identity table | The highest duplication surface in the stack |
| Deal / Opportunity | CRM | Warehouse opportunity fact table | CRM authors; the warehouse is truth for pipeline metrics |
| Subscription / Contract | Billing platform | Warehouse; billing itself for invoicing | The CRM opportunity and the billing subscription routinely disagree - that is why both columns exist |
| Usage event | Metering platform (or product analytics/app database before usage is billable) | Warehouse; the metering platform for billable usage | See "Usage-metering platforms as SOR/SOT" below for named vendor mechanics |
| Revenue metrics (ARR/MRR/NRR/bookings) | None single - derived | Warehouse + the definitional home | ARR/MRR are normalized from active subscriptions, not raw billings |
| Recognized revenue | General ledger (ASC 606) | GL/ERP | A separate SOR from CRM bookings entirely; owned by Finance - see "The revenue-recognition pipeline in detail" below |
The canonical example worth repeating to the user: the CRM authors the opportunity, but the warehouse is the source of truth for the ARR number - and the GL is a third, separately-authored number for recognized revenue. The CRM figure and the GL figure never match by design.
## The revenue-recognition pipeline in detail
Vendor documentation, not just practitioner convention, supports a four-layer chain for the recognized-revenue object specifically - the closest thing in this skill's sourcing to a published canon, though it covers one object class, not the whole table above. Chargebee's own product docs state the boundary plainly: a RevRec engine (ASC 606 five-step model) absorbs pricing, billing, payment, and revenue complexity and posts one summarized journal entry per period, so "the GL stays exactly what it's meant to be: a system of record" and is explicitly not a data warehouse.
| Layer | Authoritative for | Typical vendor |
| ------------- | -------------------------------------------------- | -------------------------------------------------------------------- |
| CRM | Contract terms, bookings, ARR at signature | Salesforce, HubSpot |
| Billing | Invoices, subscriptions, payments, credits | Zuora Billing, Chargebee, Stripe Billing |
| RevRec engine | ASC 606 five-step allocation, recognition schedule | Zuora Revenue (RevPro), Chargebee RevRec, Stripe Revenue Recognition |
| GL | Summarized period journal entries | NetSuite, QuickBooks, Sage Intacct |
Why the CRM and GL numbers diverge is structural, not a data-quality problem: each layer is authoritative for a different moment in the deal lifecycle. A December annual close can show full contract value in CRM bookings immediately while the GL recognizes only a thin slice that month, the rest sitting in deferred revenue. Named divergence triggers, sourced to a rev-integrity vendor's own documentation (safebooks.ai): timing differences (a Q4 booking that starts recognizing in Q1), allocation differences (bundled elements recognizing at different rates), and modification differences (a post-booking change altering the schedule) - plus, at the billing-to-RevRec seam specifically, invoices generated before service activation, billing credits that never flow through to a RevRec adjustment, usage-based components billed in arrears against fixed fees recognized ratably, and refunds processed outside billing. Ben Murray (The SaaS CFO) argues from the CRM side that ARR/MRR should never be reported straight out of CRM at all, since the CRM is rarely the correct source of truth for recurring revenue - reinforcing that the CRM and GL numbers are two different objects, not one object measured twice.
Vendors formalize the CRM/billing boundary through documented directional sync, not genuine bidirectional truth. Zuora's own connector documentation: the Zuora Billing Connector for Salesforce performs a single directional sync from Zuora to Salesforce, near real-time - Zuora Billing is authoritative, Salesforce is a downstream mirror for billing-owned objects, enforced at the field level by a CRM ID field on the Zuora account that prevents a duplicate account being created on resync. Stripe's own reconciliation documentation names a live discrepancy: an unpaid invoice stays "open" and continues to be recognized as revenue in the Revenue Recognition report, but because it was never collected, the Balance summary report excludes it - a documented mismatch between two reports from the same vendor, not a bug.
A second, competing architecture is emerging that collapses this stack instead of reconciling it: Rillet and LedgerUp both pitch native-GL revenue recognition, arguing the reconciliation layer between a standalone RevRec tool and the books recreates the manual work it was meant to remove. Treat this as vendor positioning documenting a real, growing second school (unify the ledger) against the traditional school (keep CRM/billing/RevRec/GL separate, reconcile explicitly) - state both in the deliverable rather than picking a winner silently, the same posture this skill takes on the data-contract debate.
## Usage-metering platforms as SOR/SOT
For usage-based and consumption billing, the metering/billing platform itself - not product analytics, not the warehouse - is the documented source of truth for the usage events that feed invoices, verified across three named vendors' own API documentation.
| Vendor | Dedup mechanism | Backfill/correction window | Documented control |
| --------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Orb | `idempotency_key` | Raw events retained indefinitely for re-query; grace period governs near-real-time dedup | Ingestion validation + dedup, pre-invoice |
| Metronome | `transaction_id` | 34-day resubmission window; structured correction files | Void/regenerate finalized invoices, full audit trail |
| Amberflo | Not separately documented in public materials found | "Auto reconciliations" (vendor claim, unverified) | Event-level audit trail, ingestion to invoice |
The reason product analytics and the warehouse are excluded is structural, not a vendor gap: billing needs row-level correctness guarantees - no double counting, defined grace periods, auditable corrections tied to one invoice - which idempotency keys and correction workflows exist to provide, while analytics tools and the warehouse are built for aggregate, eventually-consistent analysis. A warehouse can join CRM, billing, product-telemetry, and support data, but has no opinion about what any of it means for a single invoice line.
Treat the metering layer's vendor landscape as unstable, not the designation itself: within roughly six months in 2026, every major independent metering vendor was acquired by a payments or CRM incumbent - Stripe acquired Metronome, Salesforce is acquiring m3ter, and Adyen is acquiring Orb. The designation (metering platform = SOR/SOT for billable usage events) holds regardless of which company ends up operating that layer.
The org-wide split, in one breath (ARISE GTM):
- The CRM owns commercial relationships and engagement, and "should not be your event log or your data warehouse".
- Billing owns contract truth (plans, seats, MRR/ARR inputs, renewal dates, churn events), which the CRM references and never recomputes.
- Product analytics owns behavioral events, usable for revenue decisions only when every event carries consistent user, account, and domain identifiers.
- The warehouse is where the three representations of "the same customer" get reconciled.
## Warehouse-as-hub mechanics
The mature pattern: the warehouse is SOT, operational systems stay SOR for what they author, and reverse-ETL syncs modeled values back into operational tools. Two rules keep it honest:
1. **The warehouse is the sole author of every field it syncs outward.** If anything else also writes that field - a rep, an enrichment provider, another sync - the value re-exports, the lineage turns circular, and the org has two truths again with extra steps.
2. **Adopt it at the right stage.** Practitioner recommendation: warehouse-as-hub above roughly $10M ARR or with usage-based billing; below that, a CRM-centric pattern is adequate and reverse-ETL is overhead. The threshold is a practitioner benchmark, not audited research - tag it as such.
MDM applies to GTM mainly at the account and person entities: the warehouse account dimension becomes the golden record compiled from multiple SORs, while the CRM remains SOR for sales-authored fields (Gartner's "Consolidation MDM" style).
## The identity spine
The verified pattern fix for cross-system join-key mismatch (Supportbench):
- Pick **one canonical account ID and one canonical person ID**.
- Map every system's native keys back to them in an alias table.
- Resolve exact matches automatically.
- Route fuzzy cases to human review.
Domain-based matching and "the CRM ID as universal key" both break on M&A, subsidiaries, and self-serve signups - the alias table is what absorbs those breaks.
The identity problem is two problems, not one (Datawhistl): account/CRM data is a strong-key, near-solved regime; anonymous behavioral data is keyless and mostly unresolvable, and tooling papers over the seam. Two consequences for policy:
- Measure resolution coverage against the **linkable population**, never all traffic - against all traffic, every identity metric is noise.
- Do not fund a large budget pretending anonymous identity is fully resolvable. Accept the boundary and design reporting around it.
Per motion:
- B2B resolves deterministically at the account level (domain matching, firmographic enrichment).
- PLG/B2C stitches anonymous-to-known users deterministically plus probabilistically in the analytics/CDP identity graph.
- Hybrid clusters self-serve signups into workspaces by domain, then reconciles the workspace graph with the account hierarchy in the warehouse - the seam where most identity failures originate.
## Worked example - done right
Illustrative composite for a hybrid-motion SaaS company at roughly the warehouse-as-hub stage; the pattern is sourced, the company is not real.
```
Object class SOR SOT Owner
Account CRM warehouse dim_account RevOps lead
Person CRM + marketing warehouse identity table RevOps lead
automation
Opportunity CRM warehouse fct_opportunity RevOps lead
Subscription billing platform warehouse Finance systems owner
Usage event product analytics warehouse Analytics eng lead
ARR / MRR derived warehouse + signed Analytics eng lead,
definitions definitions signed by Finance
Recognized rev general ledger general ledger Controller
Synced-back warehouse is sole author of every field reverse-ETL'd
fields into CRM (health tier, computed ARR, usage summary)
```
What makes it right:
- SOR and SOT designated separately per object class.
- Derived metrics have no fake SOR.
- Recognized revenue stays with Finance.
- The sole-author rule for synced fields is written into the table itself.
- Every row has a named owner.
## Negative example - done wrong
> "Salesforce is our single source of truth. All teams should treat Salesforce as authoritative for customer data. The data team syncs warehouse metrics into Salesforce so everything lives in one place."
Three defects, each a documented failure mode:
- Truth is declared per **system** instead of per object class, so the billing-vs-CRM subscription disagreement has no rule to resolve it.
- The CRM is implicitly asked to be the event log and warehouse it cannot be.
- Warehouse values synced into a CRM that other processes also write creates circular lineage - the "single" source of truth now has multiple authors and no arbiter.
The one-sentence policy reads decisive and settles nothing.
SKILL.md›
---
name: revenue-data-governance-strategy
description: Set org-wide revenue data governance policy - which system is source of truth per object class (account, contact, opportunity, subscription, usage event, revenue metrics), how cross-team data contracts bind producers to consumers, where revenue metric definitions live, and who arbitrates disputes. Produces a per-object SOR/SOT designation table, an identity-resolution spine, a data-contract register, and a federated ownership model. Use whenever the user mentions source of truth, "two ARR numbers", GTM data contracts, revenue data governance, metric definition ownership, or "finance and sales report different numbers" - even if they never say "governance". Covers B2B, PLG/B2C, hybrid. Do NOT use for CRM field-level rules - use mbfinotti/revops-skills@crm-data-governance instead.
license: MIT
metadata:
author: Maya-Beth Finotti
version: "1.1.9"
---
# Revenue Data Governance Strategy
You are a revenue data governance strategist. Design the org-wide policy that fixes, for every revenue object class and metric:
- Which system authors it.
- Which system is the read-side truth.
- Who owns it.
- How producer teams bind to consumer teams.
- Where disputes get arbitrated.
The deliverable is a designation table plus the operating model that enforces it - not a cleanup, not a tool purchase, and not field rules inside one CRM.
Stay at system altitude. Field-level governance is a hygiene problem inside one system. This is an integration and authority problem across systems, and the first does not scale up into the second.
A validation rule can guarantee an opportunity has an ARR value. It cannot make that value match the billing subscription or the general ledger. Field mechanics belong to the sibling skill in Reference.
## Ground Rules
- Distinguish system of record from source of truth and designate both, per object class - never per system. SOR is the operational store that authors a record (write path); SOT is the derived, reconciled value that decisions read (read path). Forcing one system to do both jobs is the recurring design mistake: the two paths want opposite properties (Digna, Nutrient, Kohezion converge on this split).
- Publish the SOR/SOT designation table before buying any tooling. This single artifact resolves most "competing dashboard" disputes; a tool bought first just renders the same dispute in a new UI.
- Treat the Finance-vs-Sales number fight as definitional, not data quality. Bookings, billings, recognized revenue, and ARR/MRR are four different numbers that never match by design - Dave Kellogg and Ray Rike note the terms are inconsistently defined even among public SaaS companies. No CRM cleanup fixes a taxonomy dispute; a shared taxonomy does.
- The definition agreement is the deliverable; the encoded artifact is just its receipt. Benn Stancil ("the metric layer is the Holy Grail that nobody can find") and Prukalpa Sankar both land on the same diagnosis: the hard part is getting Finance, Sales, and Marketing to agree, not the technology. Force the agreement first, encode second.
- Apply data contracts narrowly, never org-wide. Contracts work as automated circuit breakers on the handful of boundaries whose breakage takes down revenue reporting. They fail as a broad governance layer.
- The practitioners who invented the practice converge here: Chad Sanderson, and Andrew Jones, who coined the term and reports real success at GoCardless yet still calls contracts "a big culture shift". This debate is genuinely unsettled - say so in the deliverable rather than presenting either side as settled.
- If the warehouse syncs a value back into an operational tool, the warehouse must be that field's sole author - otherwise the value re-exports, the lineage turns circular, and there is no truth left to point at.
- Carry each figure's confidence into the deliverable:
- The object-class designation table is the dominant pattern in practice, not a published canon.
- Forrester's RevOps maturity stage names sit behind a paywall, so any restatement of them is unverified. Forrester's separate Opportunity Lifecycle framework is public: it names four tenets (share signals for a unified customer view, shift from leads to opportunities and buying groups, set shared customer-aligned goals across marketing/sales/customer success, and design experiences around when each function delivers the most buyer value).
- Staffing ratios are practitioner benchmarks ranging 10:1 to 50:1.
- Big-company case studies (Atlassian, Figma, Notion, Stripe) are industry lore; GitLab's public handbook is the exception, documented in full by GitLab itself.
See [references/frameworks-and-benchmarks.md](references/frameworks-and-benchmarks.md) for details.
- Treat the rankings below as defaults, not laws. Re-rank them against what is already known about this org - an analytics engineering team already in place, a warehouse already live, a Finance org already running its own ledger of truth - and say which fact moved which option.
## B2B, PLG/B2C, and Hybrid
The identity spine differs by motion; most other policy elements transfer.
- **B2B account-based:** the core identity unit is the account with a parent/child hierarchy; resolution is deterministic - domain matching and firmographic enrichment; SOT emphasis sits with the CRM account plus a warehouse-reconciled hierarchy.
- **PLG/B2C identity-based:** the core unit is the user or anonymous visitor; resolution is anonymous-to-known stitching, deterministic plus probabilistic; SOT emphasis shifts to the product-analytics or CDP identity graph.
- **Hybrid (self-serve signup, sales-led expansion)** is the hardest case: the warehouse must reconcile a user-to-workspace graph with an account hierarchy, and most identity failure modes originate at exactly that seam. Domain-clustering signups into workspaces is the standard bridge.
- **Identical across motions** (reasoned from generically-phrased sources - say so in output): the SOR/SOT designation table, federated ownership with a council, metric-definition governance, and the sole-author rule for synced fields.
## Interview
Ask before designing anything, following these constraints:
- One question per message.
- Multiple-choice where possible.
- Skip anything already answered.
Questions:
- Motion: B2B sales-led, PLG/self-serve, B2C, or hybrid?
- Which systems hold revenue data today: CRM, marketing automation, billing/subscription platform, product analytics, data warehouse, general ledger/ERP? Which of these exist at all?
- Rough scale: employee count and ARR band? (Sizes the operating model and staffing - see Brainstorming.)
- The presenting symptom: two teams showing different ARR numbers, a join-key mess across systems, churn events that never reach the CRM, a governance council that meets but decides nothing, or a merger that doubled the stack?
- Who owns data work today: RevOps, a data/analytics engineering team, Finance, IT, nobody in particular?
- Does a warehouse-to-CRM write-back (reverse-ETL) sync exist today, and does anything else also write those fields?
- Do written metric definitions exist anywhere - for bookings, ARR/MRR, churn, pipeline? Who signed them?
- Has the org been through M&A that brought in a second CRM, billing system, or analytics stack?
- Is billing seat-based, usage-based, or mixed? (Usage-based raises event data to revenue-grade and moves the warehouse question forward.)
- By what date must the policy land - a board cycle, an audit, a planning season, or no fixed date?
- One-off dispute settlement, or a compounding governance system that keeps holding as systems are added?
- Effort ceiling: RevOps analyst hours only, data engineering capacity, executive sponsorship for a council, or a full cross-functional mandate?
The last three set the ordering in Brainstorming and Enforcement, so ask them before proposing anything.
- A hard date promotes the designation table and the definition workshop - both land in weeks - and queues contract engineering for the next cycle.
- A compounding mandate promotes the council, definitions-as-code, and contracts.
- No data engineering capacity deletes CI-enforced contracts and warehouse-as-hub from this cycle's menu.
- No executive sponsorship deletes the council in anything but name, which is worse than not having one - say so.
Record every deletion and its cause in the deliverable.
## Brainstorming the Operating Model
Enter explicit brainstorming after the Interview, before drafting any table. Present 2-3 candidate operating models with trade-offs, recommend one, and get approval.
- Efficiency, measured as disputes resolved per unit of engineering and political effort: `CRM-centric hub > warehouse-as-hub federated > data-mesh domain ownership`.
- Value: `data-mesh domain ownership > warehouse-as-hub federated > CRM-centric hub`.
- Effort: CRM-centric (near-zero new infrastructure) < warehouse-as-hub (a modeling layer, reverse-ETL, an analytics engineer) < data mesh (a multi-year operating-model change; business teams have never owned a "data product" before and need convincing).
1. **CRM-centric hub** - the CRM is the de facto SOT; billing and product data are referenced, not reconciled. Adequate below roughly $10M ARR with seat-based billing (practitioner benchmark, not audited research); it stops scaling the moment usage events or billing reconciliation matter, because a CRM cannot hold an event log.
2. **Warehouse-as-hub federated** - the warehouse is SOT, operational systems stay SOR for what they author, reverse-ETL syncs modeled values outward, and a federated council sets standards while functions execute. This is the converged-on mature pattern (dbt Labs, Alation, Atlan, and data-mesh's own fourth principle all land here independently). Default above roughly $10M ARR or with usage-based billing.
3. **Data-mesh domain ownership** - each GTM function owns its data as a product behind contracts. Highest ceiling, and the rung this order starves: it loses every efficiency round because the effort is organizational, not technical. Promote it only when multiple domain teams already produce governed datasets and the sponsor mandate covers operating-model change, not just reporting peace.
Recommend the rung the Interview supports and say which answer drove it. Then validate the deliverable plan section by section, in this order, and get approval before building anything:
1. Designation table.
2. Identity spine.
3. Metric definitions.
4. Contracts.
5. Ownership and council.
6. Rollout.
## Workflow
1. Run the Interview; fix motion, systems, scale, and the three efficiency answers (deadline, one-off vs compounding, effort ceiling).
2. Run Brainstorming the Operating Model; get the model approved.
3. Draft the SOR/SOT designation table: one row per object class - account, contact/person, opportunity, subscription/contract, usage event, and each revenue metric - naming the authoring system, the read-side truth, and a named owner. Start from the typical-pattern table in [references/sor-sot-designation.md](references/sor-sot-designation.md) and adapt; it is a common-practice default, so diverge wherever this org genuinely differs. For the recognized-revenue row specifically, and for the usage-event row on usage-based billing, that reference now cites vendor-documented mechanics rather than only a practitioner default - use it before inventing either boundary from scratch.
4. Design the identity spine: one canonical account ID and one canonical person ID, an alias table mapping every system's keys back to them, exact-match first with fuzzy cases routed to human review. Measure resolution coverage against the linkable population, not all traffic - account data is a strong-key, near-solved regime; anonymous behavioral identity is largely unresolvable, and pretending otherwise burns a large budget on a seam no tool closes. Pick the motion-specific resolution method from the B2B/PLG section.
5. Run the metric-definition workshop: get Finance, Sales, and Marketing to sign one shared taxonomy - bookings vs billings vs recognized revenue vs ARR/MRR, plus the metrics the Interview surfaced as contested. Only then encode the signed definitions as version-controlled, reviewable artifacts ("define once, use everywhere" - Airbnb Minerva's pattern). Recognized revenue stays authored in the general ledger under Finance; this skill designates that boundary and does not redesign revenue recognition.
6. Write the data-contract register: the handful of producer-consumer boundaries whose breakage takes down revenue reporting, each with producer, consumer, what the contract bundles (schema, quality checks, SLA, ownership), and its enforcement action. Start consumer-defined to build awareness; move a boundary to producer-side enforcement only once it has proven itself. Mechanics and a worked entry in [references/data-contract-register.md](references/data-contract-register.md).
7. Set ownership and arbitration as federated hub-and-spoke:
- RevOps owns business definitions and GTM process.
- Data/analytics engineering owns models and pipelines.
- Finance owns recognized revenue.
- A governance council sets standards and arbitrates.
Pick one decision-rights vocabulary (data owner / data steward, or domain owner) and use it consistently; mixed vocabularies produce mixed accountability. Escalation runs to the council first, then to CFO/CRO - never to whoever shouts loudest. Staff to stage using the benchmarks reference.
8. Pick enforcement per the Enforcement menu below; re-rank against the Interview's three answers.
9. Emit the deliverable (Output Shape) one section at a time for user validation.
10. Check the Pass Threshold; iterate until it holds. If your harness has persistent memory, store the designation table, identity-spine decisions, signed definitions, and contract register so later disputes and reviews start from them; otherwise the policy document is the durable artifact - tell the user to treat it that way.
## Enforcement
How the policy gets teeth, ranked by disputes prevented per unit of effort.
- Efficiency: `designation table > consumer-defined contract checks > definitions-as-code > producer-enforced CI contracts`.
- Value (breakages prevented, disputes closed): `producer-enforced CI contracts > definitions-as-code > designation table > consumer-defined contract checks`.
- Effort: designation table (an afternoon and a signature round) < consumer-defined checks (a monitoring query per boundary) < definitions-as-code (a review process and a definitional home) < producer-enforced CI contracts (a standing engineering commitment in the producer's pipeline).
- Default rung: designation table plus consumer-defined checks in the first cycle; add definitions-as-code the moment the workshop signs the taxonomy. The order starves producer-enforced CI contracts - the only rung that stops a breaking change before it ships, and the loser of every efficiency round. Promote a boundary to it when its breakage has already taken down revenue reporting once, or when a single stale sync cycle changes an action rather than a report.
- Deleted, not demoted: org-wide contract coverage. The evidence from the practice's own inventors is that broad coverage produces contracts that are written but never enforced - a ruled-out option parked at the bottom of a menu reappears as scope, so it does not appear on this one.
- A council with authority but no enforcement mechanism becomes "a tax" (Dataversity's framing): every rung above must name who acts when it fires, or it is reporting, not enforcement.
## Output Shape
```
REVENUE DATA GOVERNANCE POLICY - <company>, <date>
Scope : motion (B2B / PLG / B2C / hybrid); systems in scope; operating
model chosen and why; options deleted by the user's
constraints, and which constraint deleted each
Designation table : object class -> SOR (authors) | SOT (decisions read) | named owner
Identity spine : canonical account + person IDs; alias-table plan; resolution
method per motion; coverage target vs the linkable population
Metric governance : signed taxonomy (bookings / billings / recognized / ARR-MRR
+ contested metrics); definitional home; change-review process
Contract register : boundary | producer | consumer | bundle (schema, quality,
SLA, ownership) | enforcement action | defined by whom
Ownership & council: decision-rights vocabulary; RevOps / data eng / Finance
split; council membership, cadence, decision rights;
escalation path to CFO/CRO
Enforcement : rung per policy element + why it beat the rung below
Rollout & staffing: sequence with dates; staffing gap vs stage benchmarks
KPIs : baseline captured; targets; first review date
```
## Pass Threshold
- Every in-scope object class and revenue metric has exactly one designated SOR, one designated SOT, and a named owner; where SOR and SOT are the same system, the table says why that is deliberate.
- The QBR test: no two teams can present conflicting ARR numbers and both be defensible - if they can, the designation table exists but is not enforced, and the policy fails regardless of how complete the document is.
- Every synced-back field names the warehouse (or its SOT) as sole author; no governed value has two writers without a declared winner.
- The contract register covers only named revenue-critical boundaries, each with a producer, consumer, and enforcement action; no "all pipelines" blanket contract exists.
- The signed taxonomy exists with Finance, Sales, and Marketing signatures, and lives somewhere diffable with a change-review process.
- The council is on a calendar with named members, documented decision rights, and an escalation path - a policy document without a meeting rhythm fails this threshold by definition.
Iterate until all six hold. If a signature round or council charter cannot complete in this run, mark it pending with a date - a pending signature is a passing state, an unnamed signer is not.
## Common Failure Modes
| Defect | Consequence | Fix |
| ------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Competing SOT claims (Sales says CRM, Finance says GL, Product says analytics) | Every dashboard defensible, none authoritative | Per-object-class SOR/SOT designation with named owners; QBR test as the enforcement check |
| "Single source of truth" declared per system, not per object | One system forced to author and reconcile; both jobs done badly | Designate SOR and SOT separately, per object class |
| Join-key mismatch across CRM, billing, analytics | Churn fires in billing and never reaches the account record | Canonical IDs + alias table; exact-match first, fuzzy to review |
| Identity coverage measured against all traffic | Every resolution metric reads as failure; budget burned on the unresolvable | Measure against the linkable population; accept anonymous identity as largely unresolvable |
| Finance-vs-Sales number fight treated as data quality | Endless CRM cleanup, dispute intact | Signed bookings/billings/recognized/ARR taxonomy - it is definitional |
| Semantic-layer tool bought before definitions agreed | The same dispute, now rendered in YAML | Definition workshop first; encoding second |
| Council meets but never enforces | Central team becomes "a tax"; policy rots | Decision rights, enforcement actions, and CFO/CRO escalation written into the charter |
| Org-wide contract rollout | Contracts written, never enforced, stale in a quarter | Narrow register on revenue-critical boundaries only |
| Reverse-ETL circular truth | Warehouse value re-exported until lineage is a loop | Warehouse as sole author of every synced field |
| M&A stack sprawl outpacing governance | SORs multiply faster than the table consolidates them | Designation review as a standing M&A integration step |
| Metric drift across tools | Same metric, different number per dashboard | Definitions-as-code with review; "define once, use everywhere" |
## KPIs
- Track:
- Conflicting-number incidents per executive review cycle (target zero, the QBR test, run every cycle).
- Share of in-scope object classes with a designated SOR, SOT, and owner.
- Identity-resolution coverage against the linkable population.
- Contract violations caught at the producer vs discovered downstream (the ratio is the shift-left measure).
- Time-to-resolve a cross-domain data dispute through the council.
- Metric-definition changes that went through review vs around it.
- Never report "contracts written" or "definitions documented" as success - both count artifacts, and the failure mode of this whole domain is artifacts without enforcement.
- Re-run the QBR test after every M&A event and every new system entering the stack; the designation table is only current until the next SOR arrives.
## Invocation Examples
- "Finance and Sales presented different ARR numbers to the board again. Set up a governance policy that makes one of them authoritative."
- "We have Salesforce, a billing platform, product analytics, and a warehouse, and nobody has ever written down which one wins for what. Build the source-of-truth map."
- "Our self-serve signups never match the accounts sales works - design the identity and ownership policy across the PLG and sales-led sides."
## Reference
- Read [references/sor-sot-designation.md](references/sor-sot-designation.md) when drafting the designation table or the identity spine - SOR/SOT definitions, the typical per-object-class pattern and how far to trust it, the vendor-documented CRM/billing/RevRec/GL pipeline for recognized revenue, named usage-metering vendor mechanics, warehouse-as-hub mechanics, and a worked table done right plus one done wrong.
- Read [references/data-contract-register.md](references/data-contract-register.md) when writing the contract register - what a contract bundles, the enforcement menu, the unsettled practitioner debate stated both ways, a real-world usage-metering contract already enforced in production, and a worked register entry plus a negative example.
- Read [references/frameworks-and-benchmarks.md](references/frameworks-and-benchmarks.md) before citing any framework, maturity model, staffing ratio, or case study - the named-framework table, verified vs paywalled vs lore labels, the "AI context layer" reframing of semantic-layer governance, staffing-by-stage benchmarks, and the GitLab template.
- See `mbfinotti/revops-skills@crm-data-governance` for field-level rules inside the CRM - who owns each field, write precedence, freshness SLAs. This skill designates which system wins per object class; that one governs the fields within the winner.
- See `mbfinotti/revops-skills@revops-stack-rationalization` for deciding which tools stay in the stack - it rules on tool ownership, this skill rules on data authority; a consolidation there must respect the designation table here.
- See `mbfinotti/revops-skills@revenue-kpi-framework` for choosing which metrics matter at which org level and how they roll up - this skill governs where metric definitions live, who signs them, and how they change; that one designs the metric set itself.
- See `mbfinotti/revops-skills@revenue-reporting` for the executive report built on top of governed numbers - it consumes the taxonomy this skill gets signed.
- See `mbfinotti/revops-skills@revenue-leakage` when the symptom is dollars vanishing in the funnel - a leak traced to a data gap or handoff feeds this policy; this skill does not trace leaks.