Trust

Compliance kit

Written for an IRB reviewer, a procurement or IT officer, or a PI evaluating CLAIR for IRB-protected, FERPA-covered, or otherwise regulated data.

What CLAIR is

CLAIR is a single-user, local-first desktop application for analyzing confidential data entirely on the researcher's own device. There is no CLAIR cloud account and no server-side copy of your data. The AI model that answers questions runs locally through Ollama, on the same machine as everything else; there is no cloud inference step and no external model API in the path between a question and its answer.

The data-flow picture

Your file, the database CLAIR builds from it, the search index, and the AI model all live inside one boundary: your machine. The trust overview has a full diagram. Three narrow, documented network uses cross that boundary (model download, app update check, and license activation and renewal); none of them carry dataset content. A full inventory with exact hosts is on the network contract page.

No-content-egress attestation

These data classes never leave the machine, by construction

This is a structural claim: outbound network payloads have no field capable of carrying any of the following, so a regression that tried to send one would produce a dropped event, not a leak.

  • Uploaded cell values from any dataset
  • Column names, dataset names, file names, and file paths
  • Query and chat text, and any other natural-language input
  • CLAIR's responses and any SQL it generated
  • Vector embeddings of your rows
  • Raw exception messages or stack traces

Honest scope: what this does not claim

CLAIR does not defend your data against a malicious program running under your own user account on the same machine. Such a program could read CLAIR's local database directly, exactly as it could read your original spreadsheet. This is the standard local-application trust model, not a cloud multi-tenant boundary. Protect the machine itself, with full-disk encryption and normal account hygiene, the way you would protect the source files.

Offline verification

Reproduce the claim yourself, no source access required

  1. 1Activate CLAIR once while online, then disconnect the network entirely, or block it at your firewall, and relaunch the app.
  2. 2Use CLAIR fully offline: upload a file, ask chat questions, run an analysis, export a report. Everything should work with no network connection.
  3. 3Capture network traffic during that session (for example with Wireshark) and confirm nothing reaches an external address. All traffic should stay on the local loopback address the app uses to talk to itself.
  4. 4If telemetry is on, open the local telemetry queue file (plain text, on your own disk) and confirm it holds only metadata such as durations and feature names, never file content.
  5. 5Reconnect and capture again: outbound traffic should go only to the hosts listed on the network contract page.
  6. 6Confirm the off-switch: turning telemetry off in Settings stops collection and empties the local queue.

The license channel, disclosed

The one channel that carries an identifier

License activation and renewal is the single exception to "never an identifier": it sends your account email or license key, plus a hash of a stable device identifier, not the raw identifier itself and never a MAC address or serial number, in exchange for a signed token that lets the app run. It is disclosed here specifically because it is the exception, not because it is hidden.

Retention and licensing

Nothing server-side to retain, because nothing server-side receives it

There is no server-side retention question for your data, because your data never reaches a server. Locally, chat memory is kept for a short, fixed window and then cleared; if you opt into telemetry, that queue is capped and rotated automatically.

CLAIR ships only permissively licensed dependencies (MIT, Apache-2.0, BSD), with one documented exception under LGPL used solely as a fallback PDF export path. A full dependency list is available on request.

Wording you can use

For a data management plan or protocol

Three short paragraphs, grounded in the facts above, that you are welcome to copy into your own documentation. Edit the bracketed details before submitting.

General data-handling statement

CLAIR (Confidential Local Analytics Inference Runtime) is a single-user, local-first desktop application. All data analysis, including AI-assisted question answering, runs entirely on the researcher's own device. Uploaded data, the derived database, and the search index built from it are stored locally and are not transmitted to any server. The application's only network uses are a model file download, a signed software update check, and license activation and renewal; none of these carries dataset content, column names, dataset names, file names, query text, or generated results.

IRB protocol language

No participant data, and no identifiable derivative of participant data such as column names, dataset names, or query text, is transmitted off the device running CLAIR. This is enforced structurally: outbound network payloads have no field capable of carrying dataset content. A compliance kit, including a data-flow diagram, a no-content-egress attestation, and an offline-verification checklist that can be reproduced independently, is available at [insert the CLAIR trust page URL].

FERPA-covered data

Where CLAIR is used with FERPA-covered student records, column names (such as student identifiers or grade fields) and dataset names are never transmitted off the device. Where a size signal is needed for performance tuning, only coarse ranges are used, for example "10 to 25 columns," never an exact count that could identify a specific class section.