klementyneOpen klementyne

Privacy & architecture

This page explains exactly where your data lives and precisely what leaves your device, when, and why. It's written to be the answer you paste into a security review — an engineering description, not boilerplate.

The default: everything stays here

Your portfolios — pillars, tasks, updates, notes, goals, team roster — are stored in your browser's own database (IndexedDB, marked persistent), on your machine. There is no account, no sign-up, and no server-side copy. Closing the tab changes nothing; the data is simply there when you come back, like a local file.

The AI features (pillar suggestions, board regeneration, activity summaries, report narratives, Ask) run on your device — via your browser's built-in model or a locally downloaded one. Prompts and your data are processed in your browser's memory and are never sent to a klementyne server, because none of the AI features have one.

Backups and exports (Excel, CSV, Markdown, diagrams, JSON) are generated in the browser and saved directly to your disk.

What leaves your device — only when you use these, only what's listed

Jira & Confluence integrations (optional). When you connect Atlassian and pull or push, requests pass through klementyne's stateless proxy functions to Atlassian's API — required because browsers can't call Atlassian directly (CORS). The proxy forwards your request and Atlassian's response without storing either. If you use an API token, it's kept in your browser's storage and sent only inside those proxied requests; if you use OAuth, the connection tokens are held server-side keyed to your browser, and your portfolio data still never accompanies them — only the specific issue keys, project keys, or page content you explicitly pull or push.

Local sync folder (optional). If you connect a folder on your own machine (via the browser's File System Access API), klementyne mirrors your event journal and current state into files there — nothing about this involves a network request, to us or anyone else. It exists so an agent you run yourself, such as Claude Code, can read that folder and propose actions like a Jira update by writing to an inbox file you control; the app applies those the same way it applies anything else in the product, and every mirrored journal line carries the same hash chain as the source of truth, so tampering with the folder is detectable. The folder also gets a dated snapshot once a day, kept for the last 30 days, separate from the live mirror — recoverable in one click from the “Board missing?” link if local storage is ever cleared or overwritten by mistake. Disconnecting the folder at any time stops the mirror; nothing about your portfolio depends on it.

Server AI drafting (optional, off by default). If a deployment has a server-side AI key configured and you click "Draft here", the compiled report text — and nothing else — is sent to that AI for drafting and is not stored. The on-device path never does this, and a Settings preference can force copy-prompt-only so no draft ever leaves the browser.

Feedback (optional, explicit). Thumbs-up/down votes and feedback you type in the feedback form are sent with a random anonymous id. Votes carry the vote and its context label (e.g. "narrative, exec tone") — never the content it was about. Your portfolio data is not attached.

Optional cloud account (Team features). Everything above works signed-out, and signed-out is the default. If a deployment offers Team features and you explicitly sign in and sync a portfolio, that portfolio is then stored with the cloud provider for sharing — a deliberate, visible choice, never a background migration.

Analytics. Two separate things, both narrower than they sound. First, site-wide pageview analytics on the marketing pages (which page, roughly how many visitors) — cookieless, aggregate, always on, and it never sees anything inside the app itself. Second, in-app product analytics — onboarding step reached, feature turned on, view opened, that kind of thing — which is off by default and stays off until you explicitly turn it on, either during onboarding or in Settings → Data & privacy. When it's on, the only things it can ever send are that fixed, enumerated list of interaction events — there is no code path that lets a task title, a pillar name, board content, or Jira data reach it. Turning it off stops it sending anything, immediately.

What we can't do

We can't read your board, mine your updates, train on your reports, sell your data, or hand it to anyone — not as policy, but as physics: in the default local mode it never reaches us. No analytics script ever sees what's inside your portfolio — even the opt-in one is built so it structurally can't — and there are no ads. The honest flip side: we also can't recover your data if you clear your browser storage without a backup — export one from Settings, it's your data and your responsibility in the best sense.

Your exit

Every portfolio exports completely — a full JSON backup, plus Excel, CSV, Markdown, and diagram formats, and direct pushes to Confluence and Jira. Leaving klementyne with all of your data intact is a one-click operation, permanently. We think that's the only relationship with your data a tool should be allowed to have.

Questions a security review needs answered beyond this page? Use the feedback form in the app — this page is kept in lockstep with the architecture it describes.

klementyne.appAbout & the namePrivacy & architecturefree · your data stays on this device