Court Search Results Have Different Detail Levels: Do Not Review Every Hit as a Full Case

Executive Summary: A court-search response can contain records with different levels of detail. Cobalt's current New York example gives the first result more fields and documents, while later results contain top-level information.^[1] Review each hit according to the evidence actually available, and obtain missing case detail before drawing a credit conclusion.

What does a court search hit establish?

It establishes that the search returned a record within its submitted scope. The next questions are whether the record concerns the intended business, what the case information actually says, and whether there is enough detail for the lender's review.

Do not combine those questions into one “court hit” flag. A thin record can justify further investigation without establishing a judgment, a current obligation or misconduct by the applicant.

Why can detail vary within one response?

Cobalt's documented New York response example explicitly distinguishes the more detailed first result from subsequent top-level results.^[2] Your parser and analyst interface should therefore allow records in the same array to have different evidence states.

The practical mistake is applying the interpretation supported by the first object to every later object. If one result includes documents and another does not, the second record has not acquired those documents merely because both arrived in a successful response.

Does the first result have special evidentiary weight?

The example's greater detail is not proof that the first result is the correct borrower or the most material case. Establish identity and relevance using the available source information and any necessary follow-up.

Avoid interface sorting that implies an unsupported risk ranking. “More fields returned” describes response detail; it is not a finding about credit exposure.

Which fields should the reviewer inspect first?

Begin with the submitted business name and jurisdiction, then identify the source record and parties. Cobalt's court endpoint requires businessName, jurisdiction and callbackUrl; its documented jurisdictions are New York and Miami-Dade.^[3]

Keep that scope visible. A result from one supported jurisdiction should not be presented as a nationwide court-record assessment.

What does the New York example contain?

The more detailed example includes a source URL, status, caption, case type, documents, case details and party fields. Subsequent example results include only top-level fields such as URL, status, caption and case type.^[4]

Preserve the source field names and values before creating a lender-facing summary. The summary should say what was obtained and what remains to be checked, rather than filling missing fields with a presumed outcome.

Should Miami-Dade use the same parser assumptions?

No. The current Miami-Dade example uses a different shape, including case information, status, filing date and case-number fields.^[5] Build and test jurisdiction-specific mappings against the documented response rather than forcing every result through the New York example.

A normalized internal view can be useful, but it must retain the source context and any fields that could not be mapped safely. An empty normalized field should not become a factual claim that the source has no such information.

How should the workflow classify evidence depth?

Use labels that describe the next review action. Your application can track identity confidence, source-detail availability and reviewer disposition separately without pretending that any one of them is a complete risk decision.

An evidence checklist might include:

• Submitted scope. Retain the business name and jurisdiction required by the documented court request.^[6]

• Search scope retained. The submitted business name and jurisdiction are linked to the request.

• Source record identified. The relevant URL or case reference is preserved for follow-up.

• Party association reviewed. The available party information has been compared with the applicant evidence.

• Detail sufficient for the question. The fields and documents needed for the specific review have been obtained.

• Procedural meaning checked. The reviewer distinguishes a filing, allegation, decision and entered judgment where relevant.

• Disposition recorded. The authorized lender reviewer states the next action and unresolved limits.

New York Courts explains that a court decision becomes an entered judgment through a separate clerk action.^[7] That is one example of why a generic case label should not be expanded into a legal conclusion without inspecting the relevant record.

What should a thin hit look like in the interface?

Show the available case reference and a clear “Additional detail required” state when the lender's question cannot be answered from the returned fields. Provide the next retrieval action and a named owner.

Do not display empty document arrays as “No adverse documents.” The response may simply lack detail. Keep absence of returned information separate from a verified absence in the source record.

How can engineering avoid accidental enrichment by assumption?

Retain the raw result and classify the presence of evidence explicitly. Do not copy fields from the first result into later results, infer parties from a caption without review, or treat an omitted document list as an affirmative clean finding.

The following is illustrative customer-side classification using the New York example's field names. It is not a complete parser or a legal-review engine.

def detail_state(hit):
    documents = hit.get("documents")
    has_documents = isinstance(documents, list) and len(documents) > 0
    has_case_details = bool(hit.get("caseDetails"))
    if has_documents or has_case_details:
        return "detail_available_for_review"
    if hit.get("url") or hit.get("caption"):
        return "top_level_hit_requires_follow_up"
    return "response_shape_review"

Does detail available mean review complete?

No. It means the application has information for a reviewer to inspect. Documents may still be irrelevant, inaccessible, incomplete or associated with another party. Keep the human interpretation and lender action separate.

Cobalt documents document names, URLs, filing-party information and document-status fields in the detailed New York example.^[8] Use those references to support review rather than assuming the existence of a document settles the case's meaning.

Can the API automatically enrich every thin hit?

The current court request documentation does not describe a separate per-hit enrichment endpoint.^[9] Confirm any additional supported retrieval route before building around it. Do not invent a detail request by changing an identifier in an undocumented URL.

When the API response is insufficient, use an authorized source-court process or another verified evidence route appropriate to the jurisdiction.

How should the analyst obtain the missing case detail?

Start from the source reference and the specific question. The reviewer may need the parties, a particular filing, an entered judgment or later case activity. Record that target so retrieval does not become an unbounded search through every document.

New York Courts provides guest access to Supreme Court cases and documents filed in NYSCEF through its case-record search guidance.^[10] Follow the appropriate court's current access process and retain the exact record used.

What should the retrieval note contain?

Identify the jurisdiction, case reference, document or record obtained, retrieval date and the unresolved review question it addresses. Preserve the distinction between an official source record, an API response and borrower-supplied material.

Our guide to reading civil court dockets provides broader interpretation context. This workflow adds an earlier check: whether the search hit supplied enough detail to attempt that interpretation at all.

What if access is limited or the record cannot be found?

Record the limitation and assign the next permitted route. Do not turn unsuccessful retrieval into a statement that the case has no relevant documents or that an allegation was dismissed.

The lender's policy should define what evidence is required for its decision. Where the source material cannot support that decision, retain the unresolved state and identify the exact evidence or authorized judgment needed next.

What does a worked multi-hit review look like?

Consider a hypothetical search returning three New York records. The first has documents and party details; the second and third have only a caption, status and source reference. These are illustrative records, not an observed borrower case.

The reviewer checks the applicant association for each result. The detailed first hit may concern another business with a similar name. One thin hit may be the relevant applicant record but require document retrieval before the credit question can be answered.

What should the comparison table show?

For each hit, show its source reference, party-association status, detail availability and next action. Do not group all three under the interpretation reached for the first one.

If the first hit is excluded, preserve the evidence supporting exclusion. If a later hit remains unresolved, keep its task open even though another result has already been reviewed. The application summary should reflect the actual set of review requirements.

What should the final note avoid?

Avoid saying the borrower “has a judgment” unless the relevant source establishes an entered judgment against the correctly identified party. Avoid describing a case as paid, dismissed or irrelevant without the supporting record.

The New York County Clerk separately provides records concerning satisfaction of judgments.^[11] The existence of a search hit cannot substitute for those procedural facts.

A thin hit should trigger a precise evidence question, not a thick conclusion.

How should the team test the different response shapes?

Use synthetic fixtures that match the documented jurisdiction-specific examples. Include a detailed first result, thin subsequent results, an empty document list, an inaccessible source URL, an ambiguous party association and an unexpected field shape.

Test a reordered array. If the same record moves from first to later position, the application should still interpret the fields actually present rather than assigning detail or relevance based on array position.

What should the delayed-result test prove?

The court endpoint documents an initial response saying the completed request will be sent to the callback URL.^[12] Confirm that the initial acknowledgment does not create a completed court review or an empty clean-result display.

Attach the eventual result to the correct application and submitted search. A late response for earlier inputs should not overwrite the evidence associated with a corrected borrower record.

How should operations assess the workflow?

Measure your own unresolved detail tasks, retrieval effort and closure reasons. Separate incorrect-party exclusions from insufficient-detail cases and completed reviews. Those categories describe different work and should not be treated as one generic court-hit rate.

Ask a second reviewer to reconstruct a sample disposition from its source references. If the conclusion relies on information not present in the retained evidence, reopen the note before treating the task as complete.

What should a Cobalt evaluation demonstrate?

Bring a permitted multi-hit scenario and the exact questions your underwriting team needs answered. Ask to inspect the detailed and top-level New York records, the Miami-Dade shape, callback delivery and the source references available for follow-up.

When evaluating alternatives, inspect their actual legal-record model. Middesk's legal-record documentation, for example, describes case identifiers, party roles and judgment-related docket entries.^[13] Compare the evidence needed for your use case rather than assuming every court-search product returns identical detail.

The pre-funding business-verification framework can help place the court review within the wider evidence process. Keep the court result's coverage and procedural limits visible where the lending decision uses it.

Schedule a Cobalt demo with that scenario. The acceptance criterion is that every hit receives the review its actual evidence supports, with a clear retrieval path when the response is too thin to answer the question.