Company Litigation Coverage Dossier — turn repeated litigation-search hits into one honest coverage dossier per company query

Feed this Actor a batch of litigation-search observations for the same explicit company query from your own zinin/litigation-check runs (or any compatible dataset emitting company + jurisdiction + found + cases[]), and it reconciles every distinct case identity into one coverage dossier per query — disclosing exactly how many cases the source itself claimed versus how many this Actor could actually reconcile, and never turning a full-text keyword mention into a claim that the company is a litigant.

What you get

You give this Actor a dataset (or inline list) of litigation-search observation rows — one row per company-query-per-jurisdiction search, each carrying company, jurisdiction, found, and (when a search returned hits) a cases[] array. For each distinct query (the trimmed, literal, case-sensitive company text you searched for — "Tesla" and "tesla" are two different dossiers), you receive one coverage dossier:

• jurisdictionsCovered — up to 20 jurisdictions, each with an honest outcome: cases_observed (at least one real case identified), zero_hits_confirmed (an explicit, successfully-completed search that returned an empty cases array), or incomplete. Critically, sourceReportedCaseCount (the source's OWN separately-claimed total, e.g. "23 full-text matches") is kept strictly apart from observedCaseCount (what this Actor actually reconciled into distinct case identities) — a real source can legitimately claim more than it delivered, and sourceReportedCaseCountTruncated discloses that gap rather than hiding it.
• cases — up to 25 reconciled cases, each identified by jurisdiction plus EXACT source URL, or jurisdiction plus court+case number when no URL exists — never merged on case title or date alone. Every distinct name/date/signal combination ever reported for the same case identity is preserved under observations, never last-write-wins.
• caseCount — the total number of DISTINCT case identities this Actor actually reconciled, an observed count that is deliberately never equated with any source's own separately-claimed total.
• unidentifiableCaseEntriesSkipped / malformedCaseEntriesSkipped — nested case entries with no usable URL and no court+number pair, or not a plain object at all, are excluded entirely rather than given a fabricated identity that could collide with an unrelated case.
• contradictoryRowCount — source rows that reported found: false together with a non-empty cases array (self-contradictory upstream data) are never billed and never treated as either a confirmed hit or a confirmed zero.

What this Actor deliberately does not do: it never turns a signal: "fulltext-mention" keyword hit into a claim that the query company is a litigant, defendant, or subject of an adverse judgment; it never assigns a legal-risk score or any interpretation of guilt; it never merges two cases sharing a title or date but a different URL or court+number; it never treats an ambiguous found: false + non-empty cases row as either a hit or a confirmed zero; and it never calls the network, an AI model, or the system clock inside its transform step, nor launches zinin/litigation-check or any other Actor on your behalf.

Who uses it

• Compliance and third-party risk teams running zinin/litigation-check across a vendor or counterparty watch list, who need every jurisdiction's search outcome reconciled into one queryable dossier instead of scrolling raw per-jurisdiction scrape output.
• KYC/AML analysts who need sourceReportedCaseCountTruncated surfaced explicitly before assuming a "showing up to 10" search actually captured everything the source claims exists.
• Legal operations and outside-counsel coordination teams building a defensible, evidence-first litigation-exposure review queue that never silently claims a keyword mention proves wrongdoing.
• Data engineers building a litigation-monitoring warehouse, who need a dependable post-processing step that never drops a disagreement between two observations of the same case.
• Search-term note: "litigation coverage reconciliation", "court case deduplication", "full-text mention vs confirmed litigant", and "cross-jurisdiction case identity matching" all map directly onto this Actor's identity and conflict rules.

How to run

1. Open the Apify Console and start a new run of Company Litigation Coverage Dossier.
2. Choose a source, in order of precedence (an explicit dataset wins over a run reference, which wins over the inline example):
   • Source Dataset (datasetId) — an existing Dataset from a zinin/litigation-check run.
   • Source run ID (runId) — a run ID when you don't have its Dataset ID directly.
   • Integration payload (payload.resource) — set automatically by Apify's Integrations "Actor/task run" template.
   • Source records (inline) — the prefilled real public sample: one full zinin/litigation-check observation row for the query "Tesla" in Poland, reporting 23 full-text SAOS court-judgment matches with 10 actually delivered in cases[].
3. Optionally set Max source rows (maxInputRows, default 100, up to 1000) and Max results (maxResults, default 10, up to 1000). The platform's own Max total charge USD run option is a separate, independent stop.
4. Run it. Delivered dossiers land in the run's default Dataset, one per query, each carrying sourceRowIndexes back into your original batch.
5. Read confidence, status, caseCountTruncationDetected, and contradictoryRowCount before treating a run's output as complete coverage.

Pricing

This Actor bills on the Apify Pay-Per-Event model under a single primary event, result-found, priced as a "coverage dossier." There is no start fee and no per-case charge — only a delivered, useful dossier is billed. Free diagnostics (invalid rows, source failures, contradictory rows, queries with no confirmed coverage, budget stops, empty-batch outcomes) never request the paid event.

Tier	Price per coverage dossier
Free	$0.0350
Bronze	$0.0315
Silver	$0.0280
Gold	$0.0245
Platinum	$0.0245
Diamond	$0.0245

Bronze/Silver/Gold apply Apify's standard 10%/20%/30% volume discounts off Free; Platinum and Diamond hold the Gold rate. This table states only the price actually configured on this Actor's result-found event — not a revenue or volume guarantee. A partial: true dossier (for example, one where the source's own claimed case count exceeds what was actually delivered) is still a useful, billable aggregate; only a genuinely empty, invalid, or unconfirmed-coverage outcome is free.

Input contract

{
  "items": [
    {
      "recordType": "match_observation",
      "found": true,
      "checkedAt": "2026-09-22T05:25:29.359Z",
      "company": "Tesla",
      "jurisdiction": "PL",
      "caseCount": 23,
      "cases": [
        {
          "name": "KIO 2272/11",
          "court": "NATIONAL_APPEAL_CHAMBER",
          "date": "2011-11-03",
          "number": "KIO 2272/11",
          "url": "https://www.saos.org.pl/judgments/119124",
          "signal": "fulltext-mention"
        }
      ],
      "sourceNote": "Poland — SAOS full-text judgment search. 23 full-text match(es); showing up to 10."
    }
  ],
  "maxInputRows": 100,
  "maxResults": 10
}

This example is trimmed from the Actor's own real prefill, which carries the full 10-case cases array actually delivered by zinin/litigation-check for the real public "Tesla" / Poland search — a real search where the source itself reported 23 full-text matches but delivered only 10.

Field	Type	Notes
items	array, optional	Inline source rows. Bounded to 1000 rows / 4 MiB total / 64 KiB per row.
datasetId	string, optional	Reads an existing Dataset with your run's own permissions. Overrides inline items.
runId	string, optional	Reads a run's default Dataset. No elevated access.
payload	object, optional	Apify Integrations template payload; resource.id/resource.defaultDatasetId/resource.actId.
maxInputRows	integer, default 100, max 1000	Hard cap on source rows read.
maxResults	integer, default 10, max 1000	Hard cap on paid dossiers delivered.

Recognized row shapes

Field	Role
company	Query identity — trimmed, literal, case-sensitive text. Never a verified corporate-identity claim.
jurisdiction	Grouping key within a query; free text, bounded to 80 characters, defaults to UNSPECIFIED.
found	true with non-empty cases = a hit row; false with empty cases = a confirmed-zero search; false with non-empty cases = contradictory, excluded.
cases[]	Nested array of case observations, deduped by identity within this query.
cases[].url	Primary case identity signal — exact, case-preserved string.
cases[].court / .number	Fallback case identity when no url exists — both required together.
cases[].name / .date / .signal	Display evidence per observation; date must be a real calendar date.
caseCount	The source's OWN claimed total for this jurisdiction's search — kept separate from what this Actor reconciles.
checkedAt	Source capture timestamp — feeds observedAt, never a court filing date.
partial	Upstream's own honesty signal — true here forces this dossier's partial: true.

Output examples

Every row and diagnostic below is copied verbatim (whitespace-only JSON formatting) from an actual private cloud canary run of this Actor's value-add-candidate build, whose transform.js and .actor/dataset_schema.json hashes match this Actor's current source files exactly.

Happy path — a delivered dossier disclosing a real 23-vs-10 coverage gap

Real run against the full prefilled sample (a single real observation row for the query "Tesla" in jurisdiction "PL"):

{"entityId":"query:Tesla","found":true,"status":"litigation_coverage_with_cases","action":"review_cases","confidence":"medium","query":"Tesla","jurisdictionsCovered":[{"jurisdiction":"PL","outcome":"cases_observed","observedCaseCount":10,"sourceReportedCaseCount":23,"sourceReportedCaseCountUnavailable":false,"sourceReportedCaseCountConflict":false,"sourceReportedCaseCountTruncated":true,"sourceRowIndexes":[0]}],"jurisdictionsOmittedCount":0,"caseCount":10,"caseCountTruncationDetected":true,"cases":[{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/119124","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2272/11","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2272/11","date":"2011-11-03","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120176","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 808/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 808/12","date":"2012-05-07","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120463","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1174/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1174/12","date":"2012-06-22","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120946","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1812/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1812/12","date":"2012-09-07","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/122283","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 623/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 623/13","date":"2013-04-16","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/123419","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2060/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2060/13","date":"2013-09-10","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/124062","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2907/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2907/13","date":"2014-01-08","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/124432","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 327/14","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 327/14","date":"2014-03-05","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/12947","court":"Sąd Okręgowy w Jeleniej Górze","number":"III K 14/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"III K 14/12","date":"2012-12-04","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/161581","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1197/14","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1197/14","date":"2014-06-26","signal":"fulltext-mention","sourceRowIndex":0}]}],"casesOmittedCount":0,"conflictedCaseCount":0,"unidentifiableCaseEntriesSkipped":0,"malformedCaseEntriesSkipped":0,"contradictoryRowCount":0,"observedAt":"2026-09-22T05:25:29.359Z","sourceObservationWindow":{"earliest":"2026-09-22T05:25:29.359Z","latest":"2026-09-22T05:25:29.359Z","validCount":1,"totalRowCount":1},"evidence":[{"field":"cases","value":"PL: KIO 2272/11 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 808/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1174/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1812/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 623/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 2060/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 2907/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 327/14 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: III K 14/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1197/14 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0}],"businessPartial":true,"sourceRowIndexes":[0],"partial":true,"sourceCoverage":{"complete":true,"reason":null,"droppedOversized":0},"product":"company-litigation-coverage-dossier","schemaVersion":"1.0","sourceDatasetId":null,"sourceRunId":null,"suppliedSourceRunId":null,"sourceRunIdVerified":null,"processedAt":"2026-09-23T07:59:22.741Z"}

This is the complete, unedited delivered dossier. confidence is medium (not a higher tier — this Actor never assigns a high confidence level for any litigation dossier, real cases or not, because a fulltext-mention search is inherently a keyword-level signal, never an independently-confirmed party record). partial: true and caseCountTruncationDetected: true are both real and load-bearing here: the actual upstream source (zinin/litigation-check, itself proxying Poland's SAOS full-text judgment search) reported 23 real full-text matches for "Tesla" but its own API only returns up to 10 per search — this Actor discloses that exact 23-vs-10 gap via sourceReportedCaseCount: 23 vs observedCaseCount: 10 rather than silently treating 10 as "all of them." None of the 10 disclosed cases claims Tesla was a confirmed party, defendant, or found liable — every one carries signal: "fulltext-mention" verbatim, a keyword hit only.

Partial path — the real, honest boundary is coverage truncation, not a deleted column

Note on this scenario's name: the "partial-columns" scenario label is a legacy naming convention carried over from other Actors in this batch; for this Actor, no column was ever deleted from the row. The real upstream search for "Tesla" in Poland has exactly this one row, and the actual, factual coverage boundary is that the source itself only returns 10 of the 23 full-text matches it separately reports finding — a genuine API/search-provider limitation disclosed via sourceReportedCaseCount/caseCountTruncationDetected, never a fabricated or edited field. Run with maxInputRows: 1, maxResults: 2 against the same real single-row batch:

{"entityId":"query:Tesla","found":true,"status":"litigation_coverage_with_cases","action":"review_cases","confidence":"medium","query":"Tesla","jurisdictionsCovered":[{"jurisdiction":"PL","outcome":"cases_observed","observedCaseCount":10,"sourceReportedCaseCount":23,"sourceReportedCaseCountUnavailable":false,"sourceReportedCaseCountConflict":false,"sourceReportedCaseCountTruncated":true,"sourceRowIndexes":[0]}],"jurisdictionsOmittedCount":0,"caseCount":10,"caseCountTruncationDetected":true,"cases":[{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/119124","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2272/11","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2272/11","date":"2011-11-03","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120176","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 808/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 808/12","date":"2012-05-07","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120463","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1174/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1174/12","date":"2012-06-22","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/120946","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1812/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1812/12","date":"2012-09-07","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/122283","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 623/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 623/13","date":"2013-04-16","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/123419","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2060/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2060/13","date":"2013-09-10","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/124062","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 2907/13","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 2907/13","date":"2014-01-08","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/124432","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 327/14","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 327/14","date":"2014-03-05","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/12947","court":"Sąd Okręgowy w Jeleniej Górze","number":"III K 14/12","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"III K 14/12","date":"2012-12-04","signal":"fulltext-mention","sourceRowIndex":0}]},{"jurisdiction":"PL","url":"https://www.saos.org.pl/judgments/161581","court":"NATIONAL_APPEAL_CHAMBER","number":"KIO 1197/14","conflict":false,"observationCount":1,"observationsOmittedCount":0,"observations":[{"name":"KIO 1197/14","date":"2014-06-26","signal":"fulltext-mention","sourceRowIndex":0}]}],"casesOmittedCount":0,"conflictedCaseCount":0,"unidentifiableCaseEntriesSkipped":0,"malformedCaseEntriesSkipped":0,"contradictoryRowCount":0,"observedAt":"2026-09-22T05:25:29.359Z","sourceObservationWindow":{"earliest":"2026-09-22T05:25:29.359Z","latest":"2026-09-22T05:25:29.359Z","validCount":1,"totalRowCount":1},"evidence":[{"field":"cases","value":"PL: KIO 2272/11 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 808/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1174/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1812/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 623/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 2060/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 2907/13 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 327/14 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: III K 14/12 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0},{"field":"cases","value":"PL: KIO 1197/14 (fulltext-mention)","rule":"case_observed","sourceRowIndex":0}],"businessPartial":true,"sourceRowIndexes":[0],"partial":true,"sourceCoverage":{"complete":true,"reason":null,"droppedOversized":0},"product":"company-litigation-coverage-dossier","schemaVersion":"1.0","sourceDatasetId":null,"sourceRunId":null,"suppliedSourceRunId":null,"sourceRunIdVerified":null,"processedAt":"2026-09-23T08:00:53.878Z"}

Because the actual real-world batch for this scenario has only one row, this dossier's business content is identical to the happy-path dossier above except processedAt — maxInputRows: 1 reads that one real row completely (sourceCoverage.complete: true), so no rows were cut short by the row-window cap in this specific run. The genuine "partial" signal for this actor's real data is, honestly, the source's own 23-vs-10 case-count truncation shown above — not a maxInputRows cutoff, because the real batch never had a second row to cut.

Failure path — the platform's own charge limit stops delivery before any row is read

Real run with Max total charge USD set to $0.005 — below the configured $0.035 Free-tier price:

{
  "product": "company-litigation-coverage-dossier",
  "schemaVersion": "1.0",
  "status": "budget_stopped",
  "reason": "Run charge limit cannot cover any result; no source was read.",
  "found": false,
  "processedAt": "2026-09-23T08:00:25.023Z"
}

Free — chargedEventCounts.result-found was 0. The charge-limit check happens before any source row is read.

Empty-source path — a batch with nothing usable in it

Real run with items: []:

{
  "product": "company-litigation-coverage-dossier",
  "schemaVersion": "1.0",
  "status": "no_results",
  "found": false,
  "reason": "no_usable_rows_in_batch",
  "sourceCoverage": { "complete": true, "reason": null, "droppedOversized": 0 },
  "processedAt": "2026-09-23T08:00:12.037Z"
}

Also free. sourceCoverage.complete: true means the Actor read the entire (empty) batch supplied.

Field dictionary

Field	Meaning
entityId	query:<literal company text>.
found	true for a useful result eligible for the result-found event; every free diagnostic row has found: false.
status	litigation_coverage_with_cases or litigation_coverage_confirmed_zero; otherwise a diagnostic status.
action	review_cases or no_action_zero_confirmed — a routing hint, never an automated decision.
confidence	medium when real cases exist, low for a confirmed-zero dossier. This Actor never assigns high — a fulltext-mention search is a keyword signal, never independent confirmation.
query	Trimmed, literal, case-sensitive company text. Never a claim of verified corporate identity.
jurisdictionsCovered / jurisdictionsOmittedCount	Up to 20 { jurisdiction, outcome, observedCaseCount, sourceReportedCaseCount, sourceReportedCaseCountUnavailable, sourceReportedCaseCountConflict, sourceReportedCaseCountTruncated, sourceRowIndexes }; exact omitted count beyond 20.
caseCount	Total distinct case identities this Actor reconciled — an observed count, never the source's own claimed total.
caseCountTruncationDetected	true when any jurisdiction's source-claimed total exceeds what was actually delivered. Forces partial: true.
cases / casesOmittedCount	Up to 25 reconciled cases, each { jurisdiction, url, court, number, conflict, observationCount, observationsOmittedCount, observations }.
cases[].observations	Up to 5 distinct { name, date, signal, sourceRowIndex } per case identity — every disagreement preserved, never last-write-wins.
conflictedCaseCount	How many cases have more than one distinct observation.
unidentifiableCaseEntriesSkipped	Case entries with neither a usable URL nor a court+number pair — excluded entirely, never billed, never given a fabricated identity.
malformedCaseEntriesSkipped	Case entries that were not plain objects at all — excluded entirely.
contradictoryRowCount	Source rows reporting found: false with a non-empty cases array — self-contradictory, never billed as a hit or a zero.
evidence	Up to 12 { field: "cases"/"jurisdiction", value, rule, sourceRowIndex } entries; rule is case_conflict, case_observed, or jurisdiction_zero_confirmed.
observedAt / sourceObservationWindow	Real latest/earliest valid checkedAt across contributing rows — a capture time, never a court filing date.
sourceRowIndexes	Offsets into your original batch that produced this dossier.
partial	true when caseCountTruncationDetected, any display cap was hit, a source row flagged partial, or a contradictory row was excluded from this query.
sourceCoverage	{ complete, reason, droppedOversized } — whether the reader saw your entire configured row window this run.
product / schemaVersion	Fixed identifiers for schema pinning.
processedAt	When this Actor processed the row — never a court filing date or source capture time.

Diagnostics (never billed): invalid_row, missing_query, source_row_failed, contradictory_found_false_with_cases, incomplete_search_row, no_confirmed_coverage (accepted rows existed for a query but produced neither a real case nor an unambiguous confirmed-zero search), no_results, budget_stopped, or the run-level max_results_reached summary row.

Evidence and boundaries

Source correspondence is checked when run metadata is accessible: a proven run/Dataset mismatch is rejected. If metadata is inaccessible but an explicit Dataset is readable, processing can continue with sourceRunIdVerified false. Only source requests use GET; SDK output and billing perform writes. Diagnostic delivery is bounded to200 rows and64KiB per row; the summary records truncation/oversized omissions. Storage failure can prevent OUTPUT/SUMMARY persistence, and ambiguous writes may leave raw rows above confirmed counters. A run cap below one result stops before source reading; a cap covering part of the batch can deliver that part.

What "found" means. A delivered dossier requires found: true, a real query, and at least one real case OR at least one unambiguous, explicitly-completed empty search. A query bucket with accepted rows but neither is a no_confirmed_coverage diagnostic, not a billable dossier.

A confirmed zero is strict. zero_hits_confirmed requires found: false AND an explicitly empty cases array in the same row. found: false with a non-empty cases array is contradictory upstream data — never a confirmed hit, never a confirmed zero, always excluded and tracked via contradictoryRowCount.

Case identity is never title/date-based. Two cases with the same name and date but a different URL (or a different court+number) stay distinct. A case with neither a URL nor a court+number pair has no established identity at all and is excluded entirely — never billed, never given a synthetic row-index identity that could accidentally collide with an unrelated case.

Source-claimed totals are never equated with observed totals. sourceReportedCaseCount (what the source itself separately claims, e.g. via a caseCount field) is always kept apart from observedCaseCount (what this Actor actually reconciled into distinct identities). A real source can legitimately claim more cases than it delivers — this Actor discloses that gap via sourceReportedCaseCountTruncated rather than silently presenting a partial list as the complete picture.

A fulltext-mention is evidence of a keyword hit, never a legal conclusion. Every signal value (such as "fulltext-mention") is passed through verbatim as evidence text. This Actor never reinterprets it as proof the query company is a litigant, guilty, or subject to an adverse finding — and it never assigns a confidence: "high" dossier for this reason, regardless of how many cases are reconciled.

Charge limits are checked before any row is read. This Actor reads at most maxInputRows rows and delivers at most maxResults dossiers, independent of the platform's own Max total charge USD, verified to cover at least one dossier before any row is read; if not, it stops with the free budget_stopped diagnostic.

Delivery is a dataset write, then an explicit charge — not transactional, never guaranteed exactly-once. Every delivered dossier is written to your run's Dataset before the result-found charge event is requested. This Actor fails closed on any ambiguity, and never automatically retries a possibly-already-charged write. The own-run guard only prevents resurrection within the same run — re-running against the same input performs genuinely new processing and can bill again.

Source resolution precedence and permissions. An explicit datasetId/runId and an Integrations payload.resource reference must agree when both are present. A runId is read with your own run's own granted permissions — no elevated access, no upstream Actor started. The Source Dataset field's resourcePicker READ-only grant — not a bare webhook payload — is what allows a private Dataset read. Every source read (dataset items, run lookup) is a bounded, read-only GET against the fixed https://api.apify.com origin — that is a claim about source reads only. The Apify SDK's own dataset writes, key-value store writes, and the pay-per-event charge call that deliver this Actor's results are separate write operations, never GETs.

Bounded everything, always. 1000 source rows / 4 MiB total input / 64 KiB per row. cases capped at 25, jurisdictionsCovered at 20, observations per case at 5, evidence at 12 — each with an exact omitted count and forced partial: true when nonzero.

What this Actor cannot verify. It cannot confirm any case actually resolved against the query company, that the query text refers to a specific verified legal entity, or that a jurisdiction's coverage is exhaustive — only that the search rows you supplied were reconciled honestly.

Decision routing

1. litigation_coverage_confirmed_zero / confidence: "low" — no real case exists for this query, but at least one jurisdiction has an unambiguous, explicitly-completed empty search.
2. litigation_coverage_with_cases / confidence: "medium" — at least one real, identified case was reconciled for this query. This is the ceiling confidence level for this Actor — a fulltext/keyword-mention search is never independently confirmed, so confidence: "high" is never assigned regardless of case volume.

Route accordingly: low → safe to treat as "no coverage found in the jurisdictions searched," while remembering this only reflects the jurisdictions your batch actually searched. medium → route to a human review queue before treating any case as proof the query company is a litigant — check evidence[].value and cases[].observations for the exact keyword-hit context, and always check caseCountTruncationDetected before assuming the case list is complete.

Commercial playbooks

Vendor and counterparty litigation-exposure screening. Run zinin/litigation-check against a vendor onboarding list across your target jurisdictions, feed the dataset through this Actor, and route litigation_coverage_with_cases dossiers with caseCountTruncationDetected: true to a compliance analyst who can decide whether deeper manual research is warranted.

KYC/AML evidence-first review queue. Insert this Actor immediately after any litigation-search scraper, before rows reach your case-management system. Every case retains its exact source URL and keyword-hit signal, so an analyst can verify the underlying document before any decision is made.

Cross-jurisdiction coverage gap analysis. Feed multi-jurisdiction search results for the same query through this Actor to see, in one place, which jurisdictions returned confirmed zero hits versus which returned real cases versus which searches never completed — jurisdictionsCovered[].outcome makes the difference explicit rather than leaving gaps silent.

Periodic re-screening on a schedule. Re-run zinin/litigation-check against your watch list quarterly and diff each query's caseCount/jurisdictionsCovered against the prior run's dossier to spot newly-appearing full-text mentions — remembering that a new run is new processing and bills again, since there is no cross-run deduplication.

Integration recipes

Chained via Apify Integrations. Add an "Actor/task run" integration on your zinin/litigation-check Task, mapping {{resource.defaultDatasetId}} into Source Dataset.

Direct API call (Authorization header required). POST https://api.apify.com/v2/acts/zinin~company-litigation-coverage-dossier/runs?maxTotalChargeUsd=0.75 with { "datasetId": "<upstream dataset id>", "maxInputRows": 200, "maxResults": 20 }. Poll GET /v2/actor-runs/<runId>, then read GET /v2/datasets/<defaultDatasetId>/items.

Webhook-notified pipeline. Attach a webhook for ACTOR.RUN.SUCCEEDED; treat the payload as a "go read now" signal and fetch rows via the Dataset API with your own token. Define with doNotRetry: true, no embedded credentials.

MCP / agent tool use. Pass the same datasetId/runId/items + maxInputRows/maxResults shape. Surface status, confidence, caseCountTruncationDetected, and contradictoryRowCount directly to distinguish "safe to summarize" from "needs a human to review the underlying documents first."

This webhook registration is a template, not a captured dispatch. Configure the destination’s explicit Dataset READ grant; the payload alone cannot authorize access.

{
  "eventTypes": [
    "ACTOR.RUN.SUCCEEDED"
  ],
  "condition": {
    "actorId": "<UPSTREAM_ACTOR_ID>"
  },
  "requestUrl": "https://api.apify.com/v2/acts/zinin~company-litigation-coverage-dossier/runs?maxTotalChargeUsd=0.75",
  "headersTemplate": "{\"Authorization\":\"Bearer <YOUR_APIFY_TOKEN>\"}",
  "payloadTemplate": "{\"datasetId\":\"{{resource.defaultDatasetId}}\",\"payload\":{\"resource\":{{resource}}},\"maxInputRows\":100,\"maxResults\":2}",
  "doNotRetry": true
}

Operating guide

• Start with the real prefill to confirm the delivered shape before pointing this Actor at your own dataset.
• Combine every jurisdiction's search rows for the same query into one batch before running — jurisdiction coverage is only reconciled within the same run's bucket for that query.
• Set maxInputRows/maxResults to your real batch size, larger than the defaults meant for a first test.
• Always set the platform's own Max total charge USD for any unfamiliar batch size.
• Treat caseCountTruncationDetected: true as a research prompt, not a completeness claim — it means the source itself found more than it delivered; deeper manual search on the source may surface additional real cases.
• Never present a litigation_coverage_with_cases dossier as proof of wrongdoing — every case is keyword-hit evidence pointing at a real document, and the human reviewing it is responsible for the legal interpretation.

FAQ

Does this Actor search court records or litigation databases itself? No. It is a pure post-processing reconciliation over rows you already have from zinin/litigation-check or a compatible source.

Why did I get a no_confirmed_coverage diagnostic instead of a dossier for a query I know has real search rows? Because every accepted row for that query was neither a real hit (found: true with non-empty cases) nor an unambiguous, explicitly-completed empty search (found: false with an empty cases array).

What does it mean if sourceReportedCaseCount is higher than caseCount? The source itself claimed more matches exist than it actually delivered in cases[] — a genuine search-provider limitation (e.g. "showing up to 10"), disclosed via caseCountTruncationDetected: true, never hidden.

Does a case appearing in this dossier mean the query company was found liable or is a party to that case? No. Every case's signal field (such as "fulltext-mention") is passed through verbatim. This Actor never reinterprets a keyword hit as a confirmed legal outcome, party status, or wrongdoing.

What happens to a row that reports found: false but still has cases listed? It is treated as contradictory upstream data — excluded from both the hit count and the confirmed-zero count, tracked in contradictoryRowCount, and forces partial: true on the query's surviving dossier if one exists.

Will running this Actor again on the same dataset cost me twice? Yes, if the same queries still qualify. There is no cross-run deduplication, only a same-run resurrection guard.

Sources and rights

This Actor processes only litigation-search observation rows you supply — your own zinin/litigation-check runs, or a compatible source. It holds no independent relationship with any court, registry, or judgment database and performs no live searches of its own.

Related public Store Actors, verified against Apify's public Store search:

• zinin/litigation-check — the primary own-ecosystem source for litigation full-text-mention search rows.
• zinin/company-registry-enricher — Company Registry Enricher, a related own-ecosystem Actor for corporate-identity context on the same query company; a separate research pass, not a compatible input source for this Actor.
• zinin/sanctions-screening — Sanctions Screening, a related own-ecosystem Actor for sanctions-list exposure context; likewise a separate context, not a compatible input source here.
• nexgendata/court-records-search — Court Records Search, US Public Case Data API, a related public source for broader US court record types.
• nexgendata/legal-mcp-server — Legal Data MCP (case law, dockets & filings for AI agents), a related public tool for agent-based legal research.

Public examples here are curated, provenance-tagged projections of actual public source runs — every query, case URL, and court/case number traces back to a real upstream Actor, run, and Dataset. No personal data (dates of birth, home addresses, nationality, or personal contact details) is present in any of the curated public examples above. This Actor passes case names, court identifiers, and keyword-hit signal text through verbatim from whatever source rows you supply — a real litigation record can legitimately name a natural person (an individual co-defendant or litigant) — so it makes no universal guarantee that every real-world run's output is free of personal data. You are responsible for confirming your own source's terms and any data-protection obligations that apply to the rows you feed in.