Privacy posture

Last updated

Solenoid keeps the map, not the territory. We’re built so a security-minded team can connect on day one: your raw source content transits Solenoid, is processed transiently, and is not stored. We separately describe the narrow, anonymous usage telemetry used to understand whether the marketing experience works.

The posture in one line

Read-only · BYOK · raw content processed transiently · never stored · every answer cited.

What we never store

We never store your meetings, customer calls, or strategy. Your tickets, PRs, threads, and documents are processed transiently and discarded. Raw content submitted through a marketing or free-tool path is not stored by that path and is not included in usage telemetry. There are no database schemas for your raw content — we keep only pointers, derived metadata, and citations back to your own sources.

Anonymous marketing telemetry

When marketing telemetry is enabled, Solenoid sends anonymous pageview events to PostHog, our product-analytics processor. The event contains a non-identifying, per-tab random id and the ordinary URL path needed to count the page. It does not contain URL query strings or fragments, referrers, raw submitted content, or known dynamic capability ids such as a free-tool run UUID.

These events explicitly disable PostHog person profiles. The PostHog environment is also required to discard client IP data before browser telemetry can be enabled, so the IP is not retained with the event. As with any direct network request, PostHog may process the address transiently before discarding it; our promise is no IP retention, not that the processor cannot see a network connection.

Read-only connectors, approved pull requests

Connectors are read-only — Solenoid reads from your sources and never writes back through them.

Some sources are read as content in the moment (Slack messages and Linear issues); only the derived result is kept — a cluster or count — never the raw text. The one thing Solenoid can write is a pull request: only in a repository you’ve enabled, only when you approve that run, and never through a connector.

You see the scopes before you authorize. Per source:

  • GitHub — issues and PRs.
  • Linear — issue identifiers, counts, and timestamps are persisted; titles, descriptions, and label names are not.
  • Slack — message text is read in the moment and clustered; the message body is not stored.
  • HubSpot — company and deal metadata (revenue, lifecycle stage, amount, stage, and close date). Live v0 requests no contact scope and reads no contacts.

Connecting your AI to Solenoid

The sections above describe connectors that read from your sources. The AI connector runs the other way: you connect Claude (or another MCP client) to Solenoid, and your assistant can then ask Solenoid questions and record decisions on your behalf. Because that direction can write, it is described separately here.

What it can read. Four read-only tools, all scoped to your own workspace: your ranked demand themes, the drift between your two most recent runs, and the status of a run. These return Solenoid’s derived output — clusters, weights, counts, timestamps, citations — under exactly the posture above. Connecting your AI does not give it a new path to your raw source content, because Solenoid does not hold your raw source content.

What it can write. Two tools, and only these two:

  • Recording a decision. When you ask your assistant to log a decision, we do store the note you asked us to keep: its title, the decision statement, and any context you include. This is the one place the “we keep the map, not the territory” posture is a deliberate exception — a decision you explicitly asked Solenoid to remember is the map. It is saved as a candidate and never becomes part of your brain until you ratify it yourself. Your assistant cannot ratify, edit, or delete an existing note.
  • Starting a run. Your assistant can start a demand-map run over the sources you have already connected. It produces the same derived output any run does.

Both write tools are published to your AI client as writes, so a client that honours those hints prompts you before running one — and starting a run is additionally capped per day. Neither tool can reach another workspace: every call is bound to the workspace the connection authenticates, and a request that cannot be resolved to exactly one workspace is refused rather than guessed.

Storage and retention. Recorded decisions are kept in your workspace. You can discard any candidate from the decisions inbox — a discarded note is dropped from your queue and can never be ratified — but discarding sets it aside rather than erasing it, and we retain the record. To have decisions permanently removed, ask us and we will delete them. Tool calls also produce an operational record used to run and debug the service: which tool ran, which workspace, the permissions held, and a size estimate. That record carries no note text, no theme content, and no conversation content.

Third parties. Connecting your AI adds no new processor on our side, but it does put your assistant’s provider in the data path, and we want to be exact about how. When your assistant calls a tool, Solenoid sends the result directly to that provider’s infrastructure — that is how the answer reaches your conversation. So workspace-derived data does leave us for your provider, every time a tool runs.

What stays true is who starts it: that transfer only ever happens in response to a call your assistant makes under your authorization. We never push your data to a provider on our own, and we hold no connection you did not create. Once the result reaches them it is governed by your agreement with that provider. You can disconnect at any time from your AI client’s own connector settings, and no further data leaves us for it.

Authorization. The connection uses OAuth 2.1 with PKCE; sign-in is handled by our identity provider and we never see your password. If you connect a command-line client instead, its access token is shown once, stored only as a one-way hash, and can be revoked from your Solenoid settings at any time.

Questions, or a deletion request — including permanently deleting recorded decisions — reach us at [email protected].

BYOK — your provider, your terms

LLM inference runs on your own Anthropic key, under your provider’s enterprise zero-retention / no-train terms — you’re billed by your provider for inference, by us for the brain. Solenoid never uses its own keys for your inference. We’re precise about what hosted means: your content does transit our pipeline to be processed, so

we claim never stored, not “never seen” — the stronger never-sees posture is the Enterprise tier below.

Every answer cited

Every claim, quote, decision, and constraint links back to its source — a permalink, a PR, an issue. If we can’t cite it, we don’t say it.

Email capture

When you join the waitlist, we store a one-way salted hash of your email — never the raw address. We use it only to send you the walkthrough you asked for and to de-duplicate signups. We use Resend to send; we keep the map, not the territory, for our own submission flow too.

This page summarizes the posture locked in ADR 0021.

▸ Regulated industry (healthcare · finance · government)? The Enterprise tier runs the data plane inside your own environment — the stronger never-sees posture, where your content never leaves your infrastructure (ADR 0070). On our roadmap for regulated buyers — talk to us.