Executive Summary: Cobalt cachedData can provide a useful interim Secretary of State record while a live search is still running, but that stored observation does not include a current state-page screenshot. Lenders should preserve the exact cached payload, source, and age when it arrives, then attach any requested screenshot or source-page artifact only to the later live observation that produced it. Mixing the two phases creates a more serious evidence problem than having no interim image at all.
Why Does cachedData Arrive Without a Live Screenshot?
What kind of artifact is cachedData?
It is a stored structured observation made available during an incomplete live request. The feature can return fields such as title, status, normalized status, registration state, and updatedAt while the live state search continues. It does not represent a current page capture.
Cobalt's public guidance distinguishes cached and live responses by their source and timing.[1] The new interim branch keeps that distinction even though both observations may contain familiar business fields.
Why is an image not expected at that moment?
A current screenshot requires the live source-page interaction that has not completed yet. Cobalt's screenshot guidance explains that screenshots or documents depend on the state and returned lookup path rather than appearing in every response.[2]
Structured cached data and a live page capture are different evidence objects with different provenance.
Do not generate or attach a substitute image that looks like a state page. A lender-created rendering of JSON may help internal readability, but it is not a live source screenshot and must be labeled accordingly.
What Should Be Preserved When the Interim Record Arrives?
Which raw fields matter?
Retain the exact incomplete response or approved raw subset, the cachedData array, updatedAt, receipt time, top-level status, retryId, search inputs, and provider source label. Preserve original strings before customer normalization so later reviewers can explain a mapping difference.
Cobalt says cached records carry timestamps that consumers can use for their own recency decisions.[3] Store the raw timestamp and the evaluated age rather than replacing one with the other.
Which derived fields may be added?
Add customer-owned observation identity, calculated age, policy version, match-rule result, display permission, and a hash if the lender uses one for change-detection checks. Keep derived values in a separate layer so nobody mistakes them for provider fields.
• Observation ID. Stable pointer to the retained cached record.
• Source type. Explicit value such as cobalt_cached_interim.
• Provider update time. Raw and parsed updatedAt.
• Customer receipt time. When the response entered the lender system.
• Policy result. Named interim permission or rejection.
• Artifact availability. live_screenshot_available: false for this phase.
These labels are examples for the lender's system, not additions to Cobalt's API schema.
Retain schema version and content type with the raw response. The public Cobalt SOS reference defines the provider request and response surface,[4] while the new feature brief defines the interim fields being released. Version-aware storage lets a later parser distinguish a provider payload from a customer-derived record without mutating historical bytes.
How Should Evidence Objects Be Modeled?
Why should observation and artifact be separate records?
An observation contains provider data at a point in the request. An artifact is a file or capture with its own source, creation time, content type, and relationship to an observation. Storing both in one mutable business row encourages a later screenshot to appear as if it supported the earlier cached values.
{
"observationId": "obs_cached_01",
"phase": "interim",
"source": "cached",
"updatedAt": 1788994658510,
"receivedAt": "2026-09-16T08:15:00Z",
"artifacts": [],
"supersededBy": null
}When live completes, create obs_live_01 and link its returned artifacts to that observation. Do not append them to obs_cached_01.
Which provenance fields should an artifact carry?
Store artifact ID, parent live observation ID, provider or state source, retrieval time, content type, checksum if policy requires it, storage location, access class, and any provider metadata. Record whether the file is a screenshot, official document, or lender-generated rendering.
Cobalt's screenshot documentation distinguishes source screenshots and official documents and notes state-dependent availability.[2] Preserve the returned type instead of calling every file a screenshot.
Make parentage enforceable in storage. An artifact row should require a valid observation ID, and that observation should belong to the same verification request. Prevent users or background jobs from dragging a file between observations without an explicit, logged correction. If an association was wrong, retain the correction event and original reference rather than silently editing history.
What Should the Underwriter Interface Show Before Live Completion?
Which label is accurate?
Show Cached interim SOS data with record age and Live search in progress. For the artifact area, say No live screenshot yet or Live artifact pending if requested and available. Avoid Screenshot missing, which can sound like an integration failure, and avoid an empty attachment icon that looks overlooked.
The interface should not require a reviewer to infer source from the presence of fields. Cobalt's status guide makes incomplete processing distinct from completed responses.[5] Display both phase and source.
How should lender-generated views be labeled?
If the interface renders cached fields into a printable summary, label it Lender-generated interim summary, include its creation time, and link back to the observation. Do not place a state seal, browser chrome, or page URL on the summary in a way that suggests it is a capture.
Restrict download and reuse according to policy. A clearly labeled internal summary can lose context when exported, so source and pending-state language should travel with the file.
Design the empty state as deliberately as the populated state. Show when the live search began, whether an artifact was requested, and whether the current state is pending or unavailable. These are different conditions. A pending label promises only that processing continues; an unavailable label should appear only after the final response establishes that no artifact was returned.
What Happens When the Live Result Arrives?
How should the final observation be stored?
Create a new immutable live observation under the same verification request. Record the final response, receipt time, source, search inputs or their stable reference, and any returned artifact metadata. Cobalt uses retryId and callback or polling patterns to complete long-running searches.[6]
Use one idempotent terminal transition. If a poll and callback both deliver the result, they should resolve to the same observation and artifact records rather than create duplicates.
How should the screenshot be attached?
Attach it only to the live observation whose response returned or referenced it. Then show the relationship explicitly: interim cached record, later final live record, live artifact. If the live response contains no screenshot because the state or lookup path does not provide one, record that fact without fabricating a file.
Cobalt does not promise that every completed lookup includes a screenshot.[2] The evidence model must remain valid with and without one.
If artifact storage fails after the live result completes, preserve the final observation and create a separate artifact-storage exception. Do not roll the verification back to pending or attach an old image to fill the gap. Retrying storage should be idempotent and should verify checksum or provider identity before marking the artifact available.
How Should Cached-Live Differences Be Presented?
What if the structured fields agree?
Mark the final live observation as controlling and show that the interim values were consistent. Keep both timestamps and source labels. The screenshot, if returned, supports the live observation, not the earlier cache merely because the fields match.
This distinction matters when retention periods differ or when someone later views only the artifact. A direct parent link prevents the file from floating free of the response that generated it.
What if the fields differ?
Open a neutral comparison case, preserve both observations, and identify which live fields the artifact can actually corroborate. A screenshot may show a page state but may not contain every structured field or prove every identity conclusion.
Cobalt's guidance on matched fields[7] and confidence interpretation[8] supports contextual review. Neither a screenshot nor a score should independently decide the lender's identity disposition.
How Should Access, Retention, and Audit History Work?
Which events should be logged?
Log the verification request, observation creation, source, receipt time, artifact retrieval, artifact-to-observation link, viewer or system access where required, comparison outcome, and final disposition. OWASP recommends capturing event status, reason, and action while excluding or protecting sensitive data.[9]
Do not write full payloads, credentials, or private document content into general-purpose logs. Store evidence in the approved repository and log references with controlled access.
Does this create a complete legal audit trail?
Not by itself. It creates operational provenance: what arrived, when, from which phase, and what the workflow did. Legal, regulatory, contractual, and retention requirements remain lender-owned.
NIST treats log management as a lifecycle across generation, transmission, storage, access, and disposal.[10] Apply approved retention and deletion rules to both structured observations and binary artifacts.
Access policies may differ for structured status data and captured documents. Keep the linkage visible to authorized reviewers without granting every system direct file access. When an artifact expires under policy, retain only the approved metadata needed to explain that it existed and was disposed, rather than leaving a broken link that appears to be a collection failure.
How Should the Evidence Flow Be Tested?
Which cases belong in the test matrix?
Test cached data with no artifact, cache absence, live result with screenshot, live result without screenshot, official document instead of screenshot, cached-live agreement, material variance, duplicate final delivery, failed artifact storage, and unauthorized access. Verify every file's parent observation and visible label.
Also simulate a partial failure after storing the live response but before storing the artifact. The request may be final while artifact retrieval or storage is pending. Represent that state explicitly rather than moving the screenshot onto the interim record.
Include export tests. Download the lender-generated summary and any live artifact, then inspect filenames, headers, metadata, and visible labels outside the application. A correct in-app badge is not enough if the exported file loses its source and phase. Verify that access controls and expiration still apply to generated download links.
Which invariants should never fail?
An interim cached observation never claims a live screenshot. An artifact always has one source-aware parent. A lender-generated summary is never labeled as a state capture. Duplicate completion creates at most one artifact record for the same returned file. Final data never erases the cached observation that was displayed or used.
The automated audit-trail guide provides broader recordkeeping context, while the verification waterfall guide explains source layers. To map observation and artifact records into your system, schedule a demo.
Verify artifact provenance again after any storage migration.
.jpg){kind=small}
.png)