Panel catalogue

The panels shipped with the kernel, with their identifier and declared dock. Each one automatically gets a <id>.toggle command in the panneau category, callable from the palette, a shortcut, the View menu, or the All panels... picker, which is also the only place plugin panels appear.

Overview

PanelIdentifierDeclared dockShortcut
Filescore.fichiersLeftCtrl+Shift+E
Database browsercore.dbLeftCtrl+Shift+D
Journalcore.journalBottomCtrl+Shift+J
Problemscore.problemesBottomCtrl+Shift+M
Actionscore.actionsRightCtrl+Shift+A
Historycore.historiqueRightCtrl+Shift+H
Dashboardcore.tableauRightPalette
Workflowscore.workflowsRightPalette
Assistantcore.assistantRightPalette
Notebookcore.notebookBottomPalette
Python consolecore.consoleBottomPalette
Knowledgecore.connaissancesBottomPalette
LIMS acquisitioncore.limsBottomPalette
Campaigncore.campagneLeftPalette
Campaign chaincore.campagne.chaineCentral zonePalette
Taskscore.tachesBottomPalette
Pluginscore.pluginsRightTitle bar
Campaign bannerBannerOutside the docksDedicated commands

Files

Browses the user's files. Double-clicking a CSV opens it in a central-zone tab through the editor registry: the same editor as by drag-and-drop or by a plugin call, with the same CSV parser and typed columns.

Navigation is bounded by roots declared on the backend (files_routes.py): home folder, desktop, documents, mounted volumes. Any path outside a root is refused. The user may add a root; the point of the check is that a path constructed elsewhere in the application cannot reach the keys, the SQLCipher database, or the installation directory.

Every write through this panel first keeps a .bak copy of the previous file. A field data file overwritten by a misplaced click cannot be recovered by any other means, and the mistake may only be noticed months later.

Database browser

Opens an external SQLite database read-only: tables, schema, queries. It gives no access to the software's own encrypted database, which is reached exclusively through the single secure_db.connect connection point.

Journal

Session trace, filterable by source. It captures the console, feeds on command.before, command.after and command.error, and exposes K.log(source, message) to the rest of the application.

The journal is not the signed registry. For anything touching admissibility, the HMAC-chained registry of sample modifications is what counts. See HMAC traceability and integrity.

Problems

Aggregates the anomalies the engines detect: missing uncertainties, non-exploitable samples, unmatched standards, failed workflow steps. Clicking a row opens the object concerned.

Actions

The commands available in the current context, grouped by category, as a persistent list. The star pins a command as a favourite; favourites feed a dashboard widget.

Favourites are revalidated against the registry on every render: a favourite command whose plugin has been uninstalled disappears instead of failing on click.

History

Reads the signed registry, sample by sample. For each event: timestamp, operation, table, actor (who decides), agent (what executes), plus campaign and motive when declared.

Colin Ferrari, via interface Colin Ferrari, via workflow "Correction blanc v3" Colin Ferrari, via Ollama - llama3.1:8b

The panel listens for the historique.ouvrir event: clicking a recent modification on the dashboard loads that sample directly, without retyping its name.

Notebook and Python console

Neither owns a runtime. Both go through K.notebooks.noyau('python'), a single Pyodide instance running in a worker. Giving the console its own bridge would start a second Python: the user would see two where they believe there is one, and a variable defined in the console would be unreachable from a notebook cell.

Tabs are namespaces, not processes

Each console tab executes under a distinct session name, so two tabs do not tread on each other. But they share the same interpreter.

Killing the kernel from one tab kills them all, and the notebook with them. The core.console.kill command says so in its shutdown message, rather than leaving it to be discovered.

State does not survive navigation

Every sidebar link destroys the document, and therefore the worker. The console persists the command history, which is text. Never the transcripts, never the tabs: showing them again on return would suggest that the corresponding Python state is still alive, when the worker was destroyed along with the document.

%pip does not mean PyPI

The worker's CSP only allows Pyodide's local path, and the application targets air-gapped use. %pip therefore relies on micropip, which resolves first against the local Pyodide distribution: scipy, sympy and the rest of the bundle install offline.

Beyond that, a wheel must be placed in the local store (/vendor/wheels/). When the network is the cause of the failure, the console states the rule rather than relaying an unreadable network trace.

Commands

CommandEffect
core.console.newNew tab, new namespace, same interpreter.
core.console.clearClears the tab's transcript. Does not clear Python state.
core.console.killKills the Python kernel. Affects every tab and the notebook.
The notebook and the console cover what the workflow engine does not do. Task chaining is linear and loop-free: anything that needs a loop needs a script, and IsoFind already runs Python and R.

IGL compatibility

The notebook's Python kernel exposes the bindings for IGL, the open language for modelling isotopic processes, published under the name igl-lang. An IGL model can be loaded, compiled and run from a cell, like any other scientific library.

import igl model = igl.charger("reduction-cr.igl") # reads an IGL file graph = model.compiler() # produces the intermediate representation result = graph.executer() # returns the computed compositions result.variable("Groundwater.Cr(III).delta53Cr")

IGL remains an independent standard, with its own specification, reference engine and data format. IsoFind adapts to IGL and changes neither its language nor its contracts: a model written in the notebook means the same thing to any conforming implementation, inside IsoFind or outside it.

The language, its blocks, its diagnostics taxonomy and its fractionation databases are documented on the official site, igl-lang.org. This page does not replicate that documentation: for the syntax of a model, the block reference or the database catalogue, the IGL site is authoritative.

Knowledge

Declares the documentary sources the assistant may consult, and indexes them. The assistant reaches them through a tool call, visible in the conversation thread like any other.

Three kinds of source

KindSourcesPath
Shipped with IsoFind isofind, api, modules Resolved automatically, locked. Indexed on first start.
Your laboratory wiki, sop, publications To be filled in. Absolute path to a folder.
External tools phreeqc, r, python To be filled in if the documentation is installed on the machine.

External sources are empty at install time, and deliberately so: IsoFind cannot ship the PHREEQC, R and Python documentation. They weigh hundreds of megabytes, carry their own licences, and change version independently of the software.

The group that matters is Your laboratory. The model roughly knows the PHREEQC documentation already. What it does not know is your procedures: your blank-correction protocol, your acceptance threshold, your in-house standard. Those documents exist nowhere else, and that is what makes document search useful.

The document counter

DisplayMeaning
42 docSource indexed. The indexing timestamp is in the tooltip.
emptySource enabled but holding no document. Wrong path, or empty folder.
offSource unchecked. It is not consulted.
Without that counter, a source with a wrong path would produce an assistant answering "I found nothing" with no visible cause, and the fault would be put on the model. Reindexing therefore reports errors source by source, rather than a global "indexing complete" that would hide the failing sources.
GET /api/knowledge/sources PUT /api/knowledge/sources/{id} { path, enabled, label } POST /api/knowledge/reindex -> { resultats: [{ label, documents, erreur }] }

The paths of shipped sources are shown but not editable: the user must be able to see where the software found its documentation, if only to understand why it is empty, without being able to break it.

Campaign

Two surfaces carry this name. The banner shows the active campaign of the database, outside the docks, with two commands, campagne.declarer and campagne.clore. The Campaign panel opens a working folder indexed on disk and gives access to its inventory and its aliquot chain; it is described on Campaigns. What follows describes the banner: The campaign propagates to every write and enters the signed message in the registry.

Propagation is done by wrapping window.fetch once in the kernel, explicitly filtered to internal API calls. A local connector, Ollama included, never receives the campaign header.

Dashboard

Mounts the same widgets as the home page, from the same registry, inside a dock. Useful for keeping recent modifications in view while working. It remounts on events rather than displaying the state it had when it was opened, indefinitely.

LIMS acquisition

Watches folders, not a network API: files dropped by the instrument or the LIMS are detected, parsed and offered for import.

The automatic scan stops in dispose(), when the panel is closed. A scan that kept running in the background would write to the database with no surface showing it, while the panel that drives it is closed.

Kernel inspector and Plugin workshop

The Kernel inspector lists the registered contributions with their source, category, zone and capability. The Plugin workshop is restricted to the local zone: its command carries zone: 'local' and does not appear in the palette outside developer mode.

In developer mode, core.dev.dump exports the whole registry as JSON: commands, panels and context keys, with their source and zone.