Executive Summary: Cobalt's interim cachedData can look complete because it contains familiar business fields, yet the live Secretary of State search is still running. A safe underwriter interface must show four facts together: the record is cached, its age is known through updatedAt, the live request remains pending, and a later final result may change the record. Good labels make finality explicit instead of asking a reviewer to infer it from populated fields.
What Must the Interface Communicate at First Glance?
Which four facts belong in the primary status area?
Show source, age, process state, and permitted use. A compact status panel might read Cached interim SOS data, Updated 6 days ago, Live search in progress, and For preliminary review only. The final phrase must come from lender-approved policy, not from Cobalt.
Cobalt's source guidance distinguishes cached and live responses,[1] while its status guide distinguishes incomplete processing from terminal results.[2] The interface should display both dimensions.
Which labels create avoidable ambiguity?
Avoid Verified, Current, Complete, Official, or an unlabeled green success badge. Avoid No match when the optional interim array is absent. Avoid showing only a date without saying what the date represents.
Complete-looking fields must not produce a complete-looking status.
Write labels in plain language and pair color with text. Color alone is not enough for accessibility or for exported records that lose styling.
Place the status next to the business fields rather than only at the top of a long page. If a card can be copied, collapsed, or opened in a side panel, repeat the minimum source and phase label within that component. A reviewer should not need to remember a banner that scrolled out of view before interpreting the status field.
How Should Source and Process State Be Separated?
Why are two badges better than one overloaded badge?
Cached answers where the displayed observation came from. Live search in progress answers what the current request is doing. A single Pending cache badge can be misread as data still loading, cache being created, or verification being blocked.
Keep source attached to the record and process state attached to the verification request. That model remains clear when the final live observation arrives.
What should happen when cachedData is absent?
Show Live search in progress and No interim cached match available. Do not show an empty result table under a No results heading. Cobalt's cache-miss guidance says absence from a cached lookup does not prove absence from the state registry.[3]
Give the reviewer a next action such as No action needed while live search continues or the lender's approved exception path. This prevents repeat submissions driven by an apparently empty screen.
Keep absence visually distinct from an error. Use an informational treatment for an open live request and reserve warning or error styling for a documented exception. If the request exceeds a customer-defined waiting threshold, add an operations alert without changing the underlying business message. Time elapsed does not turn cache absence into final no-match.
How Should updatedAt Be Displayed?
Which human-readable age is useful?
Show a relative age and an exact timestamp, for example Updated 6 days ago with September 10, 2026, 08:17 UTC in the detail view. Label it Cached record updated, not Search completed or Data verified.
Cobalt tells consumers to use cache timestamps for their own recency decisions[4] and notes that update frequency varies by state.[5] The timestamp is evidence, not an approval.
How should policy status appear beside age?
If the lender applies an interim-age rule, show its result separately: Meets preliminary-review age rule or Too old for interim use, waiting for live. Include policy details for authorized users, such as action, threshold, and version.
Source: Cached interim SOS data
Record updated: Sep 10, 2026 08:17 UTC
Policy: Preliminary review allowed under policy v3
Request: Live SOS search in progressDo not display Fresh unless the organization has defined exactly what that means for this action.
Handle invalid and future timestamps explicitly. Show Record age unavailable, waiting for live and withhold age-dependent permissions. Do not replace an invalid timestamp with the current time or display Just updated. Authorized support users can inspect the raw value and parse error in the detail panel without exposing technical noise to every reviewer.
How Should Permitted and Blocked Actions Be Shown?
Which controls may remain available?
Enable only lender-approved reversible actions, such as opening a comparison, adding an internal note, or preparing a checklist. The exact list depends on product and policy. Attach permissions to the current observation and request phase, not to a general user role alone.
• Visible source. The control acts on a labeled cached observation.
• Named purpose. The action says Prepare review, not Verify business.
• Undo path. The output can be replaced or withdrawn when live differs.
• No hidden propagation. Downstream systems retain interim provenance.
• Policy reference. The interface can explain why the action is enabled.
• Event trace. The action and later reversal remain recorded.
If any condition is missing, keep the control disabled until live completion.
How should final-only controls be disabled?
Use clear copy such as Available after live SOS result rather than a disabled button with no reason. Enforce the rule server-side too. A reviewer should not be able to bypass the interface by calling another service or using a stale page.
The feature supplies data and process state; the lender owns workflow permissions and every credit consequence. The interface must not imply that Cobalt authorized an underwriting action.
Use confirmation language that names the effect. A button may say Use for preliminary comparison and a dialog may repeat Live SOS verification is still pending. Avoid a generic Accept action because it does not say whether the user accepted the record for display, identity, verification, or final decision. Persist the selected effect as a structured event.
How Should the Screen Change When Live Completes?
What should happen when the records agree?
Replace the primary status with Live SOS result complete, preserve the cached observation in history, and confirm any prepared values against the live record. If a screenshot or official document was requested and returned, attach it only to the live observation. Cobalt notes that artifact availability varies by state and lookup path.[6]
Do not silently relabel the cached card as live. That removes provenance even when the values agree.
What should happen when the records differ?
Show a comparison state with neutral language such as Cached and live records need review. Highlight material field differences without a fraud or error accusation. Keep final-only actions blocked until the lender's authorized review is complete.
Cobalt's matched-field guidance explains how returned fields can support match context,[7] and its confidence guidance warns against a universal threshold.[8] Let evidence, not color or rank alone, guide review.
Show a before-and-after comparison when a material value changes. Use original labels and stable identifiers, and let the reviewer expand unchanged fields rather than hiding them completely. Record whether interim preparation depended on the changed field. This turns the final transition into an explainable workflow event rather than a silent card refresh.
How Should Detail Views and Exports Preserve Context?
What belongs in the expandable detail?
Include request identity, search inputs, retryId for authorized support users, source, provider timestamp, receipt time, policy result, process state, field provenance, and event history. Separate raw provider values from lender-normalized display values.
Hide credentials and customer-sensitive data from general logs or screenshots. Role-based access should govern detailed provider and artifact information.
What happens when the record leaves the application?
Exports, print views, copied notes, and downloaded summaries must carry source, age, and pending-state text. A badge that disappears in a CSV or black-and-white PDF does not protect the meaning. Add explicit columns or headers.
If the lender generates a PDF from cached fields, label it as a customer-generated interim summary, not a state screenshot. Maintain a link to the original observation and creation time.
Test copy-and-paste behavior. When a reviewer copies a business record into an internal note, the application can prepend or append an approved source line such as Cached interim SOS data, live search pending. If policy does not permit copying, disable it consistently. Either route is clearer than letting data leave the card without provenance.
How Should Interface Actions Be Logged?
Which interaction events matter?
Record when the interim card was displayed, which source and policy labels were visible, which reversible action a reviewer took, whether data was exported, when the live result arrived, and how the final transition affected prior work. OWASP recommends logging event status, reason, and resulting action.[9]
Use observation and request IDs rather than copying sensitive payloads into general event logs. Keep the detailed evidence in its authorized store.
How can logs improve the labels?
Look for repeated resubmissions, clicks on disabled controls, long dwell on source details, and frequent support questions. These may reveal unclear copy or missing next actions. Measure behavior before claiming that a label reduces errors.
NIST describes log management across generation, storage, access, and disposal.[10] Retention and monitoring choices remain the lender's responsibility.
Link interaction events to the observation version shown at that moment. If live data arrives while the page is open, a later click should either use the new version or be rejected as stale. The log should identify which version the reviewer actually saw so a later investigation does not assume the final fields were visible earlier.
How Should the Interface Be Tested Before Release?
Which state fixtures are required?
Test incomplete with cached data, incomplete without cached data, age pass, age fail, invalid timestamp, live agreement, live variance, final no-match, artifact present, artifact absent, duplicate delivery, and terminal error. Capture both the visible status and enabled actions.
Test stale browser sessions too. Open the cached card, complete the live request in another session, then attempt an interim action. The server must reject or recompute the stale permission and prompt the user to refresh.
Include keyboard navigation, screen-reader output, high-contrast mode, narrow screens, translated copy if supported, print views, and exported files. Read the status in the order assistive technology encounters it. Source and pending state should precede action controls, so a user does not activate a task before learning that the record is interim.
Which people should review the language?
Include underwriting operations, compliance or legal stakeholders as appropriate, support, product, engineering, and accessibility review. Ask each person what the status means, what can happen next, and whether any label implies more certainty than the evidence provides.
The verification waterfall guide explains the wider source model, and the audit-trail guide covers operational history. To map these states into your underwriter interface, schedule a demo.
.jpg){kind=small}
.png)