Privacy
Last updated August 21, 2026
Temposcope is a weekly-update tool for teams. This page says what we collect, who it goes to, how long we keep it, and what we do not do. It is written to be checked against the product rather than to sound reassuring, so where our answer is “we keep it indefinitely” or “ask us”, it says that.
Temposcope is operated by Temposcope LLC, 455 Market St Ste 1940, PMB 687788, San Francisco, California 94105-2448. Questions, requests and complaints go to privacy@temposcope.ai.
Two relationships
If your employer bought Temposcope, they decide what goes into it and how long it stays; we hold and process it on their instructions. Requests to see, correct or remove what is written about you are best made to an admin in your own workspace, who can act immediately. We will help them, and we will respond to you directly if they cannot.
If you are visiting this website and have not signed up, the only personal data involved is an email address you type into the waitlist form, described below.
What we collect
When you sign in. Temposcope has no passwords. You sign in with Google, with Microsoft, or with a one-time link sent to your email address. From Google or Microsoft we receive and store your email address, your name, an identifier for your account with that provider, and a link to your profile picture. We ask those providers for nothing else.
What your organization puts in. Weekly updates and their full edit history, comments, reactions, who has read what, actions, decisions, project plans, and the profile fields an admin or colleague fills in: job title, team, manager, start date, location, and any contact email, phone number or LinkedIn address entered on the About tab. Cover images and avatars are stored in a private file store and are never publicly addressable.
What we do not collect. We do not use analytics, advertising, tracking pixels or third-party scripts of any kind: this site loads none. We do not record your IP address or browser user agent when you sign in. Our database reserves columns for both and nothing writes to them, which we mention because it is the kind of claim worth being able to verify.
The waitlist form on this site. If you enter an email address on the marketing page, your browser sends it to a Google Form we own, which records the address and the time you submitted it. It is not stored in Temposcope. Google processes it as our provider.
Cookies
We set no advertising or third-party cookies. Every cookie Temposcope sets is one of these, and all of them are first-party.
temposcope_session
Keeps you signed in. Thirty days. Only a hash of it is stored on our side, so a copy of our database cannot be used to sign in as you.
temposcope_oauth
Holds the one-time values that make a sign-in round trip safe. Ten minutes.
temposcope_slack_install, temposcope_teams_install
The same, for connecting a Slack workspace or a Microsoft Teams tenant. Thirty minutes.
temposcope_theme
Light or dark. One year. Deliberately readable by the page so the screen does not flash white before it loads.
ts_following_only, ts_directory_view, ts_digest_projects_view
Remember how you last chose to look at a list. One year each. They hold a display choice and nothing about you.
None of these are used to profile you or to follow you to other sites, and there is nothing here for a consent banner to ask about beyond what is strictly necessary to run the product and remember your preferences.
Who else sees it
We use a small number of providers, and each one receives only what its job requires:
Hosting and database
Vercel hosts the application and Neon stores its database. Everything in the product passes through them.
Anthropic
Generates the summaries and answers described below. Receives the specific update text, names and week labels that a summary or a question needs, and nothing else. Used only when a model is configured; the product works without it.
Resend
Sends invitations, weekly reminders and digests. Receives the recipient’s email address and the contents of that message, which for a digest includes colleagues’ names and their summarized updates.
Slack
Only if an admin connects a workspace. We then send reminders and digests as direct messages, and read the workspace member list once, to match people by email address. Connecting a workspace does not let us read anybody’s messages, and by itself we never do.
Separately, each person may choose to have their own messages shown beside their weekly update, as a reminder while they write. That is granted by that person, from their own settings, and by nobody on their behalf. We then search only for messages they sent, in channels, in the week they are writing about; we drop anything from a direct message before it reaches the screen. What is found is shown to that person and to nobody else, and nothing goes into an update unless they put it there. Slack’s search permission is broader than that use, so we will say plainly that the limit is in what we ask for rather than in what the permission allows. It is revoked in one press, from the same place it was given.
Microsoft Teams
Only if an admin connects a tenant. We then send reminders and digests as chats, and read the directory to match people by email address. Microsoft only lets a bot message somebody it already has a chat with, so we also store the identifier for that chat. We never read your Teams conversations, and the permissions we ask your administrator for are read-only.
GitHub
Only if an admin installs our GitHub app, and then only for people who link their own GitHub account themselves. We read the pull requests and issues that person opened, merged, closed or reviewed in the week being written about, in the repositories your admin chose at install time, and we use them to offer draft lines that person accepts or discards by hand. We never read your code, and every permission we ask for is read-only. We store no GitHub token for you: your account is used once, to confirm which login is yours, and we keep that login and nothing else.
Jira
Only if an admin connects your Jira site, and then only for people who link their own Atlassian account themselves. We read the summary, key and status of the issues that person is assigned: the ones their board moved to Done during the week being written about, and the ones sitting in progress. We use them to offer draft lines that person accepts or discards by hand. We never read an issue’s description or its comments, we never read an issue nobody has assigned to that person, and every permission we ask for is read-only, so nothing in this product can change anything in Jira. We do store one credential for you: a refresh token, encrypted, because Atlassian will only show us your issues on your own authorization. Unlinking from Settings deletes it.
Linear
Only if an admin connects your Linear workspace, and then only for people who link their own Linear account themselves. We read the title, identifier and status of the issues that person is assigned: the ones their workspace marked completed during the week being written about, and the ones sitting in progress. We use them to offer draft lines that person accepts or discards by hand. We never read an issue’s description or its comments, and we never read an issue nobody has assigned to that person. We also read the addresses attached to those issues. Linear records what a ticket is linked to, and where that is a GitHub pull request we use it for one thing: so that somebody who has both connected is not offered the same piece of work twice, once from each. We keep only the GitHub pull request addresses and discard every other kind as soon as we have looked at it. None of them is stored, and none is sent to a model. Linear publishes one read permission and no narrower one, which is worth being exact about. The consent screen you will see says read access to your account, because that is the only read permission Linear offers: there is no issues-only version of it to ask for. What limits us is that Temposcope sends exactly one question to Linear, for the issues assigned to you, and sends no other. That is a decision in our code rather than a limit Linear places on us. Every permission we ask for is read-only, so nothing in this product can change anything in Linear. We do store one credential for you: a refresh token, encrypted, because Linear will only show us your issues on your own authorization. Unlinking from Settings deletes it.
monday.com
Only if an admin connects your monday.com account, and then only for people who link their own monday.com account themselves. We read the name and link of items that have that person in a People column, the board each is on, and the People and Status values that decide whether it counts: an item is offered once a Status column moves, during the week being written about, to a label your board marks as done. We use them to offer draft lines that person accepts or discards by hand. We never read an item’s updates or comments, which monday.com keeps behind a separate permission we do not ask for, and we never read any other column. monday.com’s narrowest read permission covers every board the person can see, which is worth being exact about. There is no version of it limited to one person’s own items. What limits us is that Temposcope asks monday.com for the column layout of that person’s most recently used boards and then for items assigned to them on those boards, and sends no other question. That is a decision in our code rather than a limit monday.com places on us. Every permission we ask for is read-only, so nothing in this product can change anything in monday.com. We do store one credential for you: a refresh token, encrypted, because monday.com will only show us your items on your own authorization. Unlinking from Settings deletes it.
Close
Only if an admin connects your Close organization, and then only for people who link their own Close account themselves. We read two things and nothing else: who you are, and the names of the deals you personally won during the week being written about. We use them to offer draft lines that person accepts or discards by hand. This is the one connector where the permission we are given is not read-only, and we would rather you heard it from us. Close publishes a single permission, which its own documentation describes as the same level of access as an API key. There is no read-only version to ask for instead. So the permission you grant would allow changing your CRM, and what prevents that is our code rather than Close’s permission: Temposcope has no way to write to Close anywhere in it, and asks Close for exactly two things. We do not read your leads, your pipeline, your notes, your calls, your emails or their contents, and we do not read anybody else’s deals. We never read a deal’s value, so no revenue figure can reach an update. Nothing is stored except one credential: a refresh token, encrypted, because Close will only answer for you on your own authorization. Unlinking from Settings deletes it, though only you can withdraw the permission itself, from inside Close.
Asana
Only if an admin connects your Asana workspace, and then only for people who link their own Asana account themselves. We read the name of the tasks assigned to that person that were marked complete during the week being written about, and we use them to offer draft lines that person accepts or discards by hand. We never read a task’s description, its comments or its attachments, we never read a task that is not assigned to that person, and we never read one that is not finished. Every permission we ask for is read-only, so nothing in this product can change anything in Asana. We do store one credential for you: a refresh token, encrypted, because Asana will only show us your tasks on your own authorization. Unlinking from Settings deletes it.
Google Drive
Only if an admin connects your organization’s Google Workspace domain, and then only for people who link their own Google account themselves. We read the names and linksof documents that person changed themselves during the week being written about, and we use them to offer draft lines that person accepts or discards by hand. We never read what is inside any document: the permission we ask Google for covers a file’s name, its link and when you last changed it, and it cannot open a file. We never read a document you did not change yourself, and every permission we ask for is read-only, so nothing in this product can change anything in Drive. We do store one credential for you: a refresh token, encrypted, because Google will only show us your files on your own authorization. Unlinking from Settings deletes it.
Outlook Calendar
Only if an admin connects your organization’s Microsoft tenant, and then only for people who link their own Microsoft account themselves. We read the titles and timesof meetings that person organised or accepted during the week being written about, and we use them to offer draft lines that person accepts or discards by hand. We never read what is inside a meeting: the permission we ask Microsoft for covers a meeting’s subject, when it ran and who was on it, and it cannot return a body, an agenda or an attachment. We never read a meeting you declined, never answered, or marked private or out of office, and we never read one that has not happened yet. Attendee names are never put into your update. Every permission we ask for is read-only, so nothing in this product can change anything in your calendar. We do store one credential for you: a refresh token, encrypted, because Microsoft will only show us your calendar on your own authorization. Unlinking from Settings deletes it.
Google Calendar
Only if an admin connects your organization’s Google Workspace domain, and then only for people who link their own Google account themselves. We read the titles and times of meetings that person organised or accepted during the week being written about, and we use them to offer draft lines that person accepts or discards by hand. We never read a meeting you declined, marked as a maybe, never answered, or marked private, confidential, free or out of office, and we never read one that has not happened yet. Attendee names and addresses are never put into your update and are never requested. We do not read a meeting’s description, and it is worth being exact about why that is a promise rather than a guarantee. Google publishes no calendar permission that withholds the description, so unlike Outlook Calendar we cannot point at the grant and say the text is out of reach. What we do instead is ask Google for a named list of fields, and the description is not on it, so it never reaches us. That is a decision in our code rather than a limit Google places on us. Every permission we ask for is read-only, so nothing in this product can change anything in your calendar. We do store one credential for you: a refresh token, encrypted, because Google will only show us your calendar on your own authorization. Unlinking from Settings deletes it.
Outlook Mail
Only if an admin connects your organization’s Microsoft tenant, and then only for people who link their own Microsoft account themselves. We read the Sent Items folderof that person, for the week being written about, and only the first part of each message rather than its full body. We use it to offer whole sentences they wrote, word for word, as draft lines they accept or discard by hand. The permission is wider than that. Microsoft has no permission covering a single mail folder, so the one we ask for covers the whole mailbox, received mail included. We read only the sent folder, that restriction is in our code rather than in the permission, and we would rather tell you so than let you discover it. We never read your inbox, we never read attachments, and every permission we ask for is read-only, so nothing in this product can send, move or delete anything. Nothing from a message is stored: the panel is built fresh each time and thrown away, and the only text kept is a line that person chose to add to their own update. Greetings, sign-offs and anything quoted from a reply are left out, so a colleague’s words are never offered as somebody else’s. Recipient names are never put into an update. We do store one credential for you: a refresh token, encrypted, because Microsoft will only show us your mail on your own authorization. Unlinking from Settings deletes it.
Temposcope MCP
This is the one that sends data out rather than in. Every other connector on this list reads something so you can write your update. This one lets a tool you choose, such as an AI assistant, read the updates you have already written. Nothing is connected until an admin turns it on for your organization, and then only for people who connect a client themselves and approve it on a screen naming exactly what it may read. A connected client sees what you see and nothing more. It reads through the same permission checks your own screens use, so a private team you are not on stays private and an update nobody has shared stays a draft. It can never write: there is no tool for creating or changing an update, an action, a decision or a plan, and none for commenting, sharing or sending. That limit is in the code rather than in a setting. Where the data goes after that is between you and the tool you connected, and we cannot see or control it. We store no credential belonging to any outside company, because there is none: what we keep is an access token for that client, hashed, which you can revoke from Settings at any time. It stops working the moment your seat is closed, your organization is closed, or an admin switches the connector off.
Google, Microsoft
Verify who you are when you sign in with them. Google also receives waitlist submissions from this site.
How AI is used
Temposcope summarizes weekly updates and answers questions about them. Two rules are enforced in the code rather than by policy. First, what is sent is retrieved for the question (the rows that match, read as you, after the same permission checks the screen applies), never your organization’s whole history. A private team you cannot see contributes nothing to an answer you receive, and a check refuses the request outright if a row from another customer ever reached it.
Second, nothing written by a model is stored as a record. Actions, decisions and plans are created by people. The model summarizes and answers; it does not file commitments on anyone’s behalf, because an invented commitment is worse than a missing one.
What our AI provider may retain, and whether your content may be used to improve their models, is governed by our agreement with them rather than by this product. Under Anthropic’s commercial terms they are prohibited from training models on the content we send, and they delete it within thirty days. We have not negotiated a shorter retention period, so thirty days is the honest figure rather than none.
How long we keep it
The honest answer is: as long as your organization has an account, and deliberately so. The product exists to make a company able to read its own past, so an update written two years ago is meant to still be there.
When someone leaves, their access ends immediately and their profile is archived, but what they wrote stays: their updates, the decisions they recorded, and the comments others replied to. Removing them would tear holes in colleagues’ history. When a customer closes their account we archive the workspace rather than deleting it, so that it can be restored and so that nothing is lost by accident.
That means we do not automatically erase anything, and you should not read a promise of erasure into this page. If you need data actually removed, write to privacy@temposcope.ai and we will tell you what we can do, what we cannot, and how long it will take.
How it is protected
Every customer’s data is separated in the database itself rather than by application code being careful: a query that does not name a workspace returns nothing at all, and the application connects with an account that cannot bypass that rule. Sign-in tokens are stored only as hashes. A connected Slack workspace’s credentials are encrypted before they are written down; a connected Microsoft Teams tenant has no stored credential at all, because Microsoft issues one for each request instead. There are no passwords to steal, and uploaded images are private and served only after the same permission check as the page they appear on.
Temposcope staff can be granted access to a customer’s workspace to help with support. It is granted one workspace at a time, both granting and giving it up are recorded, and the admin screen inside that workspace says plainly whether we currently have access.
Your rights
If you live in California, you have the right to know what personal information we hold about you and where it came from, to have it corrected, to have it deleted, and to be treated no differently for asking. Write to privacy@temposcope.ai and we will respond within forty-five days, or tell you within that time if we need longer.
We do not sell your personal information, and we do not share it for advertising. We never have. There is no advertising technology in this product, no analytics, and no third-party scripts on this site, so there is nothing to opt out of, but if you would like that confirmed in writing, ask and we will confirm it.
If you think we got something wrong you can complain to the California Privacy Protection Agency or the California Attorney General. We would rather you wrote to us first, and we will not treat you worse for doing either.
We are not yet set up for people outside the United States, so this section speaks to California law. If you are elsewhere and want to exercise a right you have at home, write to us anyway: we will not refuse a request because of where it came from.
If your workspace belongs to an employer, the fastest route for most requests is an admin there, who can change or remove what is written about you without waiting for us.
Changes
If we change what we collect or who we share it with, we will update this page and change the date at the top. Material changes will be told to workspace admins directly rather than left here to be discovered.