Cookies
Cookies in the Pinavia app
The app sets only the cookies required to sign you in and keep your session secure. It sets no analytics cookies, no advertising cookies, and nothing that tracks you across sites — which is why you see no cookie banner here.
This notice is a complete draft prepared for legal review. It describes the cookies the product sets today, verified by direct inspection. If your procurement process requires a counsel-approved cookie notice before onboarding, request the reviewed version at hello@pinavia.io.
Why there is no cookie banner
Consent law asks for a choice where a choice exists. The app offers none to make: every cookie it sets is strictly necessary for signing in and holding a secure session, and consent rules exempt exactly that category.
A banner whose only category is a locked “always on” would be theatre — an interruption asking you to approve something that requires no approval. We publish this inventory instead, and commit to it staying true.
The one use of browser storage that is off by default is product improvement, described below. It is not decided by a banner: it is off unless the workspace owner switches it on in workspace settings, and Pinavia tells the customer before switching it on for them.
The complete inventory
Authentication runs through a managed identity provider, and its session cookies are the only cookies the app sets. The section after this one covers the browser storage the app uses, which is not a cookie but is disclosed here for the same reason:
- __session — your signed-in session with this workspace. Expires when the session does.
- __client — identifies this browser to the sign-in service so your session can be refreshed securely.
- clerk_active_context — remembers which organisation and workspace you are acting in, so approvals are attributed to the right context.
Other browser storage
Cookies are not the only way a site can keep something on your device, and consent rules cover the rest of it too. The app also uses your browser's local and session storage. Settings and navigation history stay on this device. Decision drafts and operation-recovery data are used only when you submit, retry, or check that decision work. Clearing site data in your browser removes every entry:
- nexus.company-setup-helper.dismissed — remembers that you closed the setup guide so it does not reappear.
- pinavia.nav.collapsed — remembers whether you collapsed the sidebar to the icon rail.
- pinavia.palette.recents — the last few screens you opened from the search palette, so it can offer them first. This is the one entry that records where you went rather than a setting; it never leaves this browser.
- pinavia.lastRoom.<workspace>: the last room you opened in each workspace, so the app can take you back to it when you return. It holds a room reference only and never leaves this browser.
- nexus_readiness_claim — carries your readiness-check claim code into onboarding. Cleared when you close the tab.
- pinavia:decision-draft — holds a decision you are part-way through writing while you move between screens. Cleared when you close the tab.
- pinavia:recommendation-decision-operation:v1 — holds one frozen recommendation-to-decision request, including its title, rationale, owner seat, deadline and status, plus an operation ID, request hash, saved time and an opaque binding to your current account and workspace. It lets the app check or safely retry the same operation after an interrupted response. Cleared after the saved record reopens successfully, when you close the tab, or when you clear site data.
- nexus:quorum-cycle-receipt:<record ID> and nexus:vantage-memo-receipt:<record ID> — one-time confirmations of a just-created governed record's server receipt. They contain an audit reference and are removed as soon as the reopened record reads them; they are not the audit record itself.
- A small number of entries whose names begin ph_ or __ph_ — written only in a workspace whose owner has switched on product improvement (see below). They hold a pseudonymous account identifier (an internal user id, never a name or email), the current visit, and replay data waiting to be sent. Nothing is sent once the switch is off, but the entries stay in the browser until site data is cleared.
Product improvement, only where the owner switches it on
A workspace owner can switch on product improvement in workspace settings. It is off unless they do, and Pinavia tells a customer before switching it on for them. When it is on, an EU-hosted product analytics service receives which screens are opened and which steps are completed, with record identifiers removed from page addresses. It never receives document, evidence or decision content, prompts or AI answers, file names, page titles, names or email addresses.
Session replay is a second, separate switch. When it is on, the service receives a replay of clicks and page layout in which all text and everything typed is masked, and images, previews, frames and file names are blocked.
This uses the browser storage entries listed above, not cookies, and goes through Pinavia's own address, so no sign-in cookie or session token reaches the service.
What the app does not set
No analytics cookies, no advertising or social-media pixels, no cross-site identifiers of any kind. There is no Google Analytics and no fingerprinting, and nothing in the app follows you to other sites.
The marketing site is governed separately
pinavia.io — the public marketing site — has its own cookie controls, including a preference center reachable from its footer, because marketing surfaces may carry measurement that the product does not. Its consent choice is stored against pinavia.io only and does not follow you into the app.
If this ever changes
Adding any cookie beyond the sign-in set is a product decision, not a configuration change. It would require consent infrastructure to ship first, this notice to be revised with a new effective date, and existing customers to be told. Until all three happen, the two inventories above are the complete list, and a test in the codebase fails if the app's own code starts writing a browser-storage key this page does not name. The product improvement entries are written by the analytics library itself; its version is pinned exactly, and a test fails if that pin or the ph_ and __ph_ disclosure is removed, so a library upgrade is a reviewed change.