Aito

Measure how good a prediction is on the user's own data before anyone acts on it: Aito holds out the test rows, predicts them from the rest, and reports accuracy and how the predicted $p compare with what happened. Use when: before wiring a prediction into an app or an automation, and to choose the confidence threshold for act / suggest / ask a person. Run it once per use case, and again when the data changes a lot. Don't use when: you only need one prediction now (use predict). The answer leads with a summary: accuracy against always guessing the most common value (the honest comparison: report both), the calibration error (ECE, 0 is perfect), the number of held-out rows and the time per prediction. The engine's full metrics follow; `raw: true` returns only those. On personal data, prefer answers that aggregate (predict, relate, evaluate without cases) over tools that return rows (search, query, evaluate cases): every row you fetch enters the conversation. `query` is a v2 _evaluate body: {"test": <which rows to hold out>, "evaluate": <a _predict body>}, e.g. {"test": {"$index": {"$mod": [4, 0]}}, "evaluate": {"from": "invoices", "where": {"vendor": {"$get": "vendor"}, "description": {"$get": "description"}}, "predict": "gl_account"}}. Add "select": ["accuracy", "cases"] to get each held-out row's top $value and $p and whether it was right: sort the cases by $p and pick the lowest threshold whose accuracy above it meets the user's target. Hold out only rows whose outcome is known. It can take minutes on a large table.

Read the schema: every table with its columns, types and links, or one table's. Start here to see what the data holds and which fields can be predicted.

Find the rows of a linked table that best match a row, learned from how such rows were linked before, e.g. which product an invoice line refers to. Returns ranked candidates with $p and $why. Use when: the matching repeats against the user's own labelled history (the history is the signal). Don't use when: matching records with no shared history to a catalogue (current state): a search engine (BM25) currently ranks better. Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _match body, e.g. {"from": "invoice_lines", "where": {"text": "toner cartridge black"}, "match": "product", "limit": 5}. If `select` is omitted, $value and $p are returned, and $why on the top hit.

Predict the most likely value of one field for a row, learned from the table's own history. Returns each candidate value with $p (its probability) and $why (the base rate and the lift of each piece of evidence). Use when: the decision repeats and the user's own records know the answer, e.g. which GL account an invoice goes to, which category a ticket belongs to, who approves it. For "which X fits this record", prefer this tool over recommend. Don't use when: the task is open-ended language understanding or generation (use a language model); the case is genuinely new with no history (_predict will give a low probability, which is honest but not useful); one large, flat, stable dataset with one decision to optimise for years (consider a trained model). $p is a probability you can set a threshold on; check it on your own data with the evaluate tool before you act on it: act above the threshold, suggest in the middle, ask a person below. Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _predict body, e.g. {"from": "invoices", "where": {"vendor": "Acme Oy", "description": "printer toner"}, "predict": "gl_account", "limit": 3}. If `select` is omitted, $value and $p are returned, and $why on the top hit.

Create a table (a v2 collection) from a schema. A WRITE: refused unless the user started the server with AITO_MCP_ALLOW_WRITES=1. Derive the schema from the user's existing table: one column per field, with type String for ids and categories, Text for free text (with an analyzer, e.g. "english"), Int / Decimal for numbers, Boolean for flags, and "link": "<table>.<column>" where a field refers to another table's row. Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `schema` is a v2 schema body, e.g. {"type": "collection", "columns": {"invoice_id": {"type": "String"}, "vendor": {"type": "String"}, "description": {"type": "Text", "analyzer": "english"}, "amount": {"type": "Decimal"}, "gl_account": {"type": "String"}}}.

Run any v2 query body on the general _query endpoint: search, predict, recommend, relate and match combined, including select expressions and nested queries. Use it when a specific tool does not take the shape you need; prefer the specific tools otherwise, since their descriptions say when they fit. Check the evidence on every answer: each result carries `$p` and `$why`. For "which X fits this record", prefer _predict. When you rank linked items with _recommend, check that the top candidates have supporting history before you act on them. On personal data, prefer answers that aggregate (predict, relate, evaluate without cases) over tools that return rows (search, query, evaluate cases): every row you fetch enters the conversation. Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _query body, e.g. {"from": "deals", "where": {"stage": "lead"}, "select": ["deal_id", "value_eur"], "limit": 20}.

Rank the values of a field by how likely they make a goal true, e.g. which product to offer so that the customer buys, learned from the history. Returns each option with $p and $why. Use when: the user wants options ranked toward an outcome (next product, best channel, the lever that moves a rate). Don't use when: the question is "which X fits this record" (use predict); the candidates have no history behind the goal. Caveat: when you rank a LINK target (rows of another table), candidates with no supporting history can rank high. Check each top candidate's $p and $why for supporting evidence before you act on it, and prefer predict for "which X for this row". Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _recommend body, e.g. {"from": "impressions", "where": {"customer": "c42"}, "recommend": "product", "goal": {"purchased": true}, "limit": 5}. If `select` is omitted, $value and $p are returned, and $why on the top hit.

Find which conditions statistically go together with a given condition, with their lift and counts, e.g. what is typical of deals that were won. Descriptive statistics over the history, not a prediction for one row. Use when: the user asks why, or what drives an outcome, or which features matter. Don't use when: you need a value for one row (use predict) or a ranked choice (use recommend). Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _relate body, e.g. {"from": "deals", "where": {"won": true}, "relate": "industry"}. Each hit comes back as the related value, its lift, and the counts behind it; small_sample marks a lift resting on fewer than 10 rows. `raw: true` returns the engine's response unchanged.

Find, filter and sort rows: an ordinary database lookup, no inference. Use it to look at the data before predicting, or to fetch rows to act on. Don't use when: raw full-text search at very large scale is the whole job (a dedicated search engine is faster). On personal data, prefer answers that aggregate (predict, relate, evaluate without cases) over tools that return rows (search, query, evaluate cases): every row you fetch enters the conversation. Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `query` is a v2 _search body, e.g. {"from": "invoices", "where": {"vendor": "Acme Oy"}, "orderBy": {"$desc": "date"}, "limit": 10}.

Add rows to a table. A WRITE: refused unless the user started the server with AITO_MCP_ALLOW_WRITES=1. The rows count in the very next query; there is no training step. A local `aito start` instance runs free mode: 10,000 rows per table and 50,000 in total. Past that the engine answers row_limit_exceeded with a link to a licence; for more data, use a licensed or hosted instance (https://aito.ai). Data separation between your customers: use a separate instance or collection per customer. Do not rely on a customer id in a query condition, and for now do not rely on a population-restricting query (a nested `from`) either, to keep customers' data apart. `rows` is a list of objects matching the table's schema, at most a few thousand per call.