AI Account-Search Empty-String-Match Automation: Forty-Six Results for a Nonsense Search
A search tool that never says "not found" is not a working search tool
The entire value of a search function that exists to answer "does this already exist?" depends on it being able to say no. A search that always returns something — regardless of how unrelated the query is to what actually exists — doesn't fail loudly; it fails by looking successful every single time, which is a much harder failure to notice than an error message, because nothing about a full result list looks obviously wrong on its own.
How the underlying problem shows up before you fix it
A search or match condition normalizes its input (stripping formatting, keeping only digits) before comparing it against a stored value, without checking whether either side actually still has any content left after that normalization.
Two independently empty values (an empty search term, a record with no value on file) are compared with ordinary equality, and nothing in the query distinguishes "both empty, so match" from "both empty, so meaningless."
A tool documented to return an explicit empty result for "not found" never actually produces that empty result in practice, for any input tested.
A search returns the same result set regardless of how unrelated or nonsensical the query is — a signal that one branch of an OR-based filter is matching unconditionally.
A capability whose contract other logic depends on (an agent inferring "not found" means "safe to treat as new") is validated only by testing that it returns SOMETHING for a real query, never by testing that it correctly returns NOTHING for a term that shouldn't match.
How a live QA session caught it, and how the fix closes exactly the empty-string trap
The finding came from a direct, dated QA session testing the account-search tool with three different terms — a genuine internal test label, a real company name, and the deliberately meaningless string "zzzzzz" — and getting back the identical 46 accounts for all three. That result rules out a partial-matching quirk on any one term and points at something structurally wrong with the query itself.
The tool's search logic combines a name-based match with a CNPJ-based match, joined by OR — either one succeeding is enough to include an account. The CNPJ branch strips every non-digit character from both the search term and the account's own CNPJ field before comparing them, which is reasonable for tolerating formatting differences (dots, slashes, spaces in a CNPJ). What it didn't account for is the case where stripping non-digits leaves NOTHING: a search term with no digits (the overwhelmingly common case — most searches are by company name, not tax ID) reduces to an empty string, and an account with no CNPJ recorded at all reduces to an empty string too. SQL's plain equality operator treats two empty strings as equal, so that branch of the OR silently matched every single CNPJ-less account for every single non-numeric search, turning what should have been a precise, narrow filter into an unconditional match across a large share of the account base.
The fix adds one condition to that branch: the CNPJ comparison only runs at all when the search term's digits-only form has at least eight characters — a reasonable floor for what could plausibly be a partial CNPJ, and high enough that an ordinary short numeric fragment or a company name won't accidentally cross it. Below that threshold, the CNPJ branch simply doesn't apply, and the name-based match carries the search on its own. The migration applying this fix is itself a programmatic patch to the existing function's stored definition, with an explicit check that refuses to apply if the exact text it expects to find and replace isn't present — and it closes with its own embedded proof, run as part of the same migration: a search for a term that matches nothing must return zero results, and a search for a real company name must return that company specifically, in a short list, not merged into a large undifferentiated batch.
What is actually built today
The CNPJ-matching branch of the account-search tool only activates when the search term's digits-only form has at least eight characters.
Below that threshold, the search relies entirely on name-based matching, which was never affected by this defect.
A search for a term that matches nothing now genuinely returns an empty result, restoring the tool's own documented contract that empty means "not yet registered."
The fix is applied as a programmatic patch to the existing function's own stored definition, refusing to apply silently if its expected target text isn't found first.
A built-in proof runs as part of the same migration: a nonsense search term returns zero accounts, and a real company name returns a short, correct result including that company.
Confirmed today via direct inspection: the eight-digit gate remains part of the current function definition.
Forty-six accounts for a search that should have found none (illustrative framing of the actual measured finding)
Searching the account tool for a company name that has never been in the system, and searching it for the literal nonsense string "zzzzzz," both returned the same 46 accounts before this fix — every account in the organization with no CNPJ recorded. After the fix, both searches correctly return an empty result, and a real company name returns only that company.
What changes operationally
Centriu's AI account-search tool can now genuinely tell an agent that a prospective account is NOT already registered, closing a defect where an empty-string comparison silently made every CNPJ-less account match every non-numeric search — a gap that risked an agent wrongly treating a fresh prospect as an existing client, or picking an unrelated account out of dozens of false matches.
When this is not the right fit
This fix is scoped to the CNPJ-matching branch of the account-search tool specifically — it does not change how the name-based branch of the same search works, which was already functioning correctly and is unaffected.
A search that always finds something vs. one that can correctly find nothing
A search tool that returns results for nearly anything typed into it can look, superficially, like it's working — every query gets an answer. Centriu's fix treats the ability to correctly return nothing as an equally essential requirement, proven with the same rigor (an explicit, embedded test asserting zero results for a term that matches nothing) as the ability to correctly return something.
Related systems
Main system: Centriu Orbit. Complementary when relevant: Centriu Axis.
What it does NOT do
- Does not change how the name-based branch of the account-search tool works — that branch was never affected by the empty-string defect and is unchanged.
- Does not apply the CNPJ comparison to a search term with fewer than eight digits — those searches rely on name matching alone.
- Does not retroactively review past search results that may have been affected before the fix — it corrects the tool's behavior going forward.
- Does not merge or deduplicate accounts that were previously returned together by the defect — each account remains its own distinct record, entirely unaffected by this fix.
- Does not claim to validate every other search or matching function across the platform — this fix addresses the specific, measured defect found in this one tool.
- Does not require every account to have a CNPJ on file — an account with none simply falls back to name-based matching, exactly as it should.
Security and governance
The account-search tool resolves the requesting agent's own organization before searching, and only ever returns accounts belonging to that organization. Any business data referenced remains subject to Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
What exactly caused every CNPJ-less account to match every search?
The CNPJ-matching clause stripped non-digits from both the search term and the account's CNPJ before comparing them; a non-numeric search term and an account with no CNPJ both reduced to an empty string, and empty string equals empty string in SQL.
How was this found?
A live QA session tested the tool with three unrelated search terms and found all three returned the identical 46 accounts — a result that pointed directly at an unconditional match somewhere in the query.
How does the fix prevent this without breaking real CNPJ searches?
The CNPJ comparison now only runs when the search term itself has at least eight digits — enough to represent a real partial CNPJ, while excluding the empty-string case entirely.
Does this affect searching by company name?
No — name-based matching was never affected by this defect and works exactly as it did before.
How was the fix verified?
The same migration includes an embedded proof: a nonsense search term must return zero results, and a real company name must return a short, correct result including that company — both checked automatically as part of applying the fix.
What does Centriu Orbit cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Orbit keeps AI account search precise
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.