When Data Governance Should Say: We Don’t Know Yet

One of the most dangerous things in Data Governance is false certainty.

Management asks a simple question:

“Can we trust this KPI?”

And sometimes the correct answer is not yes.

It is not no either.

Sometimes the correct answer is:

“We don’t know yet.”

That does not mean Data Governance has failed.

It can mean exactly the opposite.

It means the organization understands the difference between what has been confirmed and what is still being verified.

Imagine that most of the data behind a KPI has already been checked.

The main source is known.

The business definition is clear.

Validation rules are running.

But part of the Data Lineage is still being verified, or one transformation has not yet been fully reviewed.

In that situation, saying that the KPI is completely reliable would be misleading.

But saying that it is completely unusable may also be unnecessary.

The better answer is to communicate the level of confidence clearly.

This is where I believe Data Governance can benefit from a simple model:

Confirmed.

Partially Confirmed.

Not Yet Confirmed.

A Confirmed KPI should mean something serious.

It should not mean that someone looked at the dashboard and decided that the numbers “look right.”

To reach that status, all critical parts should be verified.

The business definition should be confirmed.

The main source systems should be known and validated.

The Data Lineage should be understood.

Transformation logic should be checked.

Validation rules should be in place.

And there should be no unresolved critical Data Quality issues.

Only then should a KPI be treated as fully confirmed.

But not every KPI will immediately reach that level.

Sometimes most of the important work has been completed, while a smaller part is still under review.

That is where Partially Confirmed becomes useful.

For me, this status should still require a meaningful level of verification.

It should not mean “we checked a few things.”

At least the critical foundation must be in place.

The business definition must be clear.

The main source must be known.

Validation rules must exist and provide reasonable confidence in the data.

If roughly 70% of the important verification work is complete, and the most critical elements have been covered, the KPI may be usable.

But it must never look the same as a fully confirmed KPI.

A Partially Confirmed KPI should always carry a disclaimer.

And that disclaimer should not be hidden somewhere deep in governance documentation.

It should be visible directly on the dashboard.

Top management does not have time to search through a Business Glossary every time they review a report.

If a KPI has limitations, the person making the decision should see them immediately.

The visual language can be simple.

Green for Confirmed.

Yellow for Partially Confirmed.

Red for Not Yet Confirmed.

The goal is not decoration.

The goal is immediate understanding.

A yellow KPI tells the user:

“You can use this information, but there are still known limitations.”

A red KPI says something different.

It means the organization does not yet have enough evidence to use that KPI for a serious business decision.

It can be visible.

It can be analyzed internally.

But it should not be treated as a reliable basis for decision-making until it reaches at least Partially Confirmed status.

The important point is that these statuses are not permanent.

A KPI that is green today can become yellow tomorrow.

A source system may change.

Business logic may be updated.

A new Data Quality issue may appear.

A transformation may be modified.

The moment something material changes, the confidence status should be reviewed again.

If a previously Confirmed KPI becomes Partially Confirmed, the dashboard should not only change color.

It should explain why.

For example:

“Business logic updated. Verification in progress.”

Or:

“Source data issue identified. Revalidation required.”

That explanation matters because users need to understand whether the change comes from the data, the logic or the system behind it.

And once the problem is resolved, the KPI can return to Confirmed.

But the previous status should not disappear from history.

The audit trail is critical.

It should show when the status changed.

Why it changed.

What was tested.

Which validation rules were introduced or modified.

What corrections were made.

And what finally allowed the KPI to return to a higher confidence level.

This history is valuable for more than compliance.

It becomes organizational memory.

Without it, teams can easily repeat the same work months later.

Someone may propose the same validation rule that was already tested nine months ago.

A team may investigate the same source issue again because nobody remembers what was already discovered.

Time is wasted simply because the organization forgot its own history.

A good audit trail prevents that.

There is one more important rule.

Partially Confirmed should not become a permanent comfort zone.

If a KPI stays yellow for months, the organization should treat that as an open governance issue.

The relevant teams need to finish the remaining verification work.

A temporary limitation should not quietly become the accepted standard.

This is what makes “We don’t know yet” useful.

It is not an excuse.

It is a temporary, controlled and transparent state.

Good Data Governance should not pretend to know more than it does.

It should know exactly what has been confirmed.

It should know exactly what has not.

And it should make that difference visible to the people making decisions.

Sometimes the most responsible answer is not yes.

It is not no.

It is:

“We don’t know yet — and here is exactly what we still need to confirm.”