diff --git a/web-search-api/api-reference/catch-all-api.yml b/web-search-api/api-reference/catch-all-api.yml
index a033f7f..d0d76da 100644
--- a/web-search-api/api-reference/catch-all-api.yml
+++ b/web-search-api/api-reference/catch-all-api.yml
@@ -1,7 +1,7 @@
openapi: 3.1.0
info:
title: NewsCatcher CatchAll API
- version: 1.9.0
+ version: 1.10.0
description: |
CatchAll is a web search API that generates unique datasets that don't exist anywhere else on the web. Built on NewsCatcher's proprietary real-world event index, it delivers state-of-the-art recall—finding all relevant events, not just top results.
diff --git a/web-search-api/concepts/company-monitors.mdx b/web-search-api/concepts/company-monitors.mdx
index 9d0ec30..4b37cb5 100644
--- a/web-search-api/concepts/company-monitors.mdx
+++ b/web-search-api/concepts/company-monitors.mdx
@@ -197,6 +197,13 @@ industry**, **headquarters location**, **founding year and founders**, and
**concrete products or services**. Generic adjectives ("leading," "innovative,"
"world-class") carry no disambiguating signal — drop them.
+
+ When a company name or alias is a common word, such as "Apple" or "Target",
+ CatchAll matches it using named-entity recognition instead of searching for
+ the word anywhere in article text. This reduces false matches from ordinary
+ uses of the word.
+
+
Before saving: *Could this description be true of a different company with the
same name?* If yes, add the attribute that breaks the tie — usually industry,
@@ -1169,6 +1176,14 @@ results.getAllRecords().forEach(record -> {
+### Records per company
+
+Connected jobs cluster articles separately for each company in the dataset, so
+articles about different companies never end up in the same record. When an
+article covers several companies from your watchlist, each of those companies
+can get its own record built from that article. Articles with no connected
+company are clustered together.
+
## See also
- [Jobs](/web-search-api/concepts/jobs)
diff --git a/web-search-api/concepts/jobs.mdx b/web-search-api/concepts/jobs.mdx
index bf78541..77e119d 100644
--- a/web-search-api/concepts/jobs.mdx
+++ b/web-search-api/concepts/jobs.mdx
@@ -250,7 +250,8 @@ System.out.println("Job created: " + jobId);
returns the current processing stage. Poll every 30-60 seconds until status is
`completed`. Jobs typically take 10-15 minutes.
-Jobs progress through these stages in order:
+Jobs progress through these stages in order. A job can repeat `fetching`,
+`clustering`, and `enriching` when it moves to a new [search turn](#search-turns).
| Stage | Description |
| ------------ | ------------------------------------------------------ |
@@ -375,6 +376,20 @@ while (true) {
without waiting for completion. See [Get job results](#get-job-results) below.
+### Search turns
+
+CatchAll searches in up to four turns. The first turn runs a strict precision
+search that matches your query against article titles and summaries. If the job
+runs out of candidates before reaching its `limit`, it moves to the next turn,
+which searches a broader set of sources and repeats `fetching`, `clustering`,
+and `enriching`. The job completes when it reaches the limit or finishes the
+last turn. Jobs without a `limit` can run all four turns.
+
+Because of this, a job can return to `fetching` after `enriching`. Treat this
+as continued progress on the same job, and keep polling until the status is
+`completed` or `failed`. Records from earlier turns keep their IDs; articles
+found in later turns can be added to them as new citations.
+
## Get job results
[`GET /catchAll/pull/{job_id}`](/web-search-api/api-reference/jobs/get-job-results)
diff --git a/web-search-api/get-started/changelog.mdx b/web-search-api/get-started/changelog.mdx
index b04ab78..fbbb69f 100644
--- a/web-search-api/get-started/changelog.mdx
+++ b/web-search-api/get-started/changelog.mdx
@@ -5,6 +5,46 @@ description: Track updates, improvements, and fixes to the CatchAll API.
rss: true
---
+
+## Multi-turn search and per-company clustering
+
+A quality release with no request or response schema changes. Jobs now start
+with a narrow precision search and widen only when they need more results, so
+small jobs finish faster. Company Monitors results no longer mix different
+companies in the same record. Existing jobs and event monitors pick up these
+changes automatically.
+
+### Multi-turn search
+
+Jobs now search in up to four turns. The first turn runs a strict precision
+search that matches your query against article titles and summaries. If the
+job runs out of candidates before reaching its `limit`, it searches the next,
+broader set of sources and runs fetching, clustering, and enrichment again. The
+job completes when it reaches the limit or finishes the last turn.
+
+- Jobs with a low `limit` often finish after the first turn, in around four
+ minutes.
+- Records you already pulled keep their IDs and content. Articles found in later
+ turns can join existing records as additional citations.
+- A job can return to `fetching` after `enriching`. Keep polling until the
+ status is `completed` or `failed`. See
+ [Jobs](/web-search-api/concepts/jobs#search-turns).
+
+### Per-company clustering for Company Monitors
+
+Jobs submitted with `connected_dataset_ids` now cluster articles separately for
+each connected company, so articles about different companies no longer end up
+in the same record. An article about several companies from your watchlist can
+produce a record for each of them. See
+[Company Monitors](/web-search-api/concepts/company-monitors#records-per-company).
+
+### Fixes and improvements
+
+- Fewer false matches for companies whose name or alias is a common word. For
+ these names, matching relies on named-entity recognition instead of matching
+ the word anywhere in article text.
+
+
## Paused event monitor alerts and better watchlist recall