Skip to main content
AI Baseline retrieves evidence from a selected knowledge base. Each base belongs to an organization and uses a domain that defines how its material is interpreted and queried. The API works across knowledge bases; the S&P 500 examples in these docs illustrate one base and one domain.

​
The three concepts

The organization and base identifiers are stable identifiers, separate from their display names. Use the exact values provided for your connection. Each base uses one configured domain. Multiple bases can use the same domain while keeping separate material and permissions. For example, two private research bases could both use the general_purpose domain; neither base gains access to the other’s documents by sharing that domain. These are illustrative bases, not additional provisioned endpoints.

​
Select a knowledge base

The URL selects the base. Credentials authorize access to that selected base; they do not substitute another dataset behind the same URL. An organization identifier in a URL identifies the owner, not necessarily the caller’s organization. For the S&P 500 example:
The complete REST endpoint paths are:
Do not add the domain ID to these URLs or send it as a query-body selector. The base’s domain is configured for that base. In S&P 500 responses, summary.domain and the metadata-filter response’s domain are sandp_500, while the base identifier in the URL is sandp500.

​
Access and shared knowledge bases

Knowing a base’s URL does not grant access. An API key can grant access to several bases, but each request is checked against the selected base’s permissions. For MCP, authorize a separate connection for each base; an OAuth grant for one base does not authorize another. Shared datasets retain their owning organization’s URL. A caller from another organization with an explicit grant uses that same URL. A private base has its own URL and permissions, even if it uses the same domain as a shared base.

​
Adapt the examples to your base

  1. Set the REST base URL or MCP connection URL to your supplied organization and base identifiers, and authenticate with access to that base.
  2. Read GET /corpus-overview, or the MCP get_corpus_overview tool, to understand the base’s available material and coverage. Overview is corpus orientation, not evidence for factual answers.
  3. For REST metadata-filtered queries, call GET /metadata-filters on that same base. Reuse only supported fields, operators, and values. SEC fields such as sec_ticker belong to the S&P 500 example and need not exist in another domain.
  4. Ask questions about that base’s material using POST /query or MCP’s retrieve_evidence_context tool. Preserve the returned evidence instructions and citation references when handing the result to a model.
The query modes and response structure use the same API contract across bases. Available evidence, metadata fields, distributions, and evidence-use instructions reflect the selected base and domain. Changing a URL does not copy data, change a domain, or grant permissions.

​
API versioning

v2 identifies the public REST request and response contract. Compatible additions stay within that major version; breaking contract changes require a new major version. Keep the explicit version in client configuration. The REST API version is independent of application releases and domain releases. It does not pin the base’s corpus contents or select a historical dataset. The MCP connection URL remains unversioned because it identifies the base and its OAuth resource. Use its exact URL without adding /v2 or /mcp. Continue with the REST quickstart or MCP connection guide.