Finds where one metric name means three different things
The most damaging failure in business intelligence is not a broken pipeline — those get noticed and fixed. It is that "active customer" means one thing in the finance dashboard, another in the product dashboard and a third in the board pack, all labelled the same way.
This happens without anyone doing anything wrong. Each dashboard was built by a different person for a different question, and each definition was reasonable for that question. Nobody wrote it down because at the time it was obvious. Two years later the person has gone and the definition lives only in the SQL.
The cost lands in meetings. Two teams argue for an hour about whose number is right when both are correct and measuring different things. The more expensive version is when nobody notices, and a decision is taken on a number that does not mean what the room thinks it means.
Governance tools sell catalogues you have to populate, which is why they end up half-populated. This does the opposite: it reads the queries that already exist, extracts what each metric actually computes, and reports where the same name means different things and where different names mean the same thing.
It changes no query and publishes no definition. Which definition is correct is a business decision, and it belongs to the people who own the metric.
And start arguing about the decision.
Which is the expensive version of this problem.
Rather than one nobody populates.
Not a catalogue somebody was supposed to fill in. The real definition lives in the query, and only there.
Each definition was reasonable for the question it was built for. None of them was written down.
Duplicate work maintained separately, drifting apart quietly.
A filter, a date basis, an inclusion rule. It says exactly which clause makes two numbers disagree.
So the meeting is prepared rather than derailed.
Which one is correct is a business decision owned by the people who own the metric.
Why Data & Business Intelligence in particular. 'Active customer' means three different things in three dashboards, all labelled the same. Each was reasonable for its own question and nobody wrote it down, so the definition left when its author did.
Runs unattended
Started by you or by an event, and it finishes on its own. Nothing waits for someone to be at a desk.
The same standard every time
The two-hundredth item is held to the bar the first one was. Consistency is the part people cannot sustain.
It cannot act on its own
Metric Definition Auditor has no path to sending, spending or committing. That limit is why its output is safe to act on.
This agent runs server-side through the PROMIVO runtime. Each run is logged step by step and every tool call is permission-checked before it executes.
Read-only by design. This agent has no path to sending, spending, publishing or committing anything. Where that limit is the product, removing it would remove the reason to trust the output.
Demo dataIllustrative sample output, abridged.
{
"metrics": []
}{
"noOwner": [
"Four metrics feeding the board pack have no recorded owner, so nobody can reconcile them."
],
"escalate": true,
"disclaimer": "A reading of the definitions supplied. No query, model or dashboard has been changed, nothing was written to any system, no definition is stated to be correct or canonical, and equivalences marked apparent were not verified against data.",
"escalationReason": "A metric in the board pack is computed three different ways, its revenue metric contains an unexplained hard-coded exclusion, and four board metrics have no owner.",
"dateBasisConflicts": [
"Revenue is recognised by invoice date in three reports and by service period in two. Same table, same filters, different date basis — invisible in a meeting and it moves the number every quarter end."
],
"hardCodedOrAdjusted": [
"The revenue metric excludes two named account identifiers in the WHERE clause. No comment explains why, and no reader of the dashboard can see it."
],
"reportsThatWillDisagree": [
"The board pack and the finance dashboard will report different active customer counts for the same month. Both are correct for their own definition."
],
"sameNameDifferentMeaning": [
{
"name": "Active customers",
"usedIn": [
"Finance dashboard",
"Product dashboard",
"Monthly board pack"
],
"variants": 3,
"differences": [
"Finance dashboard: any account with an invoice in the period, regardless of usage.",
"Product dashboard: any account with a login in the last 30 days, regardless of billing.",
"Board pack: any account with a live contract on the last day of the period."
],
"likelyDivergence": "The three would differ most in a month with high churn and slow invoicing — exactly the month the number gets scrutinised."
}
],
"differentNamesSameMeaning": [
"\"Monthly recurring revenue\" and \"Contracted monthly value\" compute identically. Two queries, two owners, maintained separately and already drifting."
],
"appearsEquivalentUnverified": [
"Two churn definitions appear to compute the same thing. They were not run against data, so this is reported as apparent rather than confirmed."
]
}No integrations required.
Whether the numbers agree with the operational dashboards.
What the definitions currently are, before deciding what they should be.
The definitions that left with the person who wrote them.
Exactly which clause makes the two disagree.
$349/month
Billed monthly through your PROMIVO subscription. Cancel at any time.
Runs consume your plan allowance for agent executions and tokens. See plan limits.
No. Both are usually right for their own question. Choosing the canonical one is a business decision, and a tool making it silently is how the wrong one wins.
No. It reads them. It has no write access to any warehouse, model or dashboard.
No — the absence of one is the reason this exists. It works from the query definitions themselves, which is the only place the truth is stored.
No reviews yet. Reviews open once customers have run this agent.
Tell us what to change and our team will scope a customised version for your business.
Customize this agent