Privacy Notice

PLIXO LABS LTD, trading as Wrengle, is the controller for personal data handled through this website, the account and sync services, support email, and the optional website analytics and diagnostics. Contact support@wrengle.com.

Visiting wrengle.com, creating an optional account, using the dashboard, emailing support, downloading a release, basic cookieless measurement on reviewed public pages unless you object, optional document sync, and the enhanced analytics or diagnostics you explicitly agree to. Having an account alone does not move your work off your machine.

Signing in alone does not copy your notes, transcripts, chart files, or search index into account storage. Generative AI still uploads the bounded content disclosed for its selected cloud route. On a clean install, assistant chat starts on Wrengle AI Fast; upgrades keep their existing explicit or Automatic choice, and you can switch routes. With your own OpenAI or Anthropic key — including the built-in assistant's cloud-only Automatic route — the bounded text or context the app shows for the request goes straight to that provider under its own terms, and does not pass through us. With Wrengle AI, the same text content comes to us first and we pass it to OpenAI. The text-only mappings are Fast to GPT-5.6 Luna, Balanced to GPT-5.6 Terra, and Deep to GPT-5.6 Sol; the service reports which priced tiers are currently enabled. They do not receive image prompts or fall back to another route. Prompts and replies transit Wrengle and OpenAI for generation, but we do not retain that content in the account ledger or application logs. OpenAI's own service handling still applies. Separately selected cloud transcription, sync, external-agent, and integration providers handle only the data disclosed for their feature. The Privacy and AI page covers exactly what goes where.

Sync is off by default and is turned on per vault from Settings → Account in the desktop app. When it is on, that vault's notes, charts, whiteboards, and whiteboard images, including note YAML frontmatter, and its folder structure are stored on Wrengle's sync service so your own computers stay the same, including documents you do not have open. Validated edits are saved locally before upload. Server copies are encrypted in transit and at rest, but Wrengle can technically read them to operate the service. Unaccepted agent previews are not uploaded. Sync consent does not authorize AI processing of those documents.

Where team workspaces are enabled, Wrengle stores workspace names, membership, roles, invitations, and vault assignments to administer access. Workspace admins can access all team vaults; members access only assigned vaults. Team-owned content survives an individual account deletion. Removing access stops future sync but cannot erase downloaded files. Workspace image allowances are separate from personal allowances, and AI credits remain personal.

Where sharing is enabled, the owner can invite up to 20 editors to the same vault. Editors can read, change, and delete its synced content. We store memberships and revocation records. Removing access stops future sync within five seconds; downloaded local files remain on collaborators' computers. Deleting an owner's account removes their remote shared vaults. Deleting an editor's account does not delete those vaults.

Invitation emails go through Resend and include the recipient address, owner display name, vault name, and invitation link. Links expire after seven days and require a matching verified account email. We disable open and click tracking and keep no document excerpts in invitations. Terminal invitation and delivery payloads are removed after the documented 30-day retention window; active membership records remain while needed to control access. Send-limit records contain keyed digests and expire after 48 hours.

Whiteboard image bytes are transferred and stored separately from drawing data. Images removed from a drawing remain on the server until the vault or account is deleted, following the vault retention period below, so offline devices can still recover them.

Attachments outside whiteboards do not sync. Turning sync off keeps your local files and does not delete existing server copies. Removing a vault from the server marks its copy for deletion; we keep it for 30 days, then delete it permanently. Deleting your account removes your synced documents from our database. Synced documents are stored in the European Union (Germany). Keep your own independent backups. See Sync across your computers for what syncs and what does not.

• Your account: the identifier Clerk gives you, your email address, first and last name, profile image, how you sign in, and your session. We keep a copy of the fields the dashboard needs and the ones required to handle deletion properly.
• Your synced documents: note and chart content, note YAML frontmatter, your vault's folder structure, vault and document identifiers, and device identifiers and connection activity needed to deliver optional sync.
• Your desktop account grant: Clerk issues the public desktop client a signed JWT access token and a refresh token after system-browser sign-in with PKCE. The JWT can contain readable identity, client, and scope claims, so Wrengle treats the whole value as a secret. The refresh token and cached account summary stay in the operating-system keychain; the access JWT stays only in protected native-process memory and is reacquired after an app restart. Neither token is put in your vault, logs, or telemetry. Desktop sign-out removes the local bundle first, then sends the refresh token directly to Clerk for revocation. This prevents future refreshes but cannot invalidate a JWT already issued by Clerk; a copy obtained before sign-out can remain valid until it expires, for up to one day.
• Using Wrengle AI: when Wrengle AI is the selected route — including the clean-install Fast default — your prompt and bounded note or transcript context are uploaded to us, sent to OpenAI, and the reply returns through us. We do not retain that content in the account ledger or application logs. What we keep is the cost record: the account it belongs to, which feature spent it, the tier and model that ran, Wrengle and provider request identifiers, the input, cached-input, cache-write-input, output, and reasoning token buckets the provider reported, the credits charged, price version, metering status, and time. If final usage is unavailable, the ledger marks an estimated ceiling charge and does not claim a zero token count. That record contains no prompt, no reply, and no note content.
• Buying credits: Polar takes the payment as merchant of record and gives us the order reference, the product bought, and the account it belongs to, so we can add the credits. Your card details never reach us. Creating an account or signing in does not grant a free or recurring credit balance. Checkout can be unavailable while an existing ledger remains visible.
• Signing in with Google: if you pick Google, it gives Clerk your Google account identifier, email address, name, profile image, and the fact that you signed in successfully. That is sign-in only — it does not give us access to your Gmail, your Google Calendar, or anything else in your Google account.
• Connecting Google Calendar: this is a separate desktop connection. Google supplies event identifiers, titles, and start/end times for owned timed events in your primary calendar. Wrengle keeps those rows in a local cache for no more than seven days. If you select an event, its Google event identifier, source, title, and times are copied into the frontmatter of the meeting note you own and remain there until you edit or delete the note.
• Connecting and using Jira: the editor Jira action requires a Wrengle account and a separate Atlassian OAuth approval for read:jira-work, write:jira-work, and offline_access. OAuth access and refresh tokens stay in your operating system keychain. Our account service keeps only encrypted, short-lived authorization handoff and refresh-replay records, which expire automatically; it does not keep your long-lived Jira tokens. Atlassian supplies the identity, Jira Cloud sites, projects, and issue types needed for the selectors. When you create a ticket, Atlassian receives the selected site, project, and issue-type identifiers plus the summary and description you reviewed.
• Your profile: an optional display name and role preference, plus timestamps and internal identifiers that keep changes to your account in the right order.
• A record that you deleted your account: a scrambled, one-way fingerprint of your old account identifier, plus when the deletion happened. It holds no email, no name, and no usable identifier — but we can still recognise it if the same account turns up again. It exists so a delayed message cannot quietly recreate an account you erased.
• Support: your email address and whatever you choose to tell us when you write to support@wrengle.com.
• Keeping the service running: the network and request details needed to serve the site, stop abuse, rate-limit account endpoints, and investigate incidents.
• Basic cookieless website analytics: unless you object, Wrengle sends only page-view and page-leave events for successfully rendered, reviewed public marketing, legal, and documentation routes. Each event is limited to the canonical page URL and path with query strings and fragments removed, the site hostname, the referring origin and domain, browser, operating system, coarse device type, event time, and technical PostHog event identifiers, and fixed product, schema, and analytics-lane labels. It does not include account or protected routes, page text, clicks, form activity, Web Vitals, heatmaps, campaign parameters, autocapture, session replay, or a browser-stored PostHog identity. PostHog's cookieless service uses the project, hostname, connection IP address, user agent, and a salt that changes daily to make a server-side daily identifier; it is not stored in your browser and is not meant to recognise you across days. Events go through the managed t.wrengle.com proxy to the PostHog EU project, with IP geolocation disabled. We require that project to have Cookieless server hash mode enabled and to discard IP data after receipt. The browser deliberately sends no session or window identifier in this lane; with that project mode enabled, PostHog assigns the session used for Web Analytics during ingestion. Sessions therefore cannot follow a visitor through a browser-stored ID.
• Optional enhanced website analytics: this separate lane stays off until you explicitly switch it on. It adds PostHog Web Analytics, Web Vitals, and strictly allowlisted structural interactions only on the same reviewed public marketing, legal, and documentation routes. Sign-in, sign-up, callback, account, dashboard, admin, API, not-found, and failed routes are excluded, and a page event starts only after the router confirms a successful render. URLs are reduced to their canonical public path without query strings or fragments, referrers are reduced to their origin, and campaign identifiers are removed. Hard-navigation Web Vitals are assigned only to the successfully rendered public route that loaded the document; a later SPA route cannot claim them, and an excluded document route never becomes eligible by navigating to a public route. Metrics generated when a page is restored from the back-forward cache are rejected. Nested Web Vitals objects are rebuilt with only the metric name, value, delta, and rating. Interactions are rebuilt with only the event type, element tag, and bounded sibling positions; text, attributes, classes, IDs, selectors, link destinations, and custom augmentation values are removed. It can still receive page views and leaves, coarse browser and device details, viewport and session details, approximate geography, performance measurements, and that structural interaction data. A pseudonymous browser and session identifier may be stored after opt-in. Person profiles, feature flags, heatmaps, dead-click capture, and session replay remain disabled. Both lanes disable Beacon delivery and use credential-omitting fetch through the same managed EU proxy and project. Both lanes include fixed Wrengle website, schema, and analytics-lane labels to separate this site's events from other products, without adding user identity or content. We do not use either analytics lane for advertising.
• Optional diagnostics: stripped-down Sentry error reports. Details about you, the request, the surrounding context, the message, local variables, and file paths are removed or masked before anything can be sent. Reports cover browser route failures, uncaught errors, and unhandled promise rejections after diagnostics opt-in. They retain a coarse error type, area, environment, and release; this integration does not collect server/API errors, session replay, or performance traces.

• Clerk runs sign-in, sessions, your identity, and account deletion.
• Resend delivers shared-vault invitation emails using the address, owner display name, vault name, and link described above. It does not receive vault document contents through this email feature.
• Google handles the sign-in itself if you choose Google, and passes Clerk the identity details listed above. Signing in with Google does not switch on the separate Gmail or Google Calendar integrations. If you separately connect Calendar, Google supplies the limited event fields described above directly to the desktop app.
• Atlassian handles the separate Jira authorization and Jira Cloud API. It supplies the identity, sites, projects, and issue types needed for the editor selectors and receives the selected identifiers, summary, and description when you create an issue.
• Railway hosts the website and sync service, and Neon hosts the database containing account details and documents you opt to sync. Railway handles connection data, including IP addresses, to deliver those services and rate-limit abuse.
• The managed t.wrengle.com proxy and PostHog EU receive the minimized public-page events described above unless you object, and receive enhanced analytics only after you opt in. The proxy forwards events to the EU project. PostHog also receives the connection data needed to deliver an event and, for cookieless measurement, produce the daily server-side visitor identifier and ingestion-assigned session. We require the project dashboard to enable Cookieless server hash mode, discard IP data, and apply the stated retention limits.
• Sentry EU receives the stripped-down error reports, and only if you separately opt in to diagnostics.
• GitHub hosts the release pages and the installer files. Clicking through to a download tells GitHub about the request, under its own privacy terms.
• OpenAI runs the models behind Wrengle AI and receives the prompts and bounded context of those requests — from us rather than from your device, and only for accounts whose selected route is Wrengle AI. Using your own provider key instead sends the same content directly to the provider you named, with us not involved.
• Polar sells credit packs as merchant of record, so it receives what a purchase needs: your email address, the amount, and the tax details the sale requires.
• Our support and email providers handle messages you send us.

We do not sell your personal data, and we do not hand it over for advertising. We may disclose it where the law requires, to protect someone's rights or safety, or if the business is sold or restructured — in which case appropriate safeguards apply.

PostHog and Sentry are pinned to their EU regions, and we choose UK or European hosting wherever a supplier offers it. Documents you opt to sync are stored with Neon in the European Union (Frankfurt, Germany), and the sync service runs on Railway in the EU. Even so, some suppliers — or their support teams — may handle data outside the UK. Where that happens we rely on an adequacy regulation, the UK International Data Transfer Agreement or the UK Addendum to approved standard contractual clauses, and the supplier's own security measures.

• Your account and profile stay for as long as the account does.
• Synced document state is retained while sync is on for that vault. New state replaces the previous server snapshot; sync does not provide server-side version history. Turning sync off keeps the stored documents; removing a vault from the server marks them for deletion and we delete them 30 days later. Account deletion removes the associated synced documents from our database.
• Encrypted Jira OAuth authorization handoffs and rotating-refresh replay records are transient and expire automatically. Long-lived Jira tokens stay in your operating system keychain, not in the account database.
• Deleting your account removes your identity and profile records. The scrambled deletion fingerprint described above is kept, so an erased account cannot quietly come back.
• We do not put this site live until website analytics events are set to be deleted after 12 months at the most.
• We do not put this site live until error reports are set to be deleted after 90 days at the most.
• Support emails and security records are kept only as long as we need them for the request, a dispute, a security reason, or because the law says so.

Basic cookieless analytics is on for reviewed public routes unless you object. Use “Privacy choices” in the footer and switch off “Basic cookieless analytics”, choose “Decline all”, or send Global Privacy Control or an affirmative Do Not Track signal to stop it. A basic objection stops every PostHog analytics lane; enabling enhanced analytics also enables its required basic purpose. Enhanced analytics stays off until you explicitly switch it on. Diagnostics is a separate consent choice. Switching analytics off stops future PostHog capture and requests verified deletion of PostHog browser state. If the browser blocks deletion, capture remains off. A later analytics opt-in cannot start until the site can verify cleanup and can preserve that fail-closed state; clearing this site’s data removes it manually. A change between the basic and enhanced lanes is saved and then reloads the page so their identities and page-lifetime observers do not cross the boundary. The first view of that same canonical route is suppressed in either direction so the choice change does not count it twice. Switching diagnostics off shuts Sentry down. An event or error already handed to a provider client, including an in-flight or retrying request, may still finish delivery. We also clean up identifiers left in your browser by older versions of this site the first time you load it, and the retired app.wrengle.com address runs a one-off cleanup of its own cookies and storage before sending you here. Older objections remain objections. A saved choice from the immediately preceding notice is migrated without inventing a new enhanced consent; older grants are re-asked where their scope did not include the current purpose. Objecting to basic analytics or refusing or withdrawing enhanced analytics does not affect downloads, docs, the desktop app, or your account.

While your browser sends Global Privacy Control or an affirmative Do Not Track signal, all optional website analytics and diagnostics stay off regardless of a saved choice.

Depending on the situation, UK data-protection law gives you the right to see your data, correct it, have it erased, restrict or object to how it is used, take a copy elsewhere, and withdraw consent. You can also complain to the UK Information Commissioner’s Office at ico.org.uk. We would rather sort it out ourselves first, so please email support@wrengle.com.

We may update this notice as the beta develops. The effective date above tells you which version you are reading, and we will surface anything significant through the website or your account.