Executive Summary: Cobalt's interim cachedData and a later live Secretary of State search can return different top candidates for the same business-name query. That does not automatically mean one result is wrong or the applicant is suspicious. Stored-data search and a state's live search can normalize, filter, and rank names differently. Lenders should preserve query context, compare stable identifiers and supporting fields, and route material variance to neutral review.
What Does a Name Search Actually Compare?
Why is the visible business name not the whole identity?
Legal names can include suffixes, punctuation, abbreviations, spacing, assumed names, and historical changes. Two records may look similar while representing different entities, or look different while referring to the same entity. Identity therefore depends on the returned context, not only a string.
Cobalt's matched-field guidance explains that multiple fields can support a match.[1] State identifier, jurisdiction, status, and other returned values may be more stable than presentation differences in a title.
What does candidate rank mean?
Rank means a search system ordered one candidate ahead of others under its own logic. It does not independently prove legal identity, current status, or applicant intent. Cobalt's confidence guidance says score thresholds depend on the use case and should be interpreted with returned evidence.[2]
Keep candidate selection and entity confirmation as separate events. The search layer can propose a candidate and explain which fields contributed. The lender's verification layer decides whether the evidence satisfies its identity rule. Recording both events prevents a convenient search result from being mistaken for an automatic legal-entity determination.
Rank is a search outcome. Identity is an evidence-based lender disposition.
Why Can the Cache and State Search Behave Differently?
Which technical differences can change the result order?
The two paths may use different indexes, update times, normalization rules, tokenization, candidate limits, assumed-name coverage, or state-specific query behavior. A state portal can also change its search page or ranking without mirroring a stored-data index.
Cobalt publishes state response-time variation[3] and cache-update variation[4], illustrating why jurisdiction context matters. Neither page promises identical ranking between cache and live search.
How can data age contribute?
An older cached observation may reflect a prior name, status, or candidate ordering. The record's updatedAt helps the lender measure age. Cobalt tells consumers to use timestamps for their own recency decisions rather than assume a universal validity period.[5]
Age can explain a difference but does not resolve identity by itself. A newer result is not automatically the same entity, and an older record is not automatically incorrect.
State search behavior can also change between requests. A portal may adjust filters, candidate limits, or presentation, and the same query can yield a different order even when underlying registrations do not change. Preserve the actual result and time instead of assuming that a later rerun reproduces what the original live search returned.
Which Query Details Must Be Preserved?
What should be stored before comparing results?
Retain the exact original business name, state, identifiers or filters supplied, normalization performed by the customer, request time, and lender request key. Then attach the cached and live observations to that immutable query record.
• Original query. Exact value sent to the provider.
• Customer-normalized query. Any internal transformation and its version.
• Jurisdiction. State or registry targeted.
• Provider correlation. retryId and request identity.
• Observation source. Cached interim or final live.
• Returned candidate context. Names, identifiers, scores, URLs, and status when present.
Cobalt's public SOS reference documents the request and response surface for the lookup.[6]
Why should customer normalization be visible?
If the lender removes suffixes, punctuation, or stop words before calling the API or before internal comparison, that transformation can influence the apparent result. Store the original and normalized forms with a rule version. Do not attribute a customer-side transformation to Cobalt or the state.
Use conservative normalization for deterministic comparison. More expansive fuzzy logic should create evidence for review, not silently merge entities.
Document every transformation in a testable sequence. For example, case folding may occur before suffix normalization, while punctuation removal may preserve separators needed for token comparison. Two services using the same rule names in a different order can generate different candidates. A shared versioned library or contract test reduces that hidden source of variance.
How Should Results Be Compared?
Which fields should come before name similarity?
Start with stable registration or filing identifiers, jurisdiction, entity type, and other returned identifiers. Then compare original and normalized legal names, status, dates, addresses if returned and permitted, candidate rank, score, and source URL.
Cobalt explains that fields such as name, score, and URL provide candidate context and may vary by response.[7] Absence of an optional field should not be converted into disagreement.
What should the comparison object look like?
Keep raw observations separate and create a derived comparison:
{
"queryId": "query_42",
"cachedObservationId": "obs_c_1",
"liveObservationId": "obs_l_1",
"stableIdentifierAgreement": false,
"nameDifference": "legal_suffix_and_token_order",
"statusDifference": false,
"outcome": "manual_identity_review"
}This is a lender-side example, not a Cobalt schema. The outcome should reference the policy version that produced it.
Store agreements as well as differences. A review screen that shows only conflicting names can make two records appear unrelated even when jurisdiction and registration identifier agree. Positive evidence helps reviewers resolve minor presentation variance and makes the closing rationale understandable to later operations staff.
Which Differences Can Be Resolved Automatically?
What counts as a narrow deterministic rule?
A lender may decide that case folding, whitespace normalization, known legal-suffix equivalence, and punctuation differences are non-material when stable identifiers and jurisdiction agree. The rule should be written, tested, versioned, and limited to the named use.
Do not let a similarity score alone merge records with conflicting identifiers. Automatic resolution needs positive evidence and a defined conflict rule.
Define precedence before writing code. Stable identifier conflict should usually stop a name-only auto-resolution, while identifier agreement may allow a narrow suffix rule. If identifiers are missing, the system should enter a different evidence path rather than pretending that the conflict rule passed. These choices belong to lender policy, not the provider contract.
When should the system stop and ask for review?
Route to review when identifiers conflict, the top candidate changes materially, a name transformation is ambiguous, status variance affects workflow, query inputs appear wrong, or required evidence is missing. Use neutral language such as Candidate identity requires comparison.
The feature brief says cached and live matching can differ without making either result inherently incorrect. Review should test identity and query context rather than assign blame.
Attach the review case to both immutable observations and prevent a final worker from overwriting either one. Deduplicate case creation on request and observation versions. If a corrected query creates a new provider request, link it as a separate attempt so reviewers can distinguish a search correction from a late result for the original query.
How Should Review Avoid Unsupported Inferences?
What sequence should a reviewer follow?
Confirm original query and state, compare stable identifiers, inspect original and normalized names, review timestamps, examine alternative candidates and match context, check permitted corroborating evidence, and record a structured disposition. Review the evidence in that order to reduce anchoring on the first result shown.
Do not treat a variance as fraud, misrepresentation, or provider failure without independent evidence. Those conclusions have consequences beyond entity matching.
Which dispositions support consistent operations?
Use outcomes such as same_entity_presentation_difference, same_entity_record_updated, different_entity_query_corrected, different_entity_additional_evidence, unable_to_resolve, and integration_error. Require a concise rationale tied to decisive fields.
Preserve both observations and the review outcome. Cobalt's source guidance distinguishes cached and live provenance,[8] so a final result should not erase what the workflow saw earlier.
Require the rationale to name decisive evidence without speculating about motive. A concise note might say that both observations share the registration identifier and state while the live result adds a legal suffix. Another might say identifiers conflict and additional documents are required. Structured, factual language supports quality review and avoids turning a search variance into an applicant allegation.
How Should the Workflow Handle Cache Absence and Final No-Match?
Why is cache absence not a matching disagreement?
Without cachedData, there are not two candidates to compare. The request remains live pending. Cobalt says a cache miss does not prove absence from the state registry.[9]
Route that case to the live-wait path, not to identity variance review. Creating a blank cached candidate would manufacture a disagreement.
How is final no-match different?
Final no-match is a terminal live outcome and follows the lender's no-match exception process. It may prompt query validation or additional evidence, but it is not equivalent to a different cached and live top match.
Cobalt's status guide keeps incomplete, no-results, cached fallback, and failure meanings distinct.[10] Keep separate internal codes and queues.
Make those codes visible in analytics. If cache absence, candidate variance, query correction, and final no-match share one exception category, the team cannot learn which workflow needs improvement. Separate denominators and measure how each branch closes without treating branch volume as an accuracy ranking.
How Should the Matching Path Be Tested and Monitored?
Which fixtures belong in the test set?
Test exact name and identifier agreement, punctuation difference, legal suffix difference, abbreviation, word-order change, assumed name, historical name, same name with conflicting identifiers, different candidate rank, wrong state input, missing optional fields, cache absence, and final no-match.
Add duplicate callback or polling delivery and ensure one comparison case is created. Test a stale worker attempting to reopen a case after final disposition.
Include concurrent and interface tests. Deliver two final events at once, change a candidate while the review page is open, export a comparison, and attempt a final-only action from a stale session. State, visible provenance, and downstream effects should converge on one authorized disposition.
Which metrics help without ranking the sources?
Track variance volume, rule-resolved versus reviewed cases, disposition mix, time to resolution, query-correction causes, repeated normalization issues, and downstream effects prevented. Do not publish a universal cache-versus-state accuracy claim without an appropriate study.
Review a stratified sample rather than only unusual or escalated cases. Include automatically resolved presentation differences, manually resolved identity conflicts, corrected queries, and unresolved cases from several states. Quality review should check whether rules applied consistently, decisive evidence was recorded, and neutral language was maintained. Findings may justify new tests or policy review, but they should not rewrite historical dispositions silently.
Log observation identities, compared fields, rule version, reason, and action. OWASP recommends logs that capture status, reason, and resulting action.[11] The verification waterfall guide provides broader provenance context. To review matching rules against your data flow, schedule a demo.
Preserve representative resolved cases as regression fixtures, with customer data removed or protected securely under the lender's approved test-data procedure.
.jpg){kind=small}
.png)