A Valid Value Is Not a True Value

Emily Goh · 2026-10-02

A 0 in an Amount field is a perfectly good number. A "0" in a First Name field is perfectly good text. A close date in March 2027 is a perfectly good date.

Every one of them passes a type check. Every one of them can wreck a forecast.

Most of what gets called CRM data quality stops right there: is the field filled, is the format valid, does the email look like an email. That's the type layer. It answers one question, "is this the right kind of thing?", and it never asks the question that matters: what does this mean?

The layers, in plain English

Here is how I think about any piece of data on its way to a decision:

1. Data. What did we receive? An Amount of 0, a stage of Closed Won, a close date next March.
2. Type. What kind of value is each one? A number, text and a date. All three are valid.
3. Semantics. What does it mean? A deal we say we won, with no value, that closes in the future.
4. Rules. What should be true? A won deal has an amount, and its close date is in the past.
5. Risk. What's wrong, and what is it worth? Two checks failing on a deal counted in this quarter's bookings.
6. Decision. What do we do? Fix the record before the number goes to the board.

Type is the bottom rung. It is useful and it is necessary. It is also the cheapest thing to check, which is exactly why most tools stop there.

The rungs above it are where the money is.

Type: the layer everyone checks

At the type layer, a value is one of a few shapes. A number (and dates and times are numbers in disguise). Text. A true/false. Or a structure that holds other values, like a record or a list.

Your CRM already enforces some of this. A date field won't take the word "banana." A number field won't take a sentence. Good.

But look at what that buys you. A field that holds a number is not a field that holds a true number. Type tells you the container is the right shape. It says nothing about what's inside.

Semantics: what does this actually mean?

This is the layer I want to talk about, because it's the one nobody owns.

Semantics is the meaning of a value in context. The same characters mean different things in different fields.

• 0 in Amount is a number. It also means "no deal value." Or "we haven't priced this yet." Or "someone needed to get past a required field." Those are three different realities with one identical value.
• "alysharockstar.com" in Email is text, and it looks like an email. It isn't one: there's no "@". It can't receive mail, and it won't match the person it belongs to.
• "0" in First Name is text. It is not a name. Neither is "John2."
• Closed Won with a close date next year is a valid stage and a valid date. Together they describe something that cannot have happened.

None of these fail a type check. All of them fail a meaning check. And meaning is what a human reads off the screen when they decide something.

Rules: what should be true?

Once you know what a value means, you can say what must hold for it to be trustworthy. That's a business rule. Not a format rule, a business one.

• A won deal's close date shouldn't be in the future.
• An open deal should carry an amount above zero.
• An email should contain an "@."
• A person's name shouldn't contain a digit.

Notice that these rules need the business to say what it means. A type system can't invent them. Somebody has to decide that "Closed Won" implies "already happened." That is semantics being written down as a rule.

This is the piece Gohvio is built around. It runs business-rule guardrails against your CRM data, on exports and on HubSpot and Salesforce connections, instead of just asking whether a field is filled.

Risk: what's wrong, and how much does it cost?

A rule that fires is only a rule that fired. The next question is the one a RevOps leader gets asked in the room: so what?

Three broken records is a footnote. Three broken records worth a large share of next quarter's forecast is a different conversation. Same defect, completely different weight.

That's why Gohvio doesn't hand you a percentage. A percentage of records tells you how messy things are. It doesn't tell you what the mess is worth, and a high number on trivial fields can look scarier than a low number on the deals that carry your quarter. Gohvio's Business Risk Score weighs impact, exposure, confidence and blast radius, and the headline is records and dollars. How many records, and how many dollars they touch.

That's the difference between "your data is 82% clean" and "these 14 records are sitting under a pipeline number you're about to report." You can act on the second one.

Decision: where all of this is going

Every layer exists to make one thing better: the decision someone makes from the number.

A forecast call, a board slide, a budget moved off a channel, a territory change. The decision doesn't care that the field was filled in. It cares whether the value could be trusted.

For RevOps, the damage from a type-only view shows up in three places.

Pipeline. A zero-value deal sitting in a late stage looks like pipeline until someone asks what it's worth.

Forecast. Stage and date that contradict each other make the forecast wrong in a way no filter catches, because every row looks valid.

Attribution. A placeholder where a real email or name should be means a contact that can't be matched, deduplicated or followed through the funnel. The campaign gets less credit than it earned, and a budget decision follows from that.

None of that is a formatting problem.

One detail that shows the whole idea

When Gohvio exports your data, a real 0 stays a 0. Only an empty cell exports blank. We don't quietly turn a zero into nothing, because a zero can be the truth.

But we do question it. If a value turns up where it can't belong, like a digit in a person's name or an email with no "@", the scan flags it. It doesn't hide it.

That's the whole philosophy in one rule: never change what a value says, and always ask whether it can be true.

Where we are, and where this goes

I want to be straight about this. Today, Gohvio runs business-rule guardrails and scores what they find by impact and dollars. It flags placeholder emails with no "@" and digits where a person's name should be. Lumi, our chief of staff for RevOps, explains what the checks found.

The full ladder above, where every column is understood as a specific kind of thing (a count versus an amount, a percent, a list, a record) and meaning is built in from the start, is how we think about the problem and where we want to go. It is a direction, not a feature list. I'd rather tell you that than imply a "semantic layer" exists that doesn't.

What to do with this

You don't need a tool to start. Pick the five fields your forecast leans on hardest. For each, write down one sentence: what does this value mean, and what must be true if it's right?

Then check whether your CRM can tell you when it isn't.

If the honest answer is "it can tell me the field is filled," you have a type layer and a leap of faith. The distance between the two is where forecasts quietly go wrong.

Data you can trust isn't data that's formatted correctly. It's data that means what you think it means.