Menu
Campaigns: module introduction
A campaign is a working folder that already exists on disk, with its instrument exports, its calculation workbooks, its protocols and its notes. IsoFind indexes it in place, renaming and moving nothing, and adds a descriptor that carries the meaning: which file is what, which sample it talks about, and which operations the material went through.
The problem being addressed
A doctoral or postdoctoral folder a few years old holds several hundred files, produced by different instruments and named according to conventions that changed along the way. After a while, it is no longer clear which file corresponds to which sample, or which workbook produced the value in a figure.
The most useful files are the hardest ones. An ICP-MS export, a speciation session or a multicollector run cover several samples at once and therefore, by construction, carry no sample name in their own name. Locating them one by one would mean repeating the same gesture eleven times, which nobody does.
Indexing in place
| Rule | Consequence |
|---|---|
| Originals are never renamed, moved or modified. | The folder stays usable without IsoFind, and with the laboratory's usual tools. |
| The meaning lives in campagne.isocamp, at the root of the folder. | Moving or sharing the folder carries the organisation work with it. |
| The database is only a rebuildable cache. | A database lost or moved to another machine is rebuilt by a new scan. |
The descriptor is authoritative, the database comes second. That is what makes it possible to work in pairs on a shared folder, and to reopen a campaign ten years later on a machine that never saw the original database.
What the descriptor holds
| Block | Content |
|---|---|
| genese | Version, dates, the tool that wrote the file. Outside the signed digest. |
| inventaire | One record per file: relative path, SHA-256 hash, size, recognised kind and the reason for that classification. |
| campagne | Name, description, links to samples in the database. |
| chaine | Nodes, edges, attached files and locators. |
The genese block is kept outside the signed digest, for the same reason an export date prevented any reproducible digest in method files: two writes of an unchanged descriptor must give the same hash.
| Format choice | Reason |
|---|---|
| Relative paths, / separator | The folder must be able to change disk and operating system. |
| NFC normalisation of names | macOS writes accents decomposed, Windows composed. Without normalisation the same file would appear twice. |
| Sorted by path, canonical serialisation | Two successive writes produce the same text, so the file can be diffed line by line. |
| No derivable data | Duplicates and homonyms are recomputed; storing them would create a second truth to maintain. |
| No file content, only hashes | The descriptor stays small and never duplicates the data. |
The surfaces
| Surface | Role |
|---|---|
| Campaign panel | The folder, its sections, the inventory by kind, the flags, the chain tree. |
| Chain panel | The grid view of the aliquot chain. Its place is the central zone. |
| Context menu | On a file and on a node: open, lineage, attach, link to a sample. |
| AI assistant | Three read-only provenance tools. |
What the module is not
- It is not a general-purpose file manager. The operations offered act on domain objects, not on files taken for themselves.
- It is not one more open format. IsoFind already publishes three: ISOF for data, IGL for modelling and IGDB for fractionation databases. The campaign descriptor stays an implementation detail of IsoFind.
- It is not a LIMS. Nothing requires a complete chain before the rest can be used, and a folder scanned without a chain stays readable.
Routes
POST /campagnes/scanner { racine }
GET /campagnes/descripteur ?racine=
POST /campagnes/arbitrer { racine, empreintes, genre }
GET /campagnes/chercher ?racine=&terme=&noeud=
GET /campagnes/registre known campaigns