Manual Business Verification Overrides: Record the Evidence Without Rewriting the Source Result

Executive Summary: A manual business-verification decision should sit beside the source evidence, not replace it. Cobalt's Secretary of State response can include source status, normalized status, a source URL and retrieval messages.^[1] Preserve those observations, then record who resolved the exception, what supported the decision and which action the policy allowed.

What is an analyst actually overriding?

Define the object of the decision before giving anyone an override button. An analyst may be resolving an identity question, accepting supplemental evidence or authorizing a limited next step under policy. None of those actions changes what a state registry or API returned.

For example, a hypothetical application might receive an inconclusive business-name result. The analyst obtains an official source record that establishes the intended entity. The reviewer can record that the evidence requirement was resolved using the supplemental record. They should not edit the original response into a successful match that never occurred.

Why keep those records separate?

Because they answer different questions. The source response shows what the integration observed. The disposition shows what the lender decided after considering that observation and any additional evidence.

A later reviewer should be able to see both without guessing whether a green status came from the provider or from a human decision. That distinction is especially useful when the application changes, supplemental evidence arrives or another team needs to reconstruct the file.

Does an override permit skipping required controls?

No permission follows from the word “override.” The responsible policy owner must define what decisions a reviewer may make, what evidence is required and which requirements cannot be waived through that workflow.

Design the interface around those actual permissions. A generic button that changes any unsuccessful check to “verified” is too broad to describe the decision or its authority.

Which source facts should remain unchanged?

Retain the original response, submitted inputs, source-request reference and receipt time. Preserve source labels and messages even if your application adds a more readable interpretation for the analyst.

Cobalt's SOS schema distinguishes the source status from normalizedStatus and can provide a URL for the underlying record.^[2] Keep those values traceable so an internal disposition does not erase their original meaning.

What about a recent-data fallback?

The current SOS response comments describe a message when live retrieval cannot complete but recent stored results are available, including a state-maintenance case.^[3] If a reviewer accepts that evidence for a specific purpose, preserve the message and explain the acceptance.

Do not remove the message or relabel the response as a successful live lookup. The analyst's decision can be valid within policy while the source limitation remains part of the record.

What about alternative business matches?

Preserve the candidates and the evidence supporting any selected entity. Cobalt's SOS response can include alternative-match information rather than a single definitive business result.^[4] Selecting an entity through manual review is an additional determination that should identify its basis.

Our no-match exception operations guide addresses the broader resolution process. The control here is to record the resolution without rewriting the earlier observation.

What should a manual disposition contain?

Require enough information to explain the decision, but keep the form focused on the actual exception. A reviewer should not have to write a general essay or choose from labels that do not fit the source problem.

A useful disposition record includes:

• Registry status fields. Keep the documented status and normalizedStatus values distinct from the reviewer's disposition.^[5]

• Evidence requirement. The specific application condition being resolved or advanced.

• Source observation. A reference to the unmodified response and relevant source facts.

• Supplemental evidence. The document, registry record or other permitted source that changed the reviewer's understanding.

• Reviewer authority. The person and policy role allowed to make this decision.

• Reason and scope. What the evidence supports and which next action is permitted.

• Conditions and follow-up. Any remaining requirement, expiration or event that triggers another review.

How should the reason be written?

State the evidence and the resulting action directly. For example: “Official record at the attached source identifies the applicant's submitted registry number; entity association accepted for this application revision.” That is an illustrative note, not a verified customer outcome.

Avoid “looks fine” or “approved by operations” without the supporting fact. Those phrases name a reaction or a team but do not explain why the evidence requirement was met.

Should the reviewer choose a source result value?

Prefer a separate disposition field. If the workflow requires an internal status such as “Resolved by supplemental evidence,” define it clearly as a lender status. Do not place it inside the stored API response or present it as a state-registry status.

How can the data model enforce that separation?

Store source observations and review decisions as different records linked to the same application requirement. Let the interface combine them for display while preserving the distinction in storage and exports.

The following structure is illustrative customer-side data. It is not a Cobalt response or a new vendor feature.

{
  "source_observation_id": "synthetic-observation-01",
  "application_revision": "synthetic-revision-02",
  "review_disposition": "resolved_with_supplemental_evidence",
  "supporting_evidence_id": "synthetic-record-03",
  "decision_scope": "entity_association_only",
  "reviewer_reference": "authorized-reviewer",
  "remaining_requirements": ["current_status_review"]
}

What does this structure prevent?

It gives the system a place to record a human conclusion without mutating the source result. It also makes the scope explicit: resolving entity association does not automatically resolve every other requirement on the application.

Enforce the permissions appropriate to your system around creating and changing these records. Knowing a source-observation identifier should not, by itself, grant a user the ability to accept an exception.

What if the loan system has only one status field?

Use a linked review record or evidence attachment that preserves the source and decision separately. The visible summary can say “Resolved by review” and point to that record. Do not force two meanings into one field simply because the current interface is limited.

Middesk's lifecycle documentation distinguishes verification from the client's later approval or rejection.^[6] That is useful category context for separating source work from a business decision, not a claim that Cobalt supplies the lender's approval engine.

How should the workflow handle an unresolved source problem?

Keep it unresolved unless the applicable requirement is satisfied through permitted evidence or an authorized, properly scoped decision. A reviewer comment alone should not turn unavailable evidence into a successful source check.

Cobalt documents a retry-ID path for SOS searches that take longer to complete.^[7] A still-running request, an inconclusive identity result and a source record that conflicts with application information are different situations. Route each to the next action that can resolve it.

Can a reviewer allow other work to continue?

If policy permits, record the limited action explicitly. “Continue financial analysis while current registry evidence remains outstanding” is different from “business verification passed.” Preserve the remaining condition in the application summary.

The pre-funding verification framework provides context for keeping evidence requirements tied to the decision they support. An interim action should not remove a condition that still applies before funding.

What if required evidence cannot be obtained?

Record the attempted routes, observed limitation and exact decision required from the authorized owner. The system should support that state instead of encouraging staff to select an inaccurate success label to clear their queue.

A blocked evidence task is useful information. It shows where the current process cannot support the intended decision and what must change before the task can close.

How should a reviewer use an official source record?

Attach the exact source reference and retrieval context. Compare the identifying facts relevant to the exception, then state what the record establishes and what it does not. Do not make a broad business approval depend on an unrelated field.

Cobalt's SOS schema separately represents registry identifiers, entity type, source status and several address types.^[8] Match like with like when reviewing a discrepancy. A mailing address and registered-agent address are not interchangeable simply because both are addresses.

What if a screenshot is used?

Identify when and how it was captured and which facts the reviewer inspected. Cobalt's screenshot parameter is documented as producing a short-lived URL and is not available in every state.^[9] Follow your authorized retention process when a screenshot is needed as evidence; do not assume a temporary link is a permanent record.

Keep the screenshot's purpose narrow. It can document what was displayed at capture time, but it should not be stretched into claims about every other requirement in the loan file.

What if the source later changes?

Preserve the earlier observation and the decision made from it. Add the later evidence as another event and determine whether it affects the current application or requires a new review.

Middesk's monitoring timeline describes retaining changes in business information over time.^[10] A similar principle is useful for your review history: later evidence should be traceable without erasing what supported an earlier decision.

Resolve the application requirement with evidence; do not make the source record say something it never said.

What would a defensible review history look like?

Consider an illustrative working-capital application where the initial source response did not establish a clear entity association. The analyst then obtains a current registry record using a verified identifier and state, both supported inputs for Cobalt's SOS search.^[11]

The history retains the first response, the corrected retrieval and the analyst's explanation of the association. The current review status points to the supplemental evidence, while another requirement, such as assessing the returned business status under lending policy, remains distinct.

How should a second reviewer continue the file?

They should be able to identify the original uncertainty, the evidence that resolved it, the person who made the decision and any remaining conditions. If they cannot, the first review note needs more specific references or a clearer scope.

If the second reviewer disagrees, preserve the disagreement and route it to the designated decision owner. Do not delete the earlier conclusion to make the file appear as though only one interpretation existed.

What should an export or memo show?

Include the source limitation and the manual disposition together. A shortened memo should not retain only “passed” while dropping the fact that the original response was inconclusive and the decision depended on supplemental evidence.

Test this explicitly. The exported record may be the only view available to a funding reviewer, so its language should preserve the same distinctions as the application interface.

How should you test and govern the override control?

Test an unauthorized user, a missing evidence reference, a decision beyond the reviewer's scope, a superseded application revision and a later source observation. Include an attempted edit to the stored source response and confirm the system routes the user to a separate decision record instead.

Which acceptance tests should underwriting own?

Ask underwriting to define what a permitted disposition looks like for each exception type. Engineering can then test whether the interface and stored record require the necessary evidence, authority and scope.

A numerical success rate is not enough. Review a sample of resolved cases to confirm that the evidence supports the closure reason and that remaining conditions stay visible. Use your own data to measure incomplete notes, reopened reviews and unauthorized attempts.

What should a Cobalt evaluation clarify?

Ask to inspect the actual source fields, possible result shapes, fallback messages and source references your reviewers will receive. The current documentation distinguishes source information from application decisions.^[12] Confirm the evidence available for your states and workflow without assuming a native manual-approval capability.

Middesk's quickstart similarly treats verification results as inputs to the client's business decision.^[13] Evaluate any provider using the same distinction, while retaining your own policy and permissions as the authority for manual dispositions.

Schedule a Cobalt demo with a real review requirement and a permitted example of an exception. The objective is a record that makes the source evidence, analyst reasoning and authorized next action clear to every subsequent reviewer.