What a Data Guardrail Actually Looks Like

Gohvio · 2026-06-30

The guessing game nobody admits to playing

Picture two teams, same quarter: Marketing says 400 MQLs. Sales says 120. Both pulled the number this morning. Neither is lying.

A data guardrail is the written definition of a term your teams share, plus the flag that appears when a record does not meet it. That is the whole idea. Not a gate that refuses to save, not a robot that silently corrects the record. A definition, recorded where everyone can read it, and visibility when the data disagrees with it.

The 400 and the 120 both exist because nobody wrote down which evidence counts as qualified. So each team answered it privately, kept answering it, and built a quarter of reporting on their own answer. That is the guessing game. It is played in silence, and the silence is the expensive part.

The disagreement is not the bug

Here is the part most data quality advice gets backwards.

When Finance and Marketing define "customer" differently, that is not an error to be corrected. Finance counts a customer when the first invoice clears. Marketing counts one when a closed-won deal was marketing originated. Sales counts every closed-won deal. Those are three different jobs, so they are three defensible definitions, and flattening them into one would make at least two teams report a number that does not describe their work.

The failure is not that the definitions differ. The failure is that nobody wrote them down, so nobody knows they differ, and three numbers go into one board deck as though they measure the same thing.

So the goal is not agreement. The goal is memorialising: capture what each team means, keep every version side by side, and make the difference visible instead of letting it be discovered in a meeting.

What that looks like when it is built

A guardrail in Gohvio has a term attached to it, and a department. When two rules claim the same term with different definitions and different owners, Gohvio records a conflict and describes it in plain English:

"Finance and Marketing and Sales define 'Customer' differently. No source-of-truth owner is set. Gohvio will not pick a side - assign an owner or align the definitions."

Both definitions stay. Neither is disabled, overridden or quietly merged. You can name one department the source of truth for a contested term, and when you do, the others do not disappear -- they stay visible as deltas against the owner's definition. The conflict just changes status from unresolved to owned.

Two of these are already written for you. Load the Sales, Marketing and Finance playbooks, and Customer and ARR arrive already carrying competing definitions, ready to compare:

• Customer. Sales: any closed-won deal. Marketing: closed-won and marketing originated, which is narrower. Finance: not a customer until the first invoice is paid, which is stricter than both.
• ARR. Sales books it at signature. Finance recognises it on cash. Same contract, two numbers, both correct in their own ledger.

A definition cannot fail

This is a small design decision that changes how the whole thing feels to use.

A guardrail that says "close date must not be in the past" can be violated, and a violation is a defect worth a red flag. A guardrail that says "a customer is a closed-won deal where the first invoice cleared" cannot be violated. It is a boundary, not a test. Rows that match it are the members of a set, and the count is an answer, not a problem.

So a rule saved as a definition is never flagged as an error in Gohvio. The strongest thing it can say is "here is what matches", and nothing louder than that would be honest. A tool that marks a team's own definition as a defect is a tool that team stops opening.

What it catches while you are writing them down

Two examples, out of several:

Your document contradicts itself. Upload a policy document saying close dates must be in the future in one paragraph and allowing backdated deals in another, and you get: "Your document says two different things about close date. Saving both means the second one silently wins on every row they both touch."

Your new rule contradicts one you already have. "Your existing rule has been running and its numbers are already in your score. Saving this one changes what those numbers mean."

None of them stop you from saving. You know your business. The challenge is there so the decision is made on purpose rather than by accident, not to win the argument.

What it does not do

Worth saying plainly, because most tools in this category imply otherwise.

It does not block anything. Gohvio surfaces findings and points to the records behind them. It does not stop a save, edit your records, or write back to your CRM. Gohvio never issues a write call. With HubSpot it requests read-only scopes; Salesforce has no read-only API scope, so it requests the minimum Salesforce offers and enforces read-only in its own code. Blocking a record requires certainty the record is wrong, and on a definition disagreement nobody has that certainty, because the argument is about what the word means. There is a whole post on that choice: Why We Surface, Not Silently Fix. If you want Salesforce itself to enforce read-only, connect with a Salesforce user whose profile has read-only access.

Duplicate detection is exact, not fuzzy. It matches on the whole normalised email address, the normalised company name, or the domain. No similarity percentage, no fuzzy matching. That means "Acme Inc" and "Acme, Inc." are two different companies to the check, and you should know that rather than assume the tool is cleverer than it is.

It does not guess which term your document was defining. The conflict detection above fires on rules tagged with a business term and a department. If Marketing and Finance each upload a policy document, the rules that come out are not automatically tagged, so the "customer" conflict between them will not surface on its own. You have to say which term a rule defines. That is a real limit, and it is the first thing to do after an import.

Start here

You do not need software for the first step, and you should not start with the hardest term.

1. Pick the number that caused your last argument. Not your most important number. The one two teams disagreed about most recently.
2. Write the definition in one sentence that says which evidence counts. If you cannot write it in one sentence, that is your first finding.
3. Name the team it belongs to, and the team that uses a different version. Write down both.
4. Date it. A definition without a date cannot be compared against the reports built before it.
5. Then look at the records that do not match it. That number tells you whether the definition is real or aspirational.

Step 2 is where most teams stop, and it is where most of the value is. A definition somebody wrote down beats a definition everyone assumed.

The bottom line

A guardrail is not a wall. It is a written definition and a flag.

Two teams meaning two different things is a fact to record. Two teams meaning two different things without knowing it is the failure. The work is agreeing what the word means, recording the answer, and being willing to look at the records that do not match. Teams skip the looking because it is uncomfortable, and the alternative is the guessing game, where 400 and 120 are both true and the board hears whichever one gets presented.

Write the definition down. Then go look.

Related: Guardrails Beat Cleanup. Always. and How to Write a Data Contract Without a Data Engineer.