A centralized repository of business terms, definitions, and data elements that helps everyone speak the same language. Define what "Customer," "Revenue," or "Active User" means in your organization with standardized definitions that eliminate confusion across teams.
A comprehensive repository of technical metadata that shows exactly where each data element lives across your systems. Map database tables, columns, APIs, and files to understand the physical locations and technical structures of your data assets.
Interactive visualizations showing how data flows through your organization. Trace data from source systems through transformations to final destinations. Understand dependencies, track changes, perform impact analysis, and ensure data quality throughout the pipeline.
Understand the organizational context of your data. See which business units, departments, and teams create, manage, and consume each data element. Map data stewards, owners, and consumers to establish clear accountability and facilitate collaboration. Understand the purpose for which data is needed and being used for.
Link data elements to business functions and capabilities they support. Understand why specific data exists, which processes depend on it, and how it drives business outcomes. Map data to capabilities like "Customer Acquisition," "Financial Reporting," or "Risk Management."
Logical collections of data elements organized by business process, function, or operational need. Data Assets like "Order-to-Cash," "Customer 360," or "Regulatory Compliance" that group related data elements and show exactly which processes depend on specific data.
Ask anything about your organization's data governance catalog in plain language — no SQL, no filters, no digging through menus. Find data stewards, discover sensitive elements, check approval status, and explore data relationships through natural conversation. Powered by Claude AI and scoped exclusively to your organization's data. Available on the Professional plan.
From sign-up to a fully governed data environment in seven steps.
Step 1
Request Access
Fill in your name, org, and email — you'll see a confirmation screen immediately.
Step 2
Get Approved
We typically respond within one business day with a secure link to continue.
Step 3
Subscribe — 14 Days Free
Choose Basic or Professional. Your 14-day free trial starts immediately — no charge until it ends.
Step 4
Set Password & Log In
A password email arrives right after subscribing. Click the link and log in.
Step 5
Set Up Your Organization
The onboarding wizard pre-fills your industry context — Business Units, Domains, Systems, and more — so you're not starting from scratch.
Step 6
Define & Map Your Data
Document terms in the Business Glossary, map columns in the Data Dictionary, and trace end-to-end Data Lineage.
Step 7
Collaborate with Your Team
Invite members as Administrator, Owner, or Viewer and route changes through the built-in approval workflow.
The hardest part of data governance isn't understanding why it matters. It's keeping the catalog current without turning it into a full-time second job. Here's how Datamentalist handles that.
"We know we need this. But someone has to maintain it, and that's the part nobody wants."
That's the most common thing we hear. It's a fair concern — and it's the exact problem Datamentalist is designed to solve. The goal isn't better documentation discipline. The goal is eliminating the second step: making governance metadata a byproduct of work that's already happening, not a separate task that competes with it.
The mechanical work is streamlined while the judgment stays human with the technical context already filled in.
For the 3-person IR office at a community college, templates and DDL import get the baseline in days. For the data engineering team that deploys continuously, deeper integrations make governance a zero-effort byproduct of work already happening. Every organization can move further right on the spectrum — at their own pace, without a big-bang implementation.
Start your free trial — get the baseline in week oneSelect your industry to see how data governance plays out in real scenarios.
Real people. Real roles. Real outcomes — the data conversations happening in higher ed offices right now.
The problem: The provost wants tuition revenue reconciled with enrollment figures — but Maria knows student records, not GL codes. She'd normally wait two days for a Bursar's reply and spend an afternoon decoding a context-free spreadsheet.
With Datamentalist: She searches "tuition revenue," finds the Bursar's governed definition, sees the exact table, column, valid values, and source system. Reconciliation done in an afternoon. No email sent.
The problem: SACSCOC accreditation requires documented data provenance for every key metric. Her predecessor spent three months writing a 40-page narrative from memory — half of it outdated before it shipped.
With Datamentalist: She opens the context matrix, filters by "Accreditation & Compliance," and exports. When a follow-up question arrives during the review, the answer takes thirty seconds.
Commercial teams sit at the intersection of IQVIA, Veeva, CDISC, and MedDRA data. Here's what happens when definitions are governed — and when they aren't.
The problem: The weekly flash report shows different prescription numbers than what field reps see in Veeva CRM — territory NRx is 15% higher in the CRM. Nobody documented which NRx definition feeds which report: IQVIA's counts first-time fills only, while the CRM includes competitive switches too.
With Datamentalist: Rachel finds three governed NRx terms — one per methodology — each linked to its source system. She proposes a single "Official NRx" via the approval workflow. No more conflicting numbers at the Monday sales call.
The problem: Open Payments (Sunshine Act) filing requires reconciling HCP transfers of value across four systems — events, CRM, accounts payable, and sample accountability — each identifying the same physician with a different ID: NPI, Veeva VID, tax ID, and internal code.
With Datamentalist: He finds the governed HCP Master ID with its full crosswalk to NPI, VID, OneKey, and legacy codes. $2M in speaker fees correctly attributed to 47 individuals instead of 63 fragmented records.
Risk, compliance, and analytics teams share the same data warehouse but rarely share the same definitions — until regulators ask why the numbers don't match.
The problem: CCAR stress testing requires a single "net credit exposure" figure. Treasury defines it as gross exposure minus collateral. Credit Risk defines it after netting agreements but before collateral. Market Risk defines it on a delta-adjusted basis. The business heads are arguing in the final review meeting.
With Datamentalist: Sandra finds all three exposure definitions catalogued by context, routes a proposed "Official CCAR Net Exposure" through the approval workflow. The next Fed submission goes out with a single, signed-off number and a documented audit trail.
The problem: Suspicious Activity Report filings require identifying the "customer" behind a transaction. In retail banking it's the account holder. In wealth management it's the beneficial owner. In commercial banking it's the legal entity. FinCEN expects consistency. The bank's three systems give three different answers.
With Datamentalist: Thomas maps the three "Customer" definitions with crosswalk tables resolving them into a unified AML subject entity. When the examiner asks how the bank identifies customers across channels, there's a governed answer ready.
Clinical, financial, and operational teams each have a version of the truth. When a denial is a denial depends entirely on who's counting — and why.
The problem: The CFO sees a 6% denial rate. The billing team reports 9%. Revenue Cycle tells the board 11%. All three pull from the same system — one counts initial denials, one counts worked denials, one includes late charges. The VP has stopped referencing any of the three numbers in meetings.
With Datamentalist: Angela documents all three denial rate definitions — Initial, Worked, and Gross — each tagged to its business context. A single "Official Denial Rate" is routed through approval. All three teams now reference the same number and footnote where their operational view differs.
The problem: The health system is migrating EHR platforms. "Encounter" in the old system means a billed visit. In the new system it means any clinical interaction including phone and portal messages. 18 years of quality metrics are built on the old definition. If the migration team uses the new definition, every historical benchmark breaks.
With Datamentalist: Dr. Reyes catalogs both "Encounter" definitions before migration begins. The migration team writes transformation logic against the documented difference. Post-go-live, historical comparisons hold.
Marketing sees one conversion rate. Finance sees another. When every team has its own version of the metric, nobody can agree on what to do next.
The problem: Marketing reports a 3.2% conversion rate; Finance reports 2.1%. Both are right by their own definition — Marketing divides completed orders by sessions, Finance divides by unique visitors and excludes same-day returns. The CMO and CFO are presenting different numbers to the same board.
With Datamentalist: Olivia documents both definitions — "Session Conversion Rate" for campaign optimization and "Net Order Conversion Rate" for revenue planning — each approved and tagged to its business context. The board deck shows both metrics with a footnote. The argument stops.
The problem: "Out of stock" means something different in every system. The warehouse triggers replenishment at zero on-hand. The POS flags a SKU after 24 hours of no sales. Merchandising marks it OOS when the website hides the product. Three systems, three triggers — causing double-orders and missed replenishment windows simultaneously.
With Datamentalist: Carlos documents all three OOS definitions with system, trigger logic, and business owner. The team builds a unified OOS signal chaining all three. Vendor over-orders drop 40% in the first quarter.
Shop floor, ERP, and quality systems rarely agree on what a defect is or how yield is calculated. That disagreement shows up in scrap, rework, and missed delivery windows.
The problem: The Six Sigma team reports a defect rate of 2.3% from the QMS. The production floor reports 4.1% from MES first-pass yield. Customer returns reports 0.8% from warranty claims. All three go to the plant manager in the same weekly report. She has stopped believing any of them.
With Datamentalist: Henrik catalogs all three — DPU, First-Pass Yield, and Field Defect Rate — with formulas, data sources, and context. The plant manager now presents one "Production Defect Rate" for operations and a separate "Field Quality Rate" for customer-facing reporting. The Six Sigma project finally has a baseline everyone agrees on.
The problem: SAP calls it a "Production Order." The MES calls it a "Work Order." The quality system calls it a "Job Ticket." All three refer to the same manufacturing execution unit — but no integration documentation records the mapping. When a weld failure triggers a quality hold in the MES, the SAP order continues and the customer shipment goes out anyway.
With Datamentalist: Ingrid documents the three-way crosswalk with identifier fields, status mappings, and the integration hold propagation points. The next quality event is caught at the SAP goods movement step.
Product, sales, and engineering each instrument the product differently. When "active user" means something different in every tool, the investor deck and the customer health score tell incompatible stories.
The problem: Product defines "active user" as a login within 7 days. Sales uses 30 days for renewal health scores. Customer Success uses "any login ever." The investor KPI dashboard uses a number nobody can reproduce because the original analyst left. The board asks which number is right. The CEO doesn't know.
With Datamentalist: Mei documents "Weekly Active User," "Monthly Engagement Score," and "Investor MAU" as three distinct approved definitions — each with SQL logic, the tool it feeds, and the business owner. A new analyst can reproduce any of them on day one. The CEO stops getting three different answers.
The problem: Three microservices all emit an "order_placed" event. Six months after the platform was split, the schema drifted: one service emits the price pre-discount, one post-discount, one post-discount and post-tax. The LTV prediction model is training on all three mixed together. Nobody flagged the drift because nobody owns the event contract.
With Datamentalist: Jordan catalogs "order_placed" as a governed business event with its canonical schema and each service team listed as a steward. The next schema change has to go through an approval workflow before it hits the data warehouse. The LTV model retrains on clean data.
Network operations, customer care, and regulatory compliance measure the same events from different vantage points. When an outage is an outage — and who counts it — can mean a regulatory fine.
The problem: The NOC defines an outage as any core network element failure affecting 1,000+ customers. Customer Care defines it as a surge of 200+ inbound tickets per hour. Regulatory Affairs defines it as any SLA breach per CPUC filing thresholds. A major event produces three different incident counts and nobody knows which one goes to the regulator.
With Datamentalist: Farrukh documents all three definitions with triggering logic, threshold, and reporting context. The regulatory definition is tagged as the official one for CPUC filings. The next major event, communications use a single governing definition.
The problem: Finance reports churn at 2.1% (accounts cancelled in billing). Network analytics reports 5.8% (zero usage for 90 days). The CRM team reports 1.6% (explicit cancellations). All three land in the board pack for the same quarter. The board chair asks which one is used for the subscriber outlook. Nobody answers confidently.
With Datamentalist: Nadia documents all three churn definitions with cohort logic, data source, and business owner. The CFO approves Billing Churn as the investor metric. The next earnings call has one churn number with a clean definition.
Grid operations, capital planning, and regulatory compliance depend on the same data — but "peak demand" and "emissions factor" rarely carry the same definition from one team to the next.
The problem: Three teams present "peak demand" to the capital planning committee in the same slide deck — Dispatch uses instantaneous MW, Transmission Planning uses seasonal projections, FERC Reporting uses the annual coincident peak per tariff. The committee approves investment against the Dispatch number. The discrepancy surfaces 18 months later during a rate case.
With Datamentalist: Eric documents all three definitions with measurement methodology, time basis, and governing context. Capital planning explicitly selects the transmission planning definition, with a footnote linking to the FERC tariff definition for rate filings. The next rate case documentation is already written.
The problem: SEC climate disclosure requires a single auditable CO2e methodology across all assets. The upstream division uses EPA factors, midstream uses IPCC region-specific factors from a 2019 study, and owned fleet uses vendor estimates not updated in three years. The auditors flag four separate methodologies in one table — six weeks before the filing deadline.
With Datamentalist: Priscilla documents the approved CO2e factor and tags it as the enterprise standard for SEC reporting. Every business unit that deviates is flagged in the context matrix. Within two weeks, all three divisions align to the governed methodology. The auditors sign off without a material finding.
Health Cloud brings together patients, members, providers, and care programs — but when each team uses a different Salesforce object as their source of truth, the platform creates governance problems as fast as it solves operational ones.
The problem: Care coordinators use the "Patient" custom object. Billing uses the "Member" record. Network operations tracks the same individual as a "Contact." All three exist for the same person, none are consistently deduplicated, and consent preferences on the Patient object don't flow to the Member record — creating a HIPAA exposure every time billing calls a patient who opted out.
With Datamentalist: Veronica documents all three representations with master record rules, deduplication logic, and consent field mappings. IT implements a consent sync flow. Compliance signs off on the field-level mapping before the next audit cycle.
The problem: Health Cloud tracks care gap closure through custom fields populated by care coordinators. The quality team's HEDIS measure uses claims data from the clinical warehouse, which only updates monthly. Both go to the same regulator for the same measure — and they never match.
With Datamentalist: Darnell documents two distinct definitions — the Health Cloud operational definition and the HEDIS administrative definition — with data source, update frequency, and regulatory context. Compliance submits the HEDIS definition; Care Management uses the Health Cloud definition for operations. The discrepancy is explainable, not a finding.
Some data governance problems aren't industry-specific — they happen in every organisation that uses data to make decisions.
The problem: Patricia inherited a 400-column data warehouse, four business glossaries in SharePoint that contradict each other, and a quarterly board report that three analysts produce using three different SQL queries — and nobody can explain why the numbers are always slightly different. The CDO hired her to "fix data governance."
With Datamentalist: She starts with the five most-argued terms — "Customer," "Revenue," "Active Account," "Churned," "Net Retention" — and works with each business owner through the approval workflow. Within 60 days, the board report has one set of numbers. Within 90 days, new analysts onboard without scheduling a meeting to ask what a field means.
The problem: Leon was hired to make the company "more data-driven." His first week, he finds six dashboards each showing a slightly different NPS, revenue, and customer count. The answer to "why do the numbers differ" is always "that's how we've always done it." The CEO wants a single analytics dashboard by end of quarter. Leon can't build it until he knows which definition is the right one.
With Datamentalist: Leon runs a two-week definition sprint — one metric per meeting, document the variants, vote on the official definition, route through approval. Within 30 days, the ten most-reported metrics have a governed definition with the business owner's name on it. The new dashboard is built against those definitions.
These scenarios are illustrative examples based on general knowledge of each industry and publicly available information. They are not drawn from specific customer engagements or proprietary domain expertise. Your organization's data challenges and terminology will vary — these stories are starting points, not prescriptions.
Subscribing — what to expect
By proceeding you agree to our Terms of Service.