Verification Design That Does Not Treat Unknown as Pass: Preventing AI Reliability from Being Misrepresented by Apparent Match Rates

🎥 The YouTube version is also available:

Unknown Is Not Pass: Designing AI Verification Beyond Misleading Accuracy Metrics

Books: KNOWLEDGE FLOW PRACTICAL GUIDE: Transform Enterprise Knowledge into Al-Ready Knowledge Infrastructure

When introducing AI into business operations, several metrics are commonly used:

• Answer accuracy
• Decision match rate
• Automated-processing success rate
• Search hit rate
• Rule-violation detection rate

These metrics are important. But when we look only at the numbers, we can miss something dangerous.

Are we counting what could not be verified as “no issue” or “a match”?

Documents that cannot be accessed, logs that have been truncated, data that failed to arrive because of an integration error, and sources that have stopped being updated: if an AI or verification system cannot see them, yet treats them as “not applicable,” “matched,” or “passed,” its apparent reliability becomes artificially high.

What is needed is a verification design that does not treat Unknown as Pass.

“Not Found” Is Not the Same as “Does Not Exist”

Imagine an AI receives the following question:

Does this application qualify under an exception condition that was approved in the past?

Suppose the search finds no relevant record. There are at least three possible explanations.

1. No such exception exists.
2. The exception exists, but was not found because of the search conditions or data structure.
3. The exception record exists, but cannot be accessed because of permissions or a system failure.

Only the first case means “not applicable.”

If cases 2 and 3 are also treated as “not applicable,” the system replaces the fact that it could not verify something with the conclusion that it does not exist.

This is not only an AI problem. It is a common problem across monitoring, security, quality assurance, legal review, data integration, ETL, RAG search, and every other kind of verification process.

Verification Results Should Be Treated as at Least Three-Valued

Many business systems represent results in binary form:

• Pass / Fail
• Yes / No
• Match / Mismatch
• Detected / Not detected

But in an uncertain information environment, two values are not enough.

Unknown is not merely a state for displaying an error. It is a formal result that defers a decision and routes the case to human review or additional evidence collection.

The important point is not that Unknown must always be treated as Fail. In lower-risk processes, a retry or later follow-up may be sufficient.

However, for high-risk processes, not treating Unknown as Pass is an essential principle.

How Apparent Match Rates Become Artificially High

When Unknown cases are excluded or rounded into Pass, the numbers on a dashboard can look attractive.

Suppose there are 100 verification cases with the following actual breakdown:

If we ignore Unknown and say, “80 of the 85 verified cases matched,” the match rate becomes 94.1%.

But across the actual operation, 15 out of 100 cases have not been verified. If Unknown cases are concentrated in high-risk matters or in a particular data source, the figure of 94.1% has very little meaning.

Therefore, when presenting reliability, organizations should display at least the following alongside the match rate:

• Match rate
• Mismatch rate
• Unknown rate
• Breakdown of Unknown by reason
• Retrieval success rate by information source
• Number of Unknown cases involving high-risk targets
• Number of cases awaiting re-verification or human review

A trustworthy system does not hide inconvenient uncertainty.

Major Reasons Why Unknown Occurs

Unknown means more than simply “there is no data.” Unless the cause is recorded, improvement will not follow.

When Unknown is handled by reason, the issue does not remain vaguely categorized as “poor AI accuracy.” It becomes possible to improve the real causes: information infrastructure, access rights, operations, integration quality, and data management.

Incorporating Unknown into AI Responses

Generative AI can produce natural language even when it does not know something. For this reason, handling Unknown is especially important in RAG systems and AI agents.

An AI should be able to answer like this:

Based on the materials currently available, no approved exception condition was found. However, meeting records from before June 2026 cannot be accessed because their retention period has expired. Therefore, it cannot be concluded that no exception exists. Additional verification is required.

This does not demonstrate weak answering ability. On the contrary, it demonstrates that the system can correctly manage the scope and limitations of its evidence.

What we should require from AI is not that it always produces an answer.

It is that the AI accurately distinguishes between what it could verify and what it could not verify.

Connecting Unknown to the Next Action

Simply displaying Unknown is not enough for practical operations. Every Unknown result needs to be connected to an appropriate next action.

• If the retrieval failure is temporary, retry automatically.
• If an important information source cannot be accessed, notify an administrator.
• If there is insufficient permission, route the case to an approval workflow where appropriate.
• If logs have been truncated, retrieve the original source or retrieve the specified time range again.
• If a document is outdated, request an update confirmation from the document owner.
• If evidence conflicts, stop AI-driven automatic execution and defer to human judgment.

What matters here is not trying to resolve Unknown automatically at any cost.

Designs such as “letting the AI read a document just in case, even though it lacks permission,” or “collecting inaccessible logs through another path without authorization,” do not increase reliability. They break security and governance.

Unknown is both a signal of the system’s limit and a signal of a boundary that must not be crossed.

Handle Unknown Differently According to Risk

Not every Unknown result must stop a process in the same way. But a clear risk-based policy is essential.

By designing Unknown as part of the process, organizations can achieve both speed and safety in AI adoption.

Conclusion: Reliability Means Not Hiding What Cannot Be Known

The reliability of an AI system is not defined by displaying a high match rate.

Real reliability lies in the ability to distinguish clearly between:

What was verified, what could not be verified, and why it could not be verified.

Do not count unobservable data, truncated logs, or inaccessible documents as “matches.” Record Unknown as a formal result, then route it to the required re-verification or human decision.

This design is not intended to make AI excessively cautious.

Rather, it is the foundation for correctly defining the scope in which AI can operate—and for confidently automating work within that scope.

Do not treat Unknown as Pass.

That principle creates AI systems trusted in real operations, rather than systems that merely display attractive accuracy metrics.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance