How the AI sees your deck
What the model is handed before it answers, what it can fetch mid-answer, and what stays on the server.
Every card the AI names was either already in your deck or came back from a search it ran, and the oracle text it reasons over is the text in our database. This page is how that is arranged.
Before the model sees anything
A classifier reads the last few messages. Haiku decides which of four things you want, from card suggestions, deck evaluation, a rules question or general discussion, and sets flags for what data to load: whether the answer needs your deck's strategy, its card list, a card search, analysis data, or deck-building theory.
This is a cost decision as much as a correctness one. Loading the full deck for "what's a good land count?" wastes tokens on every message.
Two shortcuts skip the classifier: a message that is only a greeting or acknowledgement, and a message that opens with search syntax. Both are recognized by pattern, and both save an API call.
Rules context is never pre-loaded. A compressed rules block is always present, and anything more specific is fetched on demand through the tools below.
Then the context is assembled according to those flags, as a set of prompt blocks. The stable ones, meaning instructions, compressed rules, your deck's identity and the oracle text of the cards in it, are marked for caching. A follow-up question in the same conversation re-reads them roughly ten times cheaper than the first message did.
What it can do mid-answer
The model has tools, and reaching for one is how it gets facts it was not given:
| Tool | Returns |
|---|---|
get_card | One card's full data by name |
search_cards | Cards matching a query |
load_concepts | Definitions from the game-concept vocabulary |
load_rules | Numbered rules from the Comprehensive Rules |
load_card_rulings | Official rulings for a card |
load_rules_examples | Worked interaction examples |
web_search | The open web, for things outside the database |
The rules tools exist so that an interaction question is answered from the actual rule text, with a citation. The prompt instructs the model to reach for them whenever its confidence in a ruling is anything short of high.
Whether the model used the tools its intent implied is recorded. A message classified as needing a card search that never ran one is logged as a mismatch.
How candidate cards get ordered
A structured search returns everything matching the filters, which for a broad query is thousands of cards. Narrowing that to what is relevant is a separate step:
- The query is executed as filters, producing a candidate set.
- The intent behind the question is embedded with Voyage
voyage-3, truncated to 256 dimensions. - A database function ranks the candidates by cosine similarity against the embeddings stored on each card.
Filters decide what is eligible. The embedding decides what is relevant. Cards with no embedding are appended at the end, so they stay reachable and are never ranked highly. If the embedding service is unavailable the original order is kept and the search still works, just less well sorted.
What stays on the server
Your decks, collection and conversation history are read server-side under row-level security. The data model documents reference data only; see that index for what it covers and what is still outstanding.
Card data sent to the model is the same card data you can query yourself. Deck contents are sent because answering about your deck requires them.
Reading an answer sceptically
- Named cards are checkable. Any card in an answer is in the database. Look it up and compare.
- Rules claims should carry rule numbers. A claim without one was answered without calling a rules tool, which is the case to verify.
- Prices in an answer are as fresh as the last import. See where a price comes from.
- A search the AI ran can be shown as a query string, because the query tree round-trips. If a recommendation looks arbitrary, the filters that produced it are recoverable.