Menu
Local AI assistant
The assistant is a language model running on the user's own machine, through Ollama. It has no access to the DOM, the database, the disk, or the network: it only calls tasks, exactly the ones the workflow engine exposes. This page describes the setup, the panel, and the precise boundary of what the model can do.
Prerequisites
| Item | Value |
|---|---|
| Runtime | Ollama, listening on 127.0.0.1:11434 |
| Model | No model is imposed. The connector lists the ones installed through /api/tags and the user picks. |
| Context window | 32k. Tool results are summarised so as not to saturate it. |
| Network | None. The transport refuses any non-local address. |
Installing Ollama
Ollama is the local runtime that serves the model. IsoFind does not bundle it: it carries its own licence and its own release cycle, and lives outside the application exactly as the external documentation sources do.
| Step | Detail |
|---|---|
| Download | From ollama.com/download, for Windows, macOS or Linux. On Windows the installer registers Ollama as a background service that starts with the session. |
| The ollama command | The installer adds it to the system PATH. A new terminal then resolves ollama --version; if it does not, the PATH entry was not picked up and the session must be reopened. |
| Model storage | Pulled models are large. They go to %USERPROFILE%\\.ollama\\models on Windows, ~/.ollama/models elsewhere. Set OLLAMA_MODELS to move them to another drive before pulling. |
| Service address | Ollama listens on 127.0.0.1:11434. This is the address IsoFind's connector expects; leave it local. Exposing it on 0.0.0.0 would break the sovereign, air-gapped posture the assistant is built around. |
ollama --version # confirms the command is on the PATH
ollama pull llama3.1:8b # or any other tool-calling model
ollama list # the models IsoFind will list through /api/tags
ollama serve # starts the runtime if the service is not already up
Recommended models
IsoFind imposes no model, but the assistant only works with one that can call tools: it acts by invoking tasks, never by writing prose the application has to parse. A model that cannot emit a tool call answers in prose without triggering anything: the panel shows a reply, and no task runs.
| Model | Note |
|---|---|
| qwen2.5:14b | The reliable default on a 12 GB card, where it fits entirely in VRAM. In testing it calls core.graphique and core.resume dependably. |
| llama3.1:8b | Lighter, a good fit for machines with less memory. Calls tools reliably. |
| qwen3:14b | Not recommended for this assistant: in testing it failed to call core.graphique and core.resume under the same task payload the others handled. |
A model that reasons well in conversation is not necessarily one that calls tools well. The two abilities are distinct, and the assistant needs the second. Prefer a model confirmed on this exact workload over a newer or larger one that has not been tried against the task list.
Some models write tool calls as text fragments rather than structured objects, which is why streaming is switched off whenever tools are offered (see below). The number of tools presented is also trimmed in conversation mode, since too large a payload overwhelms a smaller model and it stops calling anything.
No API key, no account, no outbound connection. In air-gap mode the assistant works identically, as long as Ollama and the model are present on the machine.
What the model can do
The model calls tasks, and nothing else. It holds no power a workflow does not already have, and everything it does goes through the same path, the same journal and the same signed registry.
| Capability | Through which tool |
|---|---|
| Query the database, read-only | core.sql |
| Compute statistics per group | core.resume |
| Aggregate analyses per sample | core.analyses |
| Draw a chart | core.graphique |
| Search for matches | core.correspondance |
| Show a map | core.carte |
| Generate a report | core.rapport |
What it cannot do
- No DOM access: it does not click, fill in forms, or navigate.
- No direct access to the database, the disk, or fetch.
- No kernel task deletes data.
- No data leaves the machine, including the active campaign, which is never passed to the connector.
What the model can reach is limited to the list of registered tasks. That list is declared by the core and by installed plugins: changing model, or installing a newer one, does not widen it. Adding a tool means declaring a task.
Calculation never goes through the model
The model does not compute. It calls core.resume, which returns n, mean, 2SD, min and max per group, computed in code over all rows.
A mean estimated by a model across two hundred values carries deviations, often in the last decimals, that are not caught on review. Statistics are therefore computed in code, never by the model. The instruction is written into the prompt and repeated in the notice of every tool concerned.
Summarising results
When a tool returns a table, the model does not receive the data but its shape: row count, columns, statistics, and twelve example rows. The user, meanwhile, sees the full table on screen.
| The model receives | The user sees | |
|---|---|---|
| A 400-row query | Shape: 400 rows, 6 columns, statistics, 12 example rows | The full table, sortable and exportable |
| Token cost | Roughly nine times lower | No effect |
Without that summary, a single tool call would be enough to push the model out of its 32k window, and the conversation would lose its beginning without warning.
The Assistant panel
The core.assistant panel shows the conversation thread, the tool calls with their arguments, and the rendered results (tables, charts, maps).
The answer text arrives as a stream (NDJSON read line by line). Streaming is switched off when tools are offered: a tool call arrives in fragments, and the model writes it as text. Reassembling it on the fly would mean guessing, at every fragment, whether you are in the middle of a JSON object or of a sentence. The tool-calling turn is short; it is the answer turn that is long, and that one is streamed.
Two modes
| Plan mode | Agent mode | |
|---|---|---|
| The model | Produces a workflow, touches nothing | Calls the tasks directly |
| Human review | Before execution | After the fact |
| Replayable | Yes, the workflow is an artefact | No |
| Use | Regulated contexts, client deliverables | Exploration, fast iteration |
The detail is on the Plan mode and agent mode page.
A language model is not deterministic: the same question can produce a different sequence of calls. The journal records what was done, but does not replay that sequence identically. Plan mode covers the second need, since it produces a workflow.