The Borrower Changed Its Details: Keep Old Verification Results Out of the New Application

Executive Summary: An asynchronous verification result belongs to the inputs that produced it. Cobalt's Full Verification flow returns a searchGuid for tracking a submitted search.^[1] Bind that search to an immutable application revision so a late result cannot silently become evidence for a corrected borrower record.

What happens when an application changes during verification?

Consider a hypothetical broker-submitted application. The first version contains one business name. While its state searches are still running, operations confirms a correction and updates the name. A result for the first version arrives after the correction.

That response may be valid evidence for the original search. It does not automatically answer the new question. If the integration attaches results by the application's current name or by whichever event arrived last, the analyst may see evidence for the wrong input version.

Which changes matter?

Identify the fields that determine each verification request. Depending on the supported endpoint and your workflow, these might include business name, state, registry identifier or another submitted identity attribute. A change to a field used by the request needs a deliberate evidence-reuse decision.

Cobalt's Full Verification request documents business-name or person-name inputs and optional address fields.^[2] Use the actual fields your integration submits to decide what belongs in its request snapshot. Do not assume every visible application edit changes the source query.

Does every edit require a new search?

Not necessarily. A corrected internal note may have no effect on verification inputs. A changed business identity can be material. Record the distinction in a versioning rule so operations does not have to improvise every time.

The proposed control is to preserve which inputs a result evaluated. Whether those inputs remain sufficient for the current application is a separate policy decision. Do not hide that decision inside a generic “latest result” field.

How should the application identify a verification attempt?

Create an attempt record before sending the source request. Tie it to the application, tenant or customer context where applicable, and the exact relevant input revision. Store the provider's returned request identifier on that same attempt.

Cobalt's initVerification response provides a searchGuid, and its status-check flow uses that value to retrieve progress and results.^[3] Treat it as the source-search reference, not as a replacement for your application's own identity and revision model.

What should an attempt record contain?

A practical record includes:

• Application identity. The internal application that requested the evidence, including its authorized customer context.

• Input revision. An immutable identifier for the relevant submitted facts at request time.

• Submitted snapshot. The exact request inputs, stored under the appropriate access policy.

• Provider search reference. The returned identifier used to correlate later observations.^[4]

• Observed events. Receipt times and source states associated with that attempt.

• Current-use disposition. Whether the result supports the current application, needs review or belongs only to a superseded revision.

Why not use the business name as the key?

Because the name is one of the facts that can change and one of the values the search evaluates. It is useful evidence, but it should not decide which application receives a late response.

Use your internal attempt reference and the documented provider correlation value. If an event cannot be correlated safely, keep it in an unresolved intake state rather than attaching it to the first current application with similar text.

How should a late result update the current application?

First, identify the original attempt. Then compare that attempt's input revision with the current relevant application revision. Preserve the source observation in either case, but allow it to affect the current review only through an explicit rule.

The following is customer-side pseudocode using application fields. It is not a Cobalt request or a documented vendor versioning feature.

def apply_observation(application, attempt, observation):
    attempt.observations.append(observation)
    same_application = attempt.application_id == application.id
    same_revision = attempt.input_revision == application.input_revision
    if not same_application:
        return "correlation_review"
    if not same_revision:
        return "superseded_input_evidence"
    return "evaluate_for_current_review"

What does superseded evidence mean?

It means the response belongs to an earlier input version and cannot silently overwrite the current evidence state. It does not mean the source response was erroneous or worthless.

An analyst may inspect it to understand the correction, compare possible entities or reconstruct the application history. Any decision to reuse part of it should identify the unchanged facts and the specific review purpose. Do not convert that deliberate reuse into a blanket approval of the new version.

What if the application changes during the update itself?

Use the transaction or conditional-update mechanism appropriate to your system so the revision check and current-state update cannot be separated by another edit. Test the actual race condition, not just the simple sequence in which every operation happens neatly in order.

This is an integration design recommendation. Cobalt supplies the documented search reference and source results; the customer owns application revisioning and the conditions under which evidence changes a lending workflow.

How is a retry different from a new verification request?

A retry repeats an intended operation after uncertainty about its execution. A new request evaluates a different intent or different relevant inputs. Keep that distinction explicit when the borrower record changes.

AWS's Builders Library discusses idempotent APIs in terms of safely retrying the same request intent and the problems created when request meaning changes.^[5] Apply that principle to your internal attempt model without assuming a particular Cobalt idempotency feature exists.

Should a corrected application reuse the old attempt ID?

Use a new internal attempt when the relevant submitted inputs change. Preserve the relationship between the attempts so a reviewer can understand why the second request exists. Do not overwrite the old attempt's submitted snapshot with the corrected inputs.

If the provider uses its own identifier for a new search, retain that returned value. Avoid treating a previous source-search reference as permission to ask a different question under the old evidence history.

Should a timeout trigger a fresh request immediately?

Follow the supported status and retrieval flow before deciding whether to initiate another attempt. Cobalt's Full Verification documentation provides status actions for prior or ongoing searches.^[6] A local timeout does not establish that the provider lost the original request.

If another request is needed, preserve both attempts and the reason for the second. The current application should not become a contest between whichever attempt produces a more convenient result first.

How should operations handle the correction itself?

Make the correction an evidence event. Record which fact changed, the source supporting the correction, who made it and which pending or completed checks may be affected. Keep the reason specific rather than using “data updated” for every change.

For a hypothetical business-name correction, the analyst should see the previous name, corrected name, supporting reference and current verification status for the corrected submission. The earlier search remains visible as earlier evidence, not as the current answer.

What should the analyst-facing status say?

Use wording such as “Earlier search completed; corrected application awaiting review.” That tells the reviewer both that useful evidence arrived and that the current requirement remains open.

Avoid showing only “Verification complete” at the top of the application when the completed result belongs to the superseded inputs. The summary should describe the current review state, with earlier events available in the history.

What if the correction resolves a no-match result?

Retain the original no-match evidence and the corrected request that followed it. Do not rewrite the initial source result into a match. The no-match exception operations guide provides a broader framework for resolving the underlying evidence question.

A corrected application can support a new result without making the previous result disappear. That distinction helps a later reviewer understand whether the issue was input correction, a different source response or an analyst interpretation.

How should polling and callbacks share the same history?

Route both through the same attempt record. Cobalt's documented Full Verification flow permits an optional callback and status retrieval using the search reference.^[7] Your application should not create one evidence history for callbacks and another for polling.

Preserve each observation with its receipt time, then decide whether it adds new information or repeats what the attempt already contains. The current review should depend on the correct attempt and revision, not the delivery route.

What if a status read succeeds before the source finishes?

Do not confuse that with a final result for the current application. Cobalt explicitly documents that businessStatusCheck can return HTTP 200 before all state work completes.^[8] Source completion and application-version suitability are two separate checks.

A result can be current but still partial. It can also be complete but tied to superseded inputs. Your data model should represent both situations without forcing one generic status to carry all their meaning.

What if an identifier contains special characters?

Use the documented encoding rules. Cobalt warns that the # in searchGuid must be encoded when it is passed as a query value.^[9] A correlation design is only useful if the client sends and retains the identifier accurately.

Keep failed status requests attached to the relevant attempt. Do not interpret an incorrectly constructed request as evidence that the corrected business has no state record.

A late response can be valid evidence and still be the wrong evidence for the current application.

Which tests expose the dangerous race conditions?

Use a synthetic application and control the order of events. Start a search for revision one, change a relevant field to create revision two, start the second search, then deliver the first result after the second. Confirm that the current application retains the evidence appropriate to revision two.

Repeat the test with the opposite arrival order, duplicate delivery and an application edit that occurs between the initial revision check and the final update. These are suggested acceptance cases, not claims about how frequently the events occur.

What should every test assert?

Assert the application and revision attached to each observation, the current analyst-facing status and the preservation of earlier source evidence. A test should fail if old results overwrite corrected inputs or if an uncorrelated event is attached through a fuzzy name match.

Also test a nonmaterial edit that your policy says does not invalidate a check. The system should preserve the reason it can continue using the evidence rather than creating unnecessary requests for every change in the record.

How should the reviewer validate the behavior?

Ask an underwriter to reconstruct the sequence from the evidence history alone. They should be able to identify what was submitted first, what changed, which result supports the current review and what remains unresolved.

Middesk's lifecycle documentation distinguishes submission, verification and the client's approval decision.^[10] That separation is useful when designing your own review history, although your application must still handle its own revisions and access boundaries.

What should you establish before rollout?

Agree on the fields that define a verification input revision, the handling of material corrections and the authority for reusing older evidence. Then document the actual provider identifiers and source-completion fields used by the integration.

Cobalt's fullStatusCheck documentation identifies sosStatus as the primary completion field in the current example.^[11] Keep that mapping separate from the customer-side question of whether the completed search belongs to the current application revision.

What should the evaluation include?

Bring a correction scenario, not only an unchanged happy-path application. Ask to inspect the start response, status retrieval, callback behavior and correlation information. Confirm the actual contract before assuming the provider can cancel an old search or manage the lender's application versions.

The pre-funding verification framework can help identify where the current evidence is used in the lending decision. Place the revision check immediately before that evidence changes the application's review state.

Middesk's quickstart also treats source results as information for a later business decision.^[12] Evaluate any provider against your specific correction scenario, rather than assuming asynchronous verification automatically handles application changes.

Schedule a Cobalt demo with that scenario. The practical objective is that every result remains traceable to the question actually submitted, including when the borrower record changes before the answer arrives.