Data availability is not one state.

Kam should not treat every missing table as missing data. A response can omit a table for several different reasons.

The core distinction is:

source data exists
does not mean projection is ready
does not mean the current response requested it
does not mean the answer rendered it
does not mean Kam can safely compare it

This page explains the public states used by docs, /llms.txt, receipts, and the .well-known JSON contracts.

Response states

ready_nonempty

The read succeeded and returned rows.

Kam can make bounded claims from the returned rows. The answer should show source state, freshness, and caveats.

ready_empty

The read succeeded and certified zero rows.

This is different from a failed read. Kam can say there were no rows only when the read path proves that result.

not_read

Kam did not complete the source read.

Users and agents should not interpret this as no data. The answer should say the source was not read.

not_requested

The current request did not ask for this source.

Example: a generic FanDuel board may not render Polymarket comparison rows because the user did not request Polymarket or all-sources scope.

not_materialized

Source data may exist, but the product projection is not ready.

This is the key state for durable product truth. A raw source row can exist while the comparison projection is still missing or stale. Kam should block or explain the missing projection instead of guessing.

available_not_rendered

Data is ready but outside the current response scope.

Example: a generic sportsbook board can say:

Polymarket: 15/15 matched games available.
Cross-market comparison:
  available when requested with Polymarket or all-sources scope.

That does not mean Polymarket was used in the current board. It means the adjacent comparison data is available for a follow-up action.

stale

Data exists but is outside its freshness policy.

Kam can explain stale state, but should not present it as current.

blocked

The current route cannot safely make the claim.

The answer should name what is blocked and what would unblock it, such as a missing source, missing input, stale projection, or unavailable receipt.

The MLB odds example

Generic request:

Show me MLB odds

Expected active response:

responseView: odds_board
dataPlane: materialized_daily_odds_board_view
active source: sportsbook board

Correct source wording when matched Polymarket rows are available:

Sportsbook odds: FanDuel loaded for 15/15 games.
Polymarket: 15/15 matched games available.
Cross-market comparison:
  available when requested with Polymarket or all-sources scope.

This is available_not_rendered for Polymarket comparison. The board remains a FanDuel board.

Explicit cross-market request:

Show all MLB books and Polymarket.
Find the biggest deltas and chart them.

Expected active response:

responseView: market_alignment
dataPlane: materialized_cross_market_delta_view
active source: sportsbook rows plus prediction-market rows

If the projection is not ready, the state is not_materialized or blocked, even when raw source data exists elsewhere.

What agents should do

Before submitting a request, an agent should decide:

1. Which capability is needed?
2. Which source is required?
3. Which response view should render?
4. Which data availability states are acceptable?
5. Which blocked state should be shown if the read cannot complete?
6. Which typed next action should be offered?

After receiving a response, an agent should inspect:

1. The receipt type.
2. The capability ID.
3. The active response scope.
4. The requested and used sources.
5. The result state.
6. The available next actions.

Must not say

Kam should not say:

Polymarket: 0/15 games loaded.

when matched Polymarket rows are available in the durable comparison projection.

Kam should not say:

No data exists.

when the truthful state is not_requested, not_read, or not_materialized.

Kam should not say:

Best price across all books.

when only one book was loaded.

These are not copy preferences. They are product-truth rules.