Ask your data. Choose your own model.
Krino has two AI screens: one answers questions about decisions, rules and cases in plain language, the other turns the same question into a table and a chart. Both run on the organisation's own provider and its own key — there is no model bundled into the product and no shared account.
Ask without hunting for the screen.
"How many declines this week?" "Which rules fired most in the last seven days?" "How many cases are still open, by queue?" The answer is not a guess: the assistant reads the platform's own records, and says what it read underneath the answer.
It says what it looked at
Under every answer are the sources that turn used — a report query, the live rule sets, a list lookup, one decision's breakdown. When a number is not what you expected, that is the first place to look.
It cannot reach past your permissions
The tool list put in front of the model is cut down to the person asking. In the session of somebody who cannot see cases, cases are never described to the model — and no phrasing of the question changes that.
Follow-ups make sense
"And last month?" works. The last turns of the thread travel with the question — not the whole thread, because making the twentieth question cost twenty times as much does not make the answer better.
It is on the case screen too
The panel that discusses the file in front of an analyst uses the same configuration. Whatever the organisation's provider is, that is what it talks to — no second setting, no second account.
A question comes back as a table, a chart and a sentence.
You write "declines per day this month" and get the table, its chart, and a short remark about what the table says. A report worth keeping is saved under a name and can be shared with the rest of the organisation. What is saved is the question, not the table: it re-runs each time it is opened, so "this week" still means this week next month.
Decisions
Outcome, score, rule set, record type, whether a case was opened. Volumes, decline rates, score distributions, and which rule sets are doing the work.
Rule evaluations
One row per rule per decision: which rule fired how often, what it contributed to the score, which never fires, and which is erroring.
Cases
Queue, assignment, outcome and lateness. Workload, backlog and false-positive rates come out of this one.
{
"dataset": "decisions",
"range": "thisMonth",
"bucket": "day",
"group_by": ["outcome"],
"measures": ["count"],
"chart": "line"
}The model never writes SQL.
The model is handed the catalogue — which datasets exist, what fields and measures each has — and returns a recipe. Building and running the query is the engine's job. Generated SQL fails quietly: it forgets the organisation filter, it counts superseded row versions, and a model that can write SQL against a customer's schema can write any SQL against it. With a recipe, the worst a wrong plan can produce is an irrelevant table.
Data you cannot see is never described
A dataset you lack permission for is not described to the model and is never executed. That is a check in code, not a sentence in a prompt.
The tenant filter is carried by hand
Every dataset is bound to the organisation at its source. There is no "automatically added to every query" filter across the platform — which is exactly why it is not left somewhere it can go missing.
Your calendar, not the server's
"Today" starts at midnight in your time zone, not wherever the container runs. "The last 24 hours" is a rolling window and takes no zone — the same distinction the rule engine draws, so the same sentence counts the same rows.
Your key, your bill.
The provider and API key are entered by the organisation in its own settings. A model call about a customer's transactions is that customer's data and that customer's cost; one operator-supplied key would put every organisation's traffic through one account.
OpenAI, Anthropic, Google Gemini
All three speak the same chat protocol, so choosing a provider is choosing an address and a model name. Leave the model field empty and the provider's default is used.
Or a model you run yourself
Any OpenAI-compatible endpoint: Azure OpenAI, OpenRouter, vLLM, Ollama, or your own gateway. If nothing may leave your infrastructure, this is the way.
The key never comes back
It is stored encrypted with the same protector the integration credentials use. The screen only says a key is stored; it cannot be read back, only replaced.
Tested before it is saved
The test button calls the provider once. A credential is only ever wrong at the moment it is used, and learning that from an empty report an hour later is how a mistyped key gets blamed on the assistant.
It reads. It does not write.
| The usual worry | In Krino | |
|---|---|---|
| Authority | An assistant that acts from a chat box | No write capabilities: it cannot close a case, publish a rule set or change a setting |
| Default | On the day it ships | Off until a provider is entered; during an incident it switches off without losing the key |
| Personal data | Every table opened to the model | Only decisions, rule evaluations and cases — not the event tables you send |
| Audit trail | The chat disappears | Every turn is written down: question, answer, sources read, model and tokens spent |
| Who turns it on | Anyone with access to settings | The provider and key are a separate permission from editing the organisation |
Where does the data go? The rest of Krino makes no per-transaction call to the outside; enrichment and sanctions lists are read from inside your infrastructure. The assistant is the exception: once you turn it on, the question and the rows the model reads to answer it go to the provider you chose. If that must not happen, you have two options — leave the assistant off, or point it at a model you run yourself.
Every screen is one keystroke away, by name.
There are around thirty pages in the console. ⌘K (Ctrl K on Windows) opens the search box: you type, the list narrows, Enter goes. Results are read from the navigation itself — a page closed to you does not appear — and pages carry keywords: rules finds the rule sets, alerts finds the case queue.
Let's try your question on your data.
Tell us which provider you use and we will show the screen on that model.