# Kam AI > Kam AI is an outcome-first React Native workspace for improving sports-market research decisions before and after a user acts. Current positioning: - React Native is the primary product surface. - The web app is the public product, documentation, blog, and support layer. - React Native starts user work, renders workspace state, and opens the right surface. - The backend owns durable runs, routing, tool policy, materialized read models, source truth, answer contracts, and production validation. - Schedulers and materializers prepare current and historical read models before chat asks for them. - Kam AI supports research, source review, saved reads, watchlists, and outcome review. It competes on decision quality and reviewable outcomes, not on being the cheapest chat surface. It is not a sportsbook, pick seller, or outcome-guarantee product. ## Public Pages - [Homepage](https://kam-ai.com): Public product overview. - [About](https://kam-ai.com/about): Founder and contact page for Kam AI. - [Support](https://kam-ai.com/support): Support paths for quick answers, issue reporting, field notes, and founder support. - [Product docs](https://kam-ai.com/docs): Task-first guides for the chat-first iOS experience and workspace-first iPadOS/macOS experience across Summary, Ask Kam, Game workspace, Watchlist, Traders, Portfolio, queries, and follow-ups. - [Query library](https://kam-ai.com/docs/queries): Copyable starting queries organized by product job. - [Follow-up guide](https://kam-ai.com/docs/follow-ups): How to narrow, verify, and act without losing the selected object. - [Kam Market Notes](https://kam-ai.com/blog): Candid articles about sports-market research problems, product tradeoffs, native Apple workflows, and backend source receipts. ## Current Kam Market Notes - [How Kam AI Builds an Outcome Edge](https://kam-ai.com/blog/kam-ai-react-native-workspace-architecture): How the React Native workspace and backend source truth improve decision quality and review. - [How Backend Data Becomes a Better Outcome](https://kam-ai.com/blog/how-kam-ai-backend-data-becomes-a-better-read): How backend receipts, source freshness, and read models become reviewable user outcomes. ## Architecture Summary React Native owns: - Summary Island - Watchlist - Ask Kam - Game workspace - Game details - Portfolio - Notifications - Settings - visible state, layout, route handoffs, and workspace actions The backend owns: - durable chat runs - intent routing - command compilation - turn contracts - conversation state - tool policy - materialized read models - answer validation - trace receipts - production validation Materialized read models should be exact-key, fail-closed, and presentation-ready. Public answers should carry freshness, missing-source state, caveats, and source receipts. ## Answer Standard - Lead with the current read. - Separate source truth from interpretation. - Show freshness, missing context, and caveats. - Teach the next outcome: track, save, compare, review, wait, or pass. - Keep final decisions human-controlled. - Do not present stale or thin data as strong confidence. - Do not describe Kam AI as primarily a web app. ## Chat Request Cycle First principles: - A chat request has two parts: the visible prompt and the request context the React Native screen attaches before sending. - The visible prompt should name the sport, team, date, source, saved read, or workspace scope before asking for interpretation. - The request context should lock the lane with sportFocus, dataSource, responseView, timeScope, bookmakerSelection, and useCase when the UI already knows those values. - The answer must separate active response scope from adjacent data availability. A generic sportsbook board can report Polymarket availability without rendering a full cross-market comparison. - Missing, stale, thin, or blocked data is a valid answer state. Kam should not fill source gaps from priors. - Every useful response should expose the current read, source state, caveat, and one next action. React Native request context fields: - surface: Names where the request came from so routing can preserve product intent. Example: summary_ask. Source: Quick prompt tiles and chat entry points. - analysisTier: Sets expected latency and depth for the turn. Example: fast. Source: Quick prompt requestContextOverrides. - serverManagedRouting: Lets the backend choose the exact lane while preserving UI intent. Example: true. Source: Quick prompts and odds-board detection. - answerSurface: Keeps the response optimized for the chat screen. Example: chat. Source: Quick prompt requestContextOverrides. - sportFocus: Bounds the source query to one sport when known. Example: baseball_mlb. Source: Controller sport selector or prompt text resolver. - dataSource: Chooses sportsbook prices, Polymarket, or a blended source path. Example: sportsbooks | polymarket | both. Source: Controller source selector. - responseView: Selects the UI/result shape the assistant should produce. Example: odds_board | all_games | market_alignment | quick_read. Source: Controller view mode or quick prompt override. - timeScope: Bounds today, tomorrow, this week, or a pinned date. Example: today. Source: Controller time selector. - bookmakerSelection: Controls best available, all books, or a named sportsbook. Example: best_available | all_books | fanduel. Source: Controller sportsbook selector. - preferredSportsbooks: Orders sportsbook reads without hiding other requested books. Example: ["fanduel"]. Source: User preference and controller state. - useCase: Names the backend product job, such as board summary or schedule count. Example: daily_odds_board_summary. Source: Prompt chip expectedIntent or odds-board detection. - pinnedDate: Freezes the date when the user is inspecting a specific slate. Example: 2026-07-12. Source: Pinned board/game state. - dailyOddsBoardReadModelRequired: Requires the materialized daily odds board instead of an ad hoc read. Example: true. Source: Explicit board-odds request detection. - platformPanelContext.dataPlane: Tells agents which durable read path must support the answer. Example: materialized_daily_odds_board_view. Source: ChatScreenUtils hot-read context. - gameHandoff: Carries selected game, matchup, book, hot-read keys, and snapshot age. Example: selected MLB game with hotRead keys. Source: Game details and game workspace handoff. - workspaceId: Keeps saved reads, artifacts, and follow-up turns in the right workspace. Example: saved workspace id. Source: Workspace session state. - promptRouteId: Records the selected route for debugging, receipts, and retries. Example: odds.board.daily. Source: attachKamPromptRouteToRequestContext. Response thread sequence: - userMessage: The exact prompt the user sent or selected from a quick prompt tile. User-visible: Yes. - agentProgress: Lifecycle labels such as Choosing route, Reading sources, Preparing structured response, and Writing answer. User-visible: Yes. - readModel: The durable read model or blocked state that backs the answer. User-visible: When relevant. - toolCall: The tool or source read used to load board rows, schedules, scores, or saved reads. User-visible: When relevant. - structuredResponse: A typed result such as a sports games table, market board, chart packet, or action card. User-visible: Rendered as UI. - agentMessage: The final explanation in plain language. Streaming deltas update the active assistant item. User-visible: Yes. - reasoning: A separate trace-style item for checked state, caveats, and verification notes. User-visible: When enabled. - artifact: A saved table, board, report, chart, watch item, or action artifact. User-visible: When created. - receipt: Source receipts, workflow receipts, freshness state, and next transitions. User-visible: When available. - decision: A route, blocked-state, approval, or next-action decision. User-visible: When needed. Kam chat requests should be understandable as: 1. Scope prefix: sport, team, date, saved read, source, or selected workspace context. 2. Request body: the exact research job the user wants. 3. Grounding suffix: source limits, missing-data behavior, and freshness expectations. 4. Request context: React Native fields such as sportFocus, dataSource, responseView, useCase, and platformPanelContext.dataPlane. 5. Response: current read, source state, caveats, and one next action. Do not present stale or missing data as confidence. These examples are aligned with the React Native chat prompt fixtures and the public static demo contract: - Show the current MLB board: capabilityId=kam.cap.sports.board.list.by_date.v1; typedActionId=kam.act.sports.board.show.v1; expectedIntent=daily_odds_board_summary; responseView=odds_board; dataPlane=materialized_daily_odds_board_view; copy/paste: Scope: MLB today. Source: market-price data. Show me MLB odds Use only app APIs and tool results already in this chat. Do not answer from priors. If the data is missing, say "No data available." requestContext: surface: summary_ask analysisTier: fast serverManagedRouting: true answerSurface: chat sportFocus: baseball_mlb dataSource: sportsbooks responseView: odds_board timeScope: today bookmakerSelection: best_available useCase: daily_odds_board_summary dailyOddsBoardReadModelRequired: true - Ask for a bounded schedule answer: capabilityId=kam.cap.sports.schedule.list.by_week.v1; typedActionId=kam.act.sports.schedule.navigate.by_week.v1; expectedIntent=schedule_count; responseView=all_games; dataPlane=lane-specific read model; copy/paste: Scope: Yankees, June. How many Yankees games are in June? If schedule data is incomplete, say what is missing before answering. requestContext: surface: chat analysisTier: fast answerSurface: chat sportFocus: baseball_mlb responseView: all_games timeScope: this_week useCase: schedule_count - Compare sportsbooks and prediction markets: capabilityId=kam.cap.sports.market.compare_polymarket.v1; typedActionId=kam.act.sports.market.compare_polymarket.v1; expectedIntent=market_shape; responseView=market_alignment; dataPlane=materialized_cross_market_delta_view; copy/paste: Scope: current slate. Source: market prices and prediction markets. Where do sportsbooks and Polymarket disagree? If Polymarket data is missing, say "Cross-market status: Incomplete" and explain why alignment is blocked. requestContext: surface: chat analysisTier: deep serverManagedRouting: true answerSurface: chat sportFocus: baseball_mlb dataSource: both responseView: market_alignment bookmakerSelection: all_books useCase: market_shape - Review saved reads before acting: capabilityId=kam.cap.workspace.view.switch_view.v1; typedActionId=kam.act.workspace.view.open.v1; expectedIntent=market_shape; responseView=quick_read; dataPlane=lane-specific read model; copy/paste: Scope: my watchlist today. Source: saved reads plus current market data. What changed on my watchlist? Use only app APIs and tool results already in this chat. Do not answer from priors. If the data is missing, say "No data available." requestContext: surface: chat analysisTier: fast answerSurface: chat responseView: quick_read useCase: market_shape workspaceId: saved workspace - Resolve a recent game result: capabilityId=kam.cap.sports.game.get.detail.v1; typedActionId=kam.act.sports.game.open.v1; expectedIntent=scores_context; responseView=quick_read; dataPlane=lane-specific read model; copy/paste: Scope: Lakers recent games. Did the Lakers game finish? If the score source is not final, say the game is not confirmed final. requestContext: surface: chat analysisTier: fast answerSurface: chat sportFocus: basketball_nba responseView: quick_read useCase: scores_context - Ask for current futures context: capabilityId=kam.cap.sports.board.list.by_date.v1; typedActionId=kam.act.sports.board.show.v1; expectedIntent=futures; responseView=quick_read; dataPlane=lane-specific read model; copy/paste: Scope: NBA championship futures. Who is favored to win the NBA championship? Separate available prices from interpretation and label stale futures data. requestContext: surface: chat analysisTier: fast answerSurface: chat sportFocus: basketball_nba responseView: futures useCase: futures ## Kam Public Semantic Interface Kam publishes a public semantic interface so humans and agents can understand what the product can do before submitting a chat request. Response states: - ready_nonempty: Read succeeded and returned rows. - ready_empty: Read succeeded and certified zero rows. - not_read: Kam did not complete the source read. - not_requested: The current request did not ask for this source. - not_materialized: Source data may exist, but the product projection is not ready. - available_not_rendered: Data is ready but outside the current response scope. - stale: Data exists but is outside its freshness policy. - blocked: The current route cannot safely make the claim. Capabilities: - kam.cap.sports.board.list.by_date.v1: Show the daily odds board; responseView=odds_board; requiredInputs=sport, date; states=ready_nonempty, ready_empty, not_materialized, stale, blocked; nextActions=kam.act.sports.market.switch_market.v1, kam.act.sports.market.compare_polymarket.v1 - kam.cap.sports.market.compare_books.v1: Compare prices across sportsbooks; responseView=compare_books; requiredInputs=sport, date, marketType; states=ready_nonempty, ready_empty, not_requested, not_materialized, stale, blocked; nextActions=kam.act.sports.market.filter.by_bookmaker.v1, kam.act.sports.game.open.v1 - kam.cap.sports.market.compare_polymarket.v1: Compare sportsbooks and Polymarket; responseView=market_alignment; requiredInputs=sport, date, marketType; states=ready_nonempty, available_not_rendered, not_requested, not_materialized, stale, blocked; nextActions=kam.act.sports.market.compare_polymarket.v1, kam.act.sports.market.switch_market.v1 - kam.cap.sports.schedule.list.by_week.v1: Answer a bounded schedule question; responseView=all_games; requiredInputs=sport, dateWindow; states=ready_nonempty, ready_empty, not_read, stale, blocked; nextActions=kam.act.sports.schedule.navigate.by_week.v1 - kam.cap.sports.game.get.detail.v1: Open or resolve game detail; responseView=quick_read; requiredInputs=sport, game; states=ready_nonempty, ready_empty, not_read, stale, blocked; nextActions=kam.act.sports.game.open.v1 - kam.cap.workspace.view.switch_view.v1: Review a workspace or watchlist view; responseView=quick_read; requiredInputs=workspaceId, view; states=ready_nonempty, ready_empty, not_read, stale, blocked; nextActions=kam.act.workspace.view.open.v1 Well-known JSON endpoints: - /.well-known/kam-capabilities.json - /.well-known/kam-request-context.json - /.well-known/kam-response-contracts.json - /.well-known/kam-receipt-types.json - /.well-known/kam-navigation.json ## Technical Notes - llms.txt is an agent-readable product summary. - [Capabilities JSON](https://kam-ai.com/.well-known/kam-capabilities.json): Public capability definitions. - [Request Context JSON](https://kam-ai.com/.well-known/kam-request-context.json): React Native request context fields and examples. - [Response Contracts JSON](https://kam-ai.com/.well-known/kam-response-contracts.json): Response states, response views, and forbidden wording. - [Receipt Types JSON](https://kam-ai.com/.well-known/kam-receipt-types.json): Public-safe receipt definitions. - [Navigation JSON](https://kam-ai.com/.well-known/kam-navigation.json): Agent navigation map. - [Product docs manifest](https://kam-ai.com/docs/manifest.json): Machine-readable product guides, query templates, follow-ups, and section anchors. - [Sitemap](https://kam-ai.com/sitemap.xml): Indexable public routes. - [Robots](https://kam-ai.com/robots.txt): Crawler policy.