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
}
]
}
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.