Automatic search
One question, one answer. The service answers with a one-pass fact search or an agent that reads documents, queries tables, and selects documents from the metadata catalog, and returns that route’s result (with a catalog table when the agent answered from the catalog), plus which route it took. Single-shot: no session and no clarification question back. Passmode fact or agent to run that route directly, with
no routing step.
QA
A conversation instead of a single query. Each turn runs the automatic search agent on its own; pass a result’sanswer.session_id to ask a follow-up, and
the agent may ask back on a genuinely ambiguous question. Chain follow-ups with
that conversation’s session; do not share a session across unrelated
questions.
Ground quote locations
Search does not wait for bounding boxes. After a succeeded answer, poll every id in itsgrounding_job_ids: on output for an automatic search answered by
the fact route, on output.answer when the agent answered, on answer for a
QA turn, and on the result itself for journal-entry testing. Do not
POST /v1/ground for those evidences.
postprocessing="none" or no
groundable evidence). A missing field is a job from before this field
existed — only then call Ground.
Catalog tables
When automatic search’s agent, or a QA turn, answers a filter, rank, or count question from the metadata catalog, the result carries acatalog table:
typed columns, one row per matching catalog entry, and exact totals.
Search returns matching catalog entries with identities established from the
source data. Native register entries stay separate; supporting sections keep
their own values and citations in components. total_matches counts entries
and total_files counts their distinct source files. Both totals describe all
confirmed matches before top-N and paging. Each row has a query-independent
entry_id in the current catalog and a source_file_id for its supporting
uploaded file. See the API reference for
identity behavior on rebuild.
You can also ask for fields to show beside each match. These columns carry
requested=true. Missing output values remain unexamined without removing the
entry; conditions that filter on those values must still be satisfied.
A table carries up to 200 rows. When there are more, next_cursor pages the
rest: client.search.filtered_page in Python, or
POST /v1/workspaces/{id}/filtered-search with
{ "type": "page", "cursor": "..." }. A page is a new job and re-runs the
table’s query against the current catalog.
exhaustive before treating a table as a census. catalog_drifted on a
later page means the catalog changed since the first page.
Journal-entry testing
Not retrieval. The run writes its own SQL over the ingested ledger tables and publishes every statement as a receipt, so each figure traces to the query behind it. Reach for it when the deliverable is a tested criterion rather than a cited passage.- Python
- TypeScript
- curl
effort on je-testing is the one knob (low / medium / high); omit it to take the
deployment’s own floor. figures is the checkable half of the answer;
sql_receipts is its working. exhausted means the step budget ran out before
the procedure finished — a partial answer, not a failure. Full field reference:
Python, TypeScript.
Deprecated: fact, deep, and filtered search
These keep working, as do their endpoints, until they are retired. New code should not start on them.
See Fact and deep search and
Filtered search for their reference.
Coverage
Every search response can includecoverage.restricted_candidates and
labels_required when your key cannot see every matching file. See
Access labels.