What moves, per event

When an admin approves the install, Slack redirects to our Convex HTTP endpoint with a one-time code, guarded by an anti-CSRF state value we issued. We exchange the code for a bot token over TLS 1.3.

• We store: the workspace (team) ID, the granted scopes, and the bot token (stored encrypted). We record the installer's Slack user ID and email to verify the email-match claim gate that links the workspace to an account.
• We never receive: any workspace member's messages, channel contents, or a user token. The bot token authorizes posting and reading channel lists, nothing more.

At the scheduled time we call Slack to post the question. The request carries the target channel ID and the question content as Block Kit blocks. No member data leaves Atomic Reps in this call.

When a member taps an option, Slack sends a block_actions interaction payload to our endpoint. We read the chosen option, the user ID, the team ID, the channel ID, and the one-time response_url for the ephemeral reply.

• Trust boundary: we bind the write to the team ID attested by Slack's verified request signature. We encode an orgId in the button value and treat it only as a cross-tenant hint, never as authority.
• We never receive: message history, channel content, or any text the user typed anywhere else. The payload carries the button they pressed and routing identifiers, nothing more.

We post the verdict and explanation back to the member's response_url as an ephemeral message. Slack shows it to the invoker only. No one else in the channel can see it, and Slack does not store it in the channel.

At the hour the workspace sets, we edit the original message to remove its answer buttons. We post no new message and add nothing to a thread, and the edit carries no number: the question and one closed line, both authored by us.

This used to be a summary thread carrying aggregate counts. It is gone. In a small channel, a count of who answered can identify them by elimination, so the channel now carries nothing derived from anybody's answers. That is a stronger promise than the k-anonymity floor it replaced.

With the im:write scope we send direct messages: the daily question in DM-delivery workspaces and apprentice companion updates. These are the only things we DM. Any member can stop all of them with /reps mute and resume with /reps unmute; muting does not affect channel posts.

When the app is uninstalled, Slack sends an app_uninstalled event. We read only the team ID from it. The event triggers deletion of that workspace's attributed Slack data.

All attributed Slack-specific data (user mappings, post history, sprint sessions, question feedback, insight delivery records, practice preferences, and in-Slack companion progress) is permanently deleted within 15 days: a 14-day retention window plus a daily deletion sweep, the same wording as the Privacy Policy. Anonymous aggregates that contain no identifiers continue under the 90-day window. See retention for the full schedule.

Subscribers to the email question of the day get one question with four answer buttons. Each button is a link carrying an opaque, HMAC-SHA256-signed token. The token references the subscription, the question, the send day, and the option index. The URL never contains a plaintext email address, user ID, or answer ID, and we trust nothing in the token until the signature verifies. Tokens expire after 14 days.

• Opening a link never records an answer by itself. The landing page renders first and records the answer only after a real interaction signal (a tap, a keypress, or the page staying visibly rendered). Link prefetchers never trigger that, and we designed the gate to filter out sandboxing gateways that execute JavaScript. Without JavaScript, an explicit confirm button submits the answer.
• Where the answer lives: a per-send row in our database, graded against the answer options pinned when the email was sent. The first answer wins; clicking again shows the recorded verdict. We delete these rows after 90 days (see retention).
• The correct answer is never in the email. We grade on the server, and only when a subscriber taps a button.

• One-click in your mail client (RFC 8058). Every email carries the List-Unsubscribe headers. When your mail client's unsubscribe button fires, the opt-out takes effect server-side immediately and permanently.
• The footer link. Clicking unsubscribe in an email footer opens a page that records the opt-out and offers a 24-hour undo. The page does the writing, not the link itself, so a scanner prefetching the footer link can never silently unsubscribe you. The undo exists only for this path; it never reverses a mail-client one-click.
• One flag stops everything. An unsubscribe suppresses all marketing streams (lifecycle emails, the newsletter, and the question of the day) at once. We keep the suppression record itself so we keep honoring the opt-out, and we remove it entirely on account deletion - the same rule the Privacy Policy states.