Privacy policy

ShipSignal lets people suggest and vote on features for a software product. When a front-end request gets enough votes, ShipSignal drafts the change as a pull request on GitHub, and a person on the product team reviews it. This policy explains what ShipSignal keeps, why it keeps it, and who can see it.

ShipSignal runs this service. This policy takes effect on October 19, 2026. It covers the ShipSignal web app, its public boards, and the A/B test script that product teams can add to their own sites.

Team members sign in with an email address and a six-digit code sent to that address. The app has no password sign-in. Each sign-in code expires after 10 minutes.

• Your email address, which is your sign-in name.
• A display handle. ShipSignal creates it when your account is first made, from part of your account ID, for example user-1a2b3c4d. Your team sees this handle instead of your email address. This version has no screen for changing it.
• Projects you create: the project name, the board address, whether the board is published, the two request thresholds, and the GitHub login of the approver.
• Who belongs to each project, and whether each person is an owner or a member.
• The GitHub repository connected to a project: its ID and name, its default branch, the GitHub App installation that reaches it, the team member who connected it, and when.
• Decisions: when an approver approves or rejects a request, we keep the decision, the approver's GitHub login, and any reason they wrote, up to 500 characters. A rejection needs a reason.

To count a suggestion or a vote, a voter confirms an email address with a six-digit code. Our sign-in service, Supabase Auth, stores that address. Our own tables do not hold email addresses.

• Suggestions: the title, from 5 to 120 characters, the details, up to 2,000 characters, the date, and the account that suggested it.
• Votes: the request voted for, the account, and the time. Each account counts once for each request.
• A short record of each confirmed suggestion or vote, so that a retry of the same action counts once.

The public board shows each request's title, its status, and its vote count. It shows whether you have voted only while you are signed in. It never shows email addresses, display handles, or who suggested a request. Team members see a request's details, and the display handle and time of each verified vote. They never see a voter's email address. A signed-in team member's header shows the address they signed in with.

While a voter confirms an email address, the board's browser tab keeps in its session storage the voter's sign-in token, any suggestion or vote waiting for the code, and any suggestion text not yet sent. Browsers clear session storage when the tab closes.

• Requests: the status of each request, its change class (front-end, back-end, or access-controlled), and any link to a duplicate request.
• Draft records: for a front-end request that reaches its threshold, the draft's status, its repository and branch, the pull request number and link, the AI model used, token counts, the estimated cost in US dollars, and a short reason if the draft fails.
• Audit events: a record of important actions, such as a request reaching its threshold, a draft starting or failing, a decision, a repository connecting or disconnecting, an approver linking, a test locking, and a change shipping. Each record holds the event and its time. Where they apply, it also holds the project, the request, and the account that acted, along with simple values such as a pull request number or a decision. It does not hold tokens, email addresses, or request text.
• Webhook records: for each update GitHub sends about a pull request, we keep the delivery ID, the event name, the result, and when it arrived, so that a repeated delivery does nothing. We do not keep the rest of the update.

A product team connects one GitHub repository to a project by installing the ShipSignal GitHub App on it. The app asks GitHub for three permissions: read and write access to repository contents, read and write access to pull requests, and read access to repository metadata. It listens only for pull request events.

When a front-end request reaches its threshold, ShipSignal reads a limited set of text files from the repository's default branch. It chooses files that match the words in the request, plus a few standard entry points. It then creates a branch and commits the proposed change, and opens a draft pull request as the app. The request's title appears in the branch name, the commit message, and the pull request title. The pull request description links back to the request and holds a summary of the change. ShipSignal does not merge pull requests. A person reviews them and merges them on GitHub.

We do not save copies of repository files in our database. The drafted code lives in the pull request on GitHub.

A project names one approver by GitHub login. To act as the approver, that person links their GitHub account to ShipSignal. We then keep their GitHub user ID and login, the time they linked, the access token GitHub gives us for them, and when that token expires. The token is stored encrypted, with a key that only our server holds. We use the token only to confirm the approver's GitHub login and to post their review on a pull request when they approve or reject a change.

Installing the app and linking an approver use short-lived codes. Each code works once and expires after 15 minutes. We keep each code with the user and project it belongs to, and its expiry and use times.

To draft a change, ShipSignal sends the request's title and details, and the text of the repository files it chose, to Google Cloud's Vertex AI. A Google Gemini model returns the proposed change. Google Cloud processes that content to produce the answer.

ShipSignal treats the request text as a description of what someone wants, not as instructions to the model. Every proposed change is checked before it reaches GitHub. A change can touch only front-end files. Paths for server code, routes, configuration, dependencies, migrations, and authentication, permission, or secret code are refused, and so is any change that contains a value that looks like a credential.

Back-end and access-controlled requests are not drafted by AI. A person builds them. Each project also has a daily limit on how many drafts it can start, and the default is five.

When a change ships, ShipSignal writes one credit entry for the person who suggested it, and one for each person who voted for it. Each entry holds the account, the request, the role (suggested or voted), and the time. Credit entries contain no money or payment fields.

Team members can read the ledger and export it as a CSV file. The file lists each shipped change with its title and ship time. For each credit entry it lists the contributor's display handle, role, and time, and the lift measured in the test. It does not include email addresses.

When a product team starts a test, we keep its primary metric, base rate, minimum lift, length, goal event name, and ship or revert rule, with the time the rules were locked. The rules cannot be changed after that.

A product team can add ShipSignal's test script to its own site and link it to an experiment. The script gives each browser that allows local storage a random visitor ID, kept under the name shipsignal.visitor. That ID stays in the browser until the visitor clears site data. The script sends the project, the experiment, and the visitor ID to ShipSignal's servers. After a goal is recorded, the script keeps a flag in local storage, so that the same browser does not send the goal twice.

ShipSignal keeps the visitor ID, the experiment, the variant the visitor saw (A or B), when the visitor was assigned, and whether and when a goal was recorded. The visitor ID is not linked to any ShipSignal account. Our experiment records hold no IP addresses. Rate-limit counters hold hashes, not addresses or visitor IDs.

The team that runs a test should tell its own visitors about it in its own privacy policy. This policy covers ShipSignal only.

These companies process data for us so that ShipSignal can run.

• Supabase: our database and sign-in service. It holds account records, including email addresses.
• Resend: the email service that delivers the sign-in codes Supabase sends.
• Vercel: hosts the web app and runs its server code.
• Google Cloud: runs Vertex AI, which drafts proposed changes.
• GitHub: holds the connected repositories and the draft pull requests, and handles the GitHub App and approver sign-in.

Every request to ShipSignal reaches our hosting provider, which receives the connection details that any web request carries. ShipSignal uses no third-party advertising or analytics services on its own pages, and those pages load no scripts or fonts from other companies.

ShipSignal sets cookies that keep you signed in. We do not set advertising or tracking cookies.

Browser storage holds the items described above: a voter's sign-in token and unsent suggestion text in a board tab's session storage, the A/B visitor ID and goal flag in a test site's local storage, and a few display settings that stay in one tab, such as a motion setting you turned off.

We keep account records, projects, requests, votes, decisions, draft records, audit events, credit entries, and test records until someone deletes them. The board, the approvals, and the credit ledger depend on them. This version has no automatic deletion schedule.

Sign-in codes expire after 10 minutes. Installation and approver codes expire after 15 minutes and work once.

• Sign out to end your session in that browser.
• This version has no button for deleting your account or downloading your data. To ask for either, email shipsignal@outerscope.xyz.
• Project owners can change the approver, connect or disconnect the repository, and publish or unpublish the board from project settings.

• Sign-in uses one-time codes sent by email.
• Database rules limit each signed-in account to its own records and to the records of projects it belongs to. Only the server can write privileged records, such as thresholds, decisions, and draft records.
• Approver GitHub tokens are encrypted before they are stored, with a key that only the server holds.
• Server-only keys stay on the server and never reach the browser.
• To limit abuse, we count requests per network address and, for sign-in, per email address. The counters keep only hashes of these values.
• Server logs record IDs and error messages.

No online service can promise perfect security. If you think something is wrong with your data, email shipsignal@outerscope.xyz.

When we change this policy, we change the date at the top of the page.

For questions about this policy or about your data, email shipsignal@outerscope.xyz.