Spexd (“Spexd”, “we”, “us”) is a software-specification traceability tool that helps teams link requirements, acceptance criteria, design, and tasks. This Privacy Policy explains what information we collect when you use Spexd, how we use it, and the choices you have. By using Spexd you agree to the practices described here.
Information we collect
We collect the following categories of information:
- Account and identity information. Authentication is handled by our identity provider, Clerk. When you sign up or sign in we receive your name, email address, and the organization(s) you belong to. Sign-in is by Google or GitHub single sign-on only — Spexd neither asks for nor stores a password.
- Content you create. The specifications you author in Spexd — features, requirements, acceptance criteria, designs, tasks, and the links between them — along with any text or documents you add to them.
- Usage and technical data. Basic information sent by your browser and generated as you use the service, such as pages viewed, actions taken, and diagnostic logs used to keep Spexd running reliably.
How we use your information
We use the information we collect to:
- Provide, operate, and maintain the Spexd service.
- Authenticate you and scope your access to your organization's data.
- Respond to your requests and provide support.
- Monitor, secure, debug, and improve the reliability and performance of the service.
We do not sell your personal information, and we do not use the content of your specifications for advertising.
Where your data is stored and who processes it
Spexd relies on a small number of trusted third-party providers to operate the service. Each processes data only to provide their part of the service:
- Clerk — authentication and organization management.
- Railway — application hosting and delivery, and the PostgreSQL database that holds the relational traceability graph (entity records and the links between them) and the document content attached to each specification.
- OpenRouter — the AI model provider for our in-app AI assistant, for the relevance check we run when a specification is published, for matching GitHub work to its specification task, and for indexing specifications so they can be found by meaning. When you use the AI chat, your messages and the relevant specification content are sent to the model provider to generate a response, and for no other purpose. OpenRouter passes each request on to an upstream provider that runs the model (see AI features and automated processing below for who those can be), and every request we send requires that request and response contents are not retained and not used to train models. See OpenRouter's privacy policy and its zero-retention documentation.
If your organization brings its own AI provider. An organization can be configured to use its own model provider and its own credentials for the AI assistant. Where that applies, the AI content described above is sent to that provider instead of the one named here, under your organization's own arrangement with them — their terms, their retention and training settings, and their billing — rather than ours. Your organization's administrator chooses that provider; if you are unsure whether it applies to you, ask them.
Four exceptions: conversation titles, the publish relevance check, GitHub work matching and search indexing. Each AI chat conversation is given a short label derived from its first message, so you can find it again in your history. That label is generated by us, on the provider named here and our credentials, for every organization — including one that brings its own provider — so it is not sent to your organization's provider. It carries the same zero-retention routing described below as any other request we send.
The same is true of the relevance check. When a specification is published, we check which of the specifications beneath it the change affects, so that approvals it does not affect can stand. That check is run by us, on the provider named here and our credentials, for every organization — including one that brings its own provider. It sends the change and the specifications it is weighed against, and nothing is sent to your organization's provider for it. It carries the same zero-retention routing described below as any other request we send.
And of GitHub work matching. Where your organization has connected GitHub, we suggest — and, when the match is clear, record — which specification task a branch or pull request implements. That matching is run by us, on the provider named here and our credentials, for every organization — including one that brings its own provider. It sends the branch name, or the pull request's title and description, and the reference, title, status and opening content of each candidate task, and nothing is sent to your organization's provider for it. Where the work names no task, its branch name, title and description are also sent to the embedding model to find candidate tasks by their meaning among your organization's open tasks. Both carry the same zero-retention routing described below as any other request we send.
And of search indexing. To let related specifications be found by their meaning rather than only by their words, we send each specification's title and content to the provider named here, on our credentials, for every organization — including one that brings its own provider — and keep the numeric summary it returns in our search index. The text of a search made through the API or by an AI agent is sent the same way, so the search can match by meaning. Nothing is sent to your organization's provider for either. Both carry the same zero-retention routing described below as any other request we send.
Your data is scoped to your organization: access is restricted so that members of one organization cannot read another organization's data.
AI features and automated processing
Spexd offers AI-assisted features that operate on your content:
- AI chat assistant. Spexd includes an in-app AI assistant that can read your specifications and help you draft and refine them. When you send it a message, the assistant runs on our servers and sends your messages, along with the specification content relevant to your request, to an AI model provider (OpenRouter, or your organization's own provider if it has configured one — see above) to generate a response. Only the content needed to answer your request is sent, and it is processed only to return the assistant's reply. Where we provide the model, we configure it so that request contents are not retained and not used to train models; where your organization brings its own provider, those settings are governed by its arrangement with that provider. Actions that change your data (such as creating, editing, or publishing an entity) are only ever proposed by the assistant and require your explicit confirmation before they run.
- Publish relevance check. When a specification that has approvals beneath it is published, Spexd checks which of those approved specifications the change affects, so that only affected approvals are withdrawn. We run this check ourselves for every organization, on OpenRouter and our credentials, even where your organization brings its own provider (see above). It sends the change and the specifications being weighed against it, and nothing else, and every request requires that its contents are not retained and not used to train models. It decides only whether an approval stands; the reason shown for its decision states the outcome and how confident the check was. Where it cannot decide, the approval is withdrawn as a precaution.
- GitHub work matching. Where your organization has connected GitHub, Spexd matches a branch or pull request to the specification task it implements, from the branch name, or the pull request's title and description, and the candidate tasks' references, titles, statuses and the opening of their content. Where the work names no task, its branch name, title and description are sent to an embedding model to find candidate tasks by their meaning among your organization's open tasks. We run this ourselves for every organization, on OpenRouter and our credentials, under the same zero-retention requirement. A task is linked without a person only when one candidate is a clear match; otherwise the best candidate is offered as a suggestion for a member to confirm.
- Search indexing. So that related specifications can be found by their meaning, Spexd sends each specification's title and content to an embedding model and keeps the list of numbers it returns in our search index, beside the words already indexed there. We run this ourselves for every organization, on OpenRouter and our credentials, under the same zero-retention requirement. A specification is sent again only when its title or content changes. The text of a search made through the API or by an AI agent, including the in-app assistant, is also sent to the same embedding model under the same zero-retention requirement, so that the search can match by meaning; we record that a search was made, but not its words. Searches typed into Spexd's own search box are matched by their words alone and are not sent.
- MCP server. Spexd provides a Model Context Protocol (MCP) server that lets you connect external AI assistants and agent tools to your Spexd workspace. When you connect a client through the MCP server, it can read and act on the specification data your organization has granted it access to. Access is authenticated and scoped to your organization, but any assistant or tool you connect is operated by you or a third party and handles your data under its own terms, not this policy.
Onward routing. OpenRouter does not run the models itself. It passes each request on to an upstream model provider that serves it, and which provider serves any given request varies from request to request. Every request we send requires zero-retention routing, so the providers that may receive your content are limited to those OpenRouter publishes as operating a zero-data-retention policy for the model we have configured. For the frontier models we use those are principally the cloud platforms that host them — Amazon Web Services (Bedrock), Google Cloud (Vertex AI) and Microsoft Azure — since a model vendor's own first-party endpoint can receive your content only where it too operates a zero-retention policy. The publish relevance check and GitHub work matching use a model served by its developer, TypeSafe, which receives their content under the same zero-retention requirement. Search indexing uses an openly published embedding model, served by the providers OpenRouter lists as operating a zero-data-retention policy for it. OpenRouter publishes the current list of zero-retention endpoints, and where no such provider is available for a request, that request fails rather than being routed to one that retains data. Where your organization brings its own AI provider this does not apply to the requests we send to it: that provider, and any onward routing it performs, are governed by your organization's arrangement with it. It does still apply to the conversation titles, the publish relevance check, GitHub work matching and search indexing described above, which we run ourselves in every case.
Data retention
We retain your account and content data for as long as your account or organization remains active, and as needed to provide the service. When data is deleted, it is removed from our active systems; residual copies may persist in backups for a limited period before being overwritten.
Security
We take reasonable technical and organizational measures to protect your information, including access controls that isolate each organization's data and encrypted connections in transit. No method of transmission or storage is completely secure, so we cannot guarantee absolute security.
Your rights and choices
Depending on your location, you may have the right to access, correct, export, or delete the personal information we hold about you. You can update much of your account information directly within Spexd, and you can contact us to make any other request. We will respond in accordance with applicable law.
Children's privacy
Spexd is a tool for software teams and is not directed at children. We do not knowingly collect personal information from children.
Changes to this policy
We may update this Privacy Policy from time to time. When we do, we will revise the “Last updated” date above. Your continued use of Spexd after a change takes effect constitutes acceptance of the updated policy.
Contact us
If you have questions about this Privacy Policy or how we handle your information, contact us at admin@spexd.com.