Executive Summary: Cobalt's new cachedData response can expose an interim Secretary of State match before the live search completes. The later live result may identify a different candidate because Cobalt's cache search and a state's own search can interpret or rank the same query differently. A lender should preserve both observations, create a neutral identity-review case, and resolve it with stable identifiers and query context instead of treating the variance as proof of error or misconduct.
Why Can Cached and Live Matches Differ?
How can search paths rank the same name differently?
A stored-data search and a state website do not necessarily use the same index, normalization, candidate pool, ranking rules, or update timing. Punctuation, legal suffixes, abbreviations, word order, assumed-name records, and state-specific search behavior can change which candidate appears first.
Cobalt's guidance on matched fields explains that match evaluation can consider multiple returned fields rather than the company name alone.[1] The top label is therefore one part of the identity context, not an independent verdict.
Does a different top result prove one source is wrong?
No. The approved feature brief explicitly says cached and live matches can differ because the search systems behave differently and that this does not necessarily make either result incorrect. The completed live response remains the final Cobalt result, but the earlier observation still explains what the workflow displayed or used.
Treat the difference as a comparison condition, not an accusation.
Cobalt's confidence-threshold guidance also cautions that a score should be interpreted with business context rather than used as a universal decision line.[2]
When Should the Integration Open a Review Case?
Which differences may be material?
The lender should define materiality for its own products. Candidate triggers may include a different state identifier, a legal-name change that cannot be normalized safely, conflicting entity status, a different registration state, or a final candidate that fails the original interim match rule. A punctuation-only difference may be non-material if other identifiers agree.
Do not use one generic string inequality. Normalize only according to documented customer rules and retain both original values.
Which differences should not create an automatic allegation?
A different candidate rank, suffix presentation, abbreviation, or returned URL may require comparison without implying applicant fault. Likewise, cache age can explain a changed status without proving that either system malfunctioned.
Cobalt's cache guidance tells consumers to examine timestamps for recency decisions.[3] Record age as one review input, not as a substitute for identity evidence.
Use explicit triggers:
• Stable identifier conflict. Returned registration or filing identifiers differ.
• Material legal-name variance. Normalization cannot explain the difference.
• Status variance. Interim and live status would change an allowed workflow step.
• Jurisdiction variance. The returned registration state differs from the intended search.
• Candidate switch. The selected entity changes after live completion.
• Policy uncertainty. The rule cannot classify the variance deterministically.
Version the trigger rules and evaluate them only after the live observation has been durably stored. A later rule change should not rewrite why an earlier case entered the queue. If a rule is corrected, create a new evaluation event that references the earlier one. This preserves the difference between the evidence received and the customer's interpretation at that time.
What Evidence Should the Review Case Preserve?
Which observations must remain immutable?
Keep the raw incomplete response, cached record, updatedAt, receipt time, search inputs, retryId, final live response, final receipt time, and any interim rule outcome. Do not overwrite the cached values when the live response arrives.
Cobalt's source guidance distinguishes cached and live responses by provenance and timing.[4] Retaining both lets a reviewer reconstruct the sequence without guessing which fields changed.
Which comparison fields should be extracted?
Build a customer-owned comparison object that points back to the raw observations:
{
"reviewReason": "cached_live_candidate_variance",
"cachedObservationId": "obs_cached_1",
"liveObservationId": "obs_live_1",
"query": {"state": "CA", "name": "Example Holdings LLC"},
"differences": ["title", "registrationIdentifier"],
"stableAgreements": ["stateOfSosRegistration"],
"disposition": null
}This is an internal model, not a Cobalt response schema. Cobalt documents fields such as candidate name, score, and URL as contextual data whose presence can vary by response.[5]
Retain the provider response shape without inventing missing fields. The Cobalt SOS reference is the public contract for request and response behavior,[6] while the customer's comparison object is a derived record. Keeping those layers separate prevents an internal convenience field from being mistaken for data returned by Cobalt.
How Should the Queue Be Designed?
What should a reviewer see first?
Show the original query and state, cached and live source labels, both timestamps, stable identifiers, material differences, and current process status. Put the final live observation first for finality, but keep the cached observation visible as prior context.
Avoid a red fraud banner or a label such as bad match. Use Identity comparison required or another lender-approved neutral phrase. The interface should explain that different search paths can rank candidates differently.
How should cases be prioritized?
Prioritize by business dependency and evidence conflict, not by unsupported risk inference. A case blocking a time-sensitive final verification may enter a faster queue than a historical variance with no open action. A stable-identifier conflict may deserve higher review priority than a punctuation difference.
Document queue rules, owner, service targets, and escalation. Cobalt supplies results and context; the lender owns staffing, disposition, and every credit consequence.
Deduplicate queue creation on the verification request plus the two observation versions. A repeated callback or poll should find the open case rather than create another assignment. If a materially different final observation later arrives through an authorized correction path, create a linked case version and explain why it superseded the prior comparison.
How Should a Reviewer Resolve the Variance?
Which sequence reduces confirmation bias?
Begin with the exact query and jurisdiction, compare stable identifiers, inspect normalized and original names, review registration status and dates if returned, examine candidate alternatives and scores in context, and record corroborating evidence permitted by lender policy. Do not begin by choosing the source the reviewer expects to win.
Cobalt's matched-field guidance can help explain which fields supported a candidate,[1] while its confidence guidance says thresholds depend on use case.[2] Neither replaces lender judgment.
Which dispositions should be available?
Use controlled outcomes such as same_entity_nonmaterial_variance, same_entity_material_update, different_entity_query_corrected, different_entity_additional_evidence_required, unable_to_resolve, and integration_error. Add reviewer rationale and the evidence considered.
Do not allow a free-text note alone to close the case. A structured disposition supports consistent operations and lets the team monitor recurring causes without turning the output into an unsupported accuracy score.
Require a short rationale even when the structured outcome seems obvious. The rationale should cite the decisive fields or evidence and avoid speculation about the applicant. Templates can prompt reviewers to state, for example, that registration identifiers agreed and the difference was a legal suffix. This creates useful quality-review material without asking reviewers to write a narrative essay.
How Should Interim Actions Be Handled During Review?
What if cachedData already triggered preparation?
Freeze any dependent preparation that could carry the wrong identity forward. Keep a trace of what occurred, reverse only through the lender's authorized procedure, and do not delete the earlier event. Reversible work is useful precisely because the system can pause or recompute it when final data changes.
If the cached observation was only displayed, mark it superseded by the final source while retaining its original label and time. Never relabel it as live after the fact.
If interim preparation wrote data into another system, send a source-aware correction event that points to the final observation and original action. Do not rely on a nightly overwrite with no explanation. Confirm that every consumer either updates its derived record, freezes for review, or has no decision-bearing dependency on the field that changed.
Which actions must remain blocked?
Keep final verification, approval, decline, funding, and other lender-defined decision-bearing steps behind the completed review when the variance is material. The feature supplies an interim observation, not authority for a credit outcome.
Cobalt's status documentation distinguishes incomplete and completed states.[7] The review queue should preserve that terminal-state boundary even when both observations contain plausible business records.
How Should the Decision Be Logged and Closed?
What belongs in the audit event?
Record the lender request key, retryId, both observation IDs, timestamps, query inputs, fields compared, rule version, queue entry time, reviewer identity, evidence references, disposition, and resulting workflow action. OWASP recommends application logs that capture event status, reason, and action.[8]
Protect customer and provider data with lender-approved access and retention. NIST frames log management across collection, storage, access, and disposal.[9] A record's existence alone does not establish legal sufficiency.
When is the case actually closed?
Close the review only after the structured disposition is committed and the orchestration state advances exactly once. If a callback or poll is delivered again, idempotent handling should recognize the terminal observation without reopening or duplicating the case.
AWS describes idempotency as repeated operations producing the same state effect.[10] Use a unique review key based on the verification request and compared observation versions.
How Should the Team Test and Improve the Queue?
Which fixtures expose real failure modes?
Test exact agreement, punctuation-only change, legal suffix change, stale status update, different stable identifier, different top candidate with the same query, altered query input, missing candidate metadata, duplicate final delivery, and unresolved evidence. Assert the visible language, permitted actions, disposition, and event count.
Include a case where the cache is absent. It must not enter this variance queue because there are not two observations to compare. Include a final no-match case separately because it follows the lender's no-match exception path.
Exercise permission and race conditions too. Deliver the live result while a reviewer is opening the interim record, retry the final event twice, and close the case while an old worker attempts to enqueue it again. The final database state, user screen, and emitted workflow events should agree on one case and one disposition.
Which metrics are responsible to publish internally?
Track queue volume, disposition mix, time to resolution, repeat causes, reopened cases, and downstream actions prevented. Do not convert those figures into claims that one search path is universally more accurate unless a valid study establishes that conclusion.
Review a sample of closed cases for consistent rationale and interface clarity. The verification waterfall guide gives the broader source-provenance model, and the no-match exception guide addresses a different terminal branch. To review the comparison design against your workflow, schedule a demo.
Feed confirmed recurring causes back into query validation, interface copy, and rule tests. Keep that improvement loop separate from individual applicant disposition so operational learning never becomes an unsupported negative inference.
Retain the reviewed evidence under the lender's approved access and disposal rules.
.jpg){kind=small}
.png)