Traceability and audit

Every write performed by the assistant is recorded in the signed registry, with the agent that produced it and the hash of the prompt that motivated it. The agent recorded is the one the server issued, not the one the client claims. This page describes the session mechanism, what the registry proves, and what it does not.

Why a header is not enough

An early version carried the agent identity in an X-IsoFind-Agent header. A header can be forged: any client can write Ollama - IsoFind Assistant. A human can pass for the AI, and the AI for a human.

As long as the agent is a value declared by the client, the registry holds a claim that nothing can corroborate after the fact. Audits check this early.

The agent session

Before it starts, the assistant requests a session from the backend. The server issues a token, and the server is what decides the identity that gets recorded.

POST /api/agents/session { "connecteur": "ollama", "modele": "llama3.1:8b", "prompt_sha256": "3f8a1c..." } -> { "session": "ag_7f3c...", "agent": "Ollama - llama3.1:8b" }

Subsequent writes carry the X-IsoFind-Agent-Session header. The registry records the agent resolved from the token, never the one the client declares.

Header received	Backend behaviour
Valid session token	The agent issued by the server is recorded.
Unknown or expired token	Warning in the logs, fallback to the generic agent. The token is not trusted.
No token, only an X-IsoFind-Agent header	Value sanitised and recorded as a declarative agent, with no probative value.

The prompt enters the signed chain

The SHA-256 hash of the system prompt is passed at session open and enters the signed message. Without it, the prompt would remain modifiable after the fact: the instruction that motivated the write would be the only element of the record left out of the signature.

Actor and agent

The registry keeps two distinct fields, and an auditor reads the second one first.

acteur : Colin Ferrari who decides, and who is accountable agent : Ollama - llama3.1 what executes Colin Ferrari, via interface Colin Ferrari, via workflow "Correction blanc v3" Colin Ferrari, via Ollama - llama3.1:8b

A correction applied to forty samples does not carry the same responsibility depending on whether it came from a repeated gesture, an automatic rule, or a model's decision. Both fields are present in every entry, so nothing has to be reconstructed.

Campaign and motive

Two further fields enter the signed message: the declared campaign and the motive for the write. They answer the question the registry could not previously handle: not what, nor who, but why.

The campaign is propagated by wrapping window.fetch once, filtered to internal API calls. It is never passed to the connector: Ollama receives neither the campaign name nor the motive.

Versioning the HMAC chain

Adding the campaign and the motive changes the formula of the signed message. The chain is therefore versioned: V1 entries stay verifiable with their original formula, and V2 entries include the two new fields.

Item	Behaviour
Earlier entries	Verified with the V1 formula. No rewriting, no loss of verifiability.
Existing database	Migrated at startup: ALTER TABLE for the columns, then the triggers are rebuilt.
Chain version	Stored in the __chaine__ pseudo-table in the registry metadata.

Without the version marker, existing triggers would call the chaining function with the old argument count after an update, and the software would become unusable. The version is therefore read at startup and triggers a rebuild whenever the formula has changed.

What the registry proves

Proved	Not proved
That a write happened, on that date, on that value.	That the same sequence would happen again identically.
Which actor is responsible for it.	That the actor was right.
Which agent executed it, according to the server.	That the model followed its language instructions.
Under which prompt, by its hash.	The content of the prompt, if it was not kept elsewhere.
That the chain has not been tampered with.	That no data was omitted before the first write.

Checking a session

History panel › Sample › Events › Actor, agent, campaign, motive

Chain-integrity verification is described in HMAC traceability and integrity. ISOF exports additionally carry an ECDSA P-256 signature that can be verified offline, including by the open-source isof package, without IsoFind.

Regulatory context

The logging obligations that apply to AI systems under the European regulation depend on how the use case is classified. Depending on whether the analysis of critical raw materials falls into a high-risk category or not, the architecture described here is either an advantage or a condition of market access.

This classification is a legal qualification, not a technical choice. This page describes what the software records; the compliance analysis belongs to those qualified to conduct it.