> ## Documentation Index
> Fetch the complete documentation index at: https://stockcontext.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Coverage and known gaps

> How coverage is signaled per symbol, where to query current coverage, and where the data ends.

Coverage changes as filings are ingested, so do not hard-code a count from docs copy. Query coverage from the API.

* Schema 1: use `stock_search` to resolve a security and read its coverage flags.
* Schema 2: use `stock_universe` to enumerate/filter listings, `stock_reference` with `{ "catalog": "coverage" }` for measured rates, and `stock_search` to resolve user input.

## Enumerate the universe

```bash theme={null}
curl -sS "https://api.stockcontext.com/v1/tools/stock_universe" \
  -H "X-API-Key: $STOCKCONTEXT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"coverage":"has_fundamentals","shape":"operating_company","limit":500}'
```

Rows align to `data.columns`. Page metadata reports the filtered total, returned and omitted
counts, and `next_offset`. Coverage is exactly one of `has_fundamentals`, `prices_only`, or
`discovery_only`; these markers come from published pointers and held price rows, not guesses.

## Coverage is per symbol

Every `stock_search` result carries coverage flags, so you always know before you spend a call:

```json title="stock_search coverage block" theme={null}
{
  "ticker": "AAPL",
  "is_covered": true,
  "coverage": {
    "is_covered": true,
    "stock_financials": { "available": true },
    "stock_prices": { "available": true }
  }
}
```

* **`is_covered: true`** — fundamentals are ingested and served.
* **`is_covered: false` with `ingestion_pending`** — the ticker is a real, known security whose fundamentals have not been ingested yet. This is a coverage fact, not an error; do not guess a value.

## All filer shapes

Covered filers span multiple SEC filer shapes, each with its own statement structure and extraction rules:

| Shape             | Example                             |
| ----------------- | ----------------------------------- |
| Operating company | Apple, most industrials and tech    |
| Bank              | Bank holding companies              |
| Broker-dealer     | Investment banks                    |
| REIT              | Real-estate investment trusts       |
| Insurer           | Insurance carriers                  |
| IFRS filer        | Foreign filers reporting under IFRS |
| BDC               | Business development companies      |

A response tells you the shape it applied via `data.applies_to` (for example `operating_company`). IFRS filers can return the more specific sub-shape tokens `ifrs_bank` or `ifrs_insurer` when their statement face is bank-like or insurance-like. The full router shape list is served by `stock_reference` with `{ "catalog": "shapes" }`.

In schema 2, the committed shapes catalog uses `shape` values such as `operating_company`, `bank`, `broker_dealer`, `insurer`, `reit`, `bdc`, `ifrs`, `shell_blank_check`, and `unsupported_entity_type`, with `financials_status` on each item.

## Where the data ends

StockContext is fundamentals and licensed prices — not a market-intelligence platform. None of these exist; do not imply them in UI copy or generated summaries:

* options, futures, FX, crypto
* an intraday tick stream, a consolidated real-time feed, or L2 / order-book depth
* analyst consensus, price targets, or earnings estimates
* earnings-call transcripts, news, or sentiment
* forecasts, fair-value targets, or investment advice
* non-US local listings (US-filed securities only)

Fundamentals come only from SEC filings; prices come only from a licensed feed. Provider names are never embedded in payloads. See [Concepts](/docs/concepts) for the trust model and [Clocks and provenance](/docs/reference/freshness) for the two clocks.