Your spreadsheet data stays in your sheet unless you send it.

The short version

Your spreadsheet data stays in your sheet unless you send it. All computation (statistics, machine learning, simulations, optimizers, matching, forecasting) runs inside Google's Apps Script environment and your browser. The add-on never transmits your cell values, formulas or sheet names unless you tick the assistant box, and sends a label only as a name in Ask’s AI fallback with AI on; beyond that there is one exception, and you have to press a button to reach it: a Pro user exporting a simulation of more than 250,000 trials, which is larger than a browser tab can build, is offered a run on our server, and that request carries the model. What it does send is set out in full below: anonymous feature-usage events, which carry no spreadsheet data and no account identifier; if you buy a license, the license checks that go with activating and renewing your key; and, only if you hold a Pro license and ask for a written reading of a result, the shape of that result (ratios, correlations and cell references, no values), which you can inspect before and after it is sent and which your administrator can switch off entirely. Separately, if you choose to sign in on the website, we keep that sortia.io account’s email address and Google account id, and nothing else from Google; the web app runs models in your browser, and keeps a plan only if you press Commit as the plan.

What the add-on can access

The add-on requests two narrow permissions:

Google attaches two more to every Workspace Marketplace install, your primary Google account email address and your basic profile information, so the consent screen and the listing's Permissions tab show four rather than two. Sortia does not use either of them. Its own code asks Google who you are and gets nothing back, which is why activating an organization key has to ask the holder to type an address at the covered domain instead of reading one.

What that list allows is one thing; what it cannot allow is the more useful half, and it is arithmetic on the manifest rather than a promise. What an add-on can see works through it, along with the one thing a short permission list still cannot tell you.

What we collect

Almost nothing, and never your data. Specifically:

• Your spreadsheet data stays in your sheet unless you send it. No cell values, ranges, formulas, sheet names or file information are read by us or sent anywhere in the course of using Sortia (apart from what a rare error message can carry into our own error logs, set out under Data processing details), and no labels either, except that with AI on, a message Ask’s rules don’t understand goes with the names of the model’s estimates (which are your labels), as Ask’s AI fallback sets out. The other exception is the assistant box, only after you tick it, as The assistant box sets out. The one thing derived from a result that can leave, for a Pro user who asks for it, is the shape of that result, listed field by field in the section on written readings below. There is exactly one way to send more than that, it is a button rather than something that happens to you, and it is the large simulation export described below: on Pro, on a run of more than 250,000 trials, the model itself goes to our server to be run there because a browser tab cannot build a file that size.
• Anonymous feature-usage events. The add-on sends a short event to our server at these moments: when the sidebar opens (boot and session), the first time it ever opens for you (first_open), when a tool panel opens (view), when a run finishes and writes a result, or fails, or a panel fails to load or has to be reset after an error (run, mounterr), when a run fails, and when the sidebar recovers from an unexpected error, a second event naming the kind of failure with one word from our own fixed list (bridge_stale, sheets_timeout, formula, rolled_back, partial, too_big, refused, auth_refused, stale_sheet, no_access, service, script, admin_blocked, sheet_missing, quota or unknown), never the error message itself (err; the few cleaned-up words that can go to our own error logs for a failure Sortia cannot name are set out under Data processing details). When that word is refused it means the run was stopped by one of Sortia's own guards because the request could not be carried out as asked, and the sidebar showed you a sentence saying how to fix it; with that word the event may carry one more word from a second fixed list saying what kind of problem the guard found (range_empty, range_small, non_numeric, header, too_many, output_big, stale_window, param, plan, degenerate, range_missing or other), for example that the selected range was empty, that Google Sheets could not find the cell or tab it names or that a header row was selected as data; it records the kind of problem and the tool, never the range you selected, never what you entered and never the sentence you were shown. auth_refused means Google refused a request from a sidebar that was already open, which can happen when several Google accounts are signed in to one browser, and stale_sheet means the sidebar was still open after its spreadsheet was closed or replaced. no_access means Google reported that you can open the spreadsheet but not change it, or that Sortia was installed without permission to read spreadsheets; it records that word only, never which spreadsheet or who shared it. service means Google's own Sheets or Apps Script service reported a failure, and script means Sortia's own code threw an error; both are chosen by matching the failure's wording against a fixed list of Google's own phrasings and JavaScript error names. The full wording is never sent. For these two words and unknown, the first few words of it go with the count, cleaned of every number, quoted text and cell address, and are kept only in our own error logs, as set out under Data processing details. When a panel fails to load, the event may also name which step failed with one word (render, restore, chart, wire or other). The add-on also sends, after a successful run, which of five coarse duration ranges it fell into, such as under four seconds, never a precise time (perf), and, for a Data Analysis run, the same coarse range for each part of the run, named by one word from a fixed list (bridge, the time spent passing the request between the sidebar and Google, read, compute and write), never a precise time, the first time a run ever finishes for you (first_run), and when you reach one of the five Pro engines without a license or click an upgrade button (gate), and when a reading of a result or a tool suggestion is shown (assist, carrying only which of the three surfaces it was and whether the built-in text or a written reading was used), and when you load one of our example templates, from the template library, from a search or an Ask reply, or from a tool’s example button (template, carrying only the short name we gave that example, such as loanpayoff, so we can tell which examples people actually start from), and a small set of outcome signals (ux), each one word from a fixed list: the first-result card's button was pressed or the card was closed (reveal_cta, reveal_dismiss), a result stayed on screen for three seconds (result_seen), you pressed thumbs up or thumbs down under "Was this useful?" (react_up, react_down), a result was exported, copied or written to the sheet (result_export), you pressed the button to try a tool on our sample data or to load an example (sample_run, example_load), the same kind of refusal happened twice in a row (refuse_repeat), the very same refusal happened twice in a row, counted from a hash kept in your browser and never from the message or the cell it names (refuse_same), a run was stopped before it started because a required input was missing (preflight_block), a Risk run was started with a goal on an output, counted once and never with the goal itself (goal_set), and the help card for a Google authorization refusal was shown or its Retry button was pressed (auth_card, auth_retry), that the help card was shown after a request had already succeeded in the same sidebar session, or that a request succeeded again after the help card was shown (auth_card_late, auth_recovered), counts only, that a button in the panel whose request was refused waited and retried on its own, and that the wait cleared without another press (first_run_wait, first_run_self_cleared), counts only, that your browser blocked the new tab when you pressed an upgrade button, so the panel offered you a link instead (upgrade_blocked), a count only and never which button, that the sidebar sent more events in ten seconds than it ever should and stopped sending for the rest of that window (rl_drop), which says that the page got stuck in a loop and nothing about you or your file, that your browser reported an error it would not describe to us, giving only the words “Script error.” with no detail of any kind (script_opaque), a count only, that the offer to try the new Sortia was shown in Settings, that you switched to it, or that you switched back to the classic view (next_offer_seen, next_switch, next_back), counts only, that a plan was committed to your sheet (commit), that a check of a committed plan ran with at least one actual filled in (actuals_in), never how many, which cells or what they hold, that a new schedule baseline was saved (rebaseline), that the panel showed the card that waits for Google to register Sortia's permission to read spreadsheets (first_run_door), that a question to Ask matched nothing and the reply offered its other doors, and that a run started after you pressed one of them (nomatch_shown, nomatch_running), never the question, and that a Data Analysis result was handed to Risk Analysis (data_to_risk), counts only, that the private-window step on the help card for a Google authorization refusal was pressed (auth_how), and that after a Data Analysis refusal over text in a few rows you pressed the button to run on the numeric rows only (numeric_rows), a press only and never which rows, how many or what they held, and, in the new Sortia, which of the four reasons you picked after a thumbs down when it asks “What was off?” (react_why_model for Wrong model, react_why_numbers for Wrong numbers, react_why_follow for Hard to follow, react_why_asked for Not what I asked), one count per reason, that a question was sent in Ask (ask_sent), that its reply named a tool or a ready-made model (ask_match), that its reply said the question is outside what Sortia does (ask_offtopic), that a match was opened (ask_open), that Tools was opened from Ask’s box (ask_tools), that Use selection was pressed in Ask’s box (ask_sel), never the question, the cells or what they hold, that a tool screen was switched between Steps and Conversation (talk_switch), that the banner offering to reconnect Sortia was shown and whether a press on it ended connected again or not (reconnect_shown, reconnect_ok, reconnect_fail), that the banner saying Sortia was updated was shown (stale_banner), that opening a saved answer failed (card_open_fail), and that a busy button stopped waiting and told you so (busy_timeout), counts only, and, for Ask’s conversation about an open model (added October 7, 2026), that an edit to the model was understood, applied, matched nothing in the model or failed (edit_asked, edit_applied, edit_nomatch, edit_failed), that a number was kept from becoming the goal (goal_guard), that a what-if run started, finished or failed (wi_run, wi_landed, wi_failed), that a model was run again or re-run with the same seed to check it (rerun_run, verify_run), that Ask asked you a question with choices and one was picked (clarify_shown, clarify_picked), that it asked whether to start a new thread (newtopic_confirm), that it said in one line what it cannot do here (honest_shown), and, only if AI is on, that a message Ask’s rules did not understand was read by AI and how that ended (ai_parse_used, ai_parse_auto, ai_parse_confirmed, ai_parse_rejected, ai_parse_failed, ai_parse_capped) with one word for the kind of change it read (ai_kind_edit, ai_kind_fixed, ai_kind_shape, ai_kind_add, ai_kind_remove, ai_kind_pin, ai_kind_whatif, ai_kind_goal, ai_kind_newthread, ai_kind_answer, ai_kind_unknown), never the message, which kind of reply you rated (rate_match_up, rate_match_down, rate_follow_up, rate_follow_down, rate_edit_up, rate_edit_down, rate_whatif_up, rate_whatif_down, rate_setup_up, rate_setup_down, rate_answer_up, rate_answer_down, rate_help_up, rate_help_down, rate_nomatch_up, rate_nomatch_down, rate_meta_up, rate_meta_down), that thumbs down was pressed (react_down_open), that the offer of the new Sortia was opened (next_offer_open), that Ask was turned off or on (ask_off, ask_on), and, on the web, that a run failed, the browser engine timed out or Verify did not reproduce (run_failed, engine_timeout, verify_failed), counts only, and, on an account's third separate day of use, one question about what you use Sortia for, whose answer is one of four words we chose (use_reason_class, use_reason_work, use_reason_personal, use_reason_trying) or the dismiss (use_ask_dismiss), never the sentence (in a version we are testing, that one question is instead asked once, on the open after your first finished result, and the answer is followed by a line with a link to write to us), and the one Marketplace line after a result, where a press on the listing link counts (rating_click), and the support line shown only after the class answer, where a press counts (teacher_contact_click), and a link to write to us that a future version may show after an answer, where a press counts (use_talk_click), and when an Optimization answer takes 15 seconds or more to write to your sheet (opt_write_slow) or does not get written (opt_write_failed); the question, its answers and the account are never sent together. One more kind of event (turn) closes each conversation turn with two words from fixed lists: how Ask read the message (new, follow, rematch, edit, whatif, rerun, meta, diff, goal, undo, clarify, help, offtopic, nomatch) and how the turn ended (acted, idle, failed, up, down, superseded), never the message, counts only, and, for the experimental live estimate cells feature that is off unless you turn it on in Settings, that Settings was opened (exp_settings_viewed), that the feature was turned on or off (exp_livecells_enabled, exp_livecells_disabled), that the template workbook link was pressed (exp_template_copied), how you answered the one-tap poll about whether the odds moved (exp_poll_yes, exp_poll_no), and that the Diagnose check found an odds formula showing a number (exp_odds_recomputed); the check reads the formulas on the active sheet to find EST and ODDS cells and whether each shows a number or an error; only counts and yes/no answers come back to the sidebar, and none of the formulas, cells or values leave your sheet. For the experimental guided builder, also off unless you turn it on in Settings: that the flow was opened (exp_builder_opened), that it reached a working model (exp_builder_completed), whether it matched one of our templates or drafted a model from your answers (exp_builder_matched_template, exp_builder_drafted_spec), and that a draft was rejected by our checker once (exp_validator_rejection), a count only; your answers and the draft never leave your browser except into your own sheet. For published result links: that the preview was opened, that a link was published, and that a link was revoked (share_preview, share_publish, share_revoke); what a link contains is described under published result links below, and none of it travels on this counting wire. Four more moments, each a count of a press or of something appearing on screen: Verify pressed on a result's receipt (receipt_verify), the receipt copied as JSON (receipt_copy), an estimate edited after a "What matters most" line was shown, counted once and never with the value (driver_edit), the guided builder's plan box appearing with a plan in it (exp_builder_plan_seen), and the hub search answering a question about the product itself, counted once and never with the question (hub_orient). For the experimental Guide, off unless you turn it on in Settings: that a message was sent, that a suggested model was opened, and that a drafted shape was handed to the guided builder (guide_turn, guide_suggest_open, guide_draft_open), counts only; the words never travel with them. A reaction is a count of up or down per tool and never text: in the classic view the "Tell us what went wrong" link that follows a thumbs down opens a draft in your own mail program, which you can send or discard, and in the new Sortia the reasons you pick are counted as described above, while the optional “Tell us more” box beside them stays in the sidebar and is never sent. So that the question is not asked more than once a week per tool, your browser keeps the date it was last shown, and a new account that has seen the first example screen keeps a note of which example that was. Both stay in your browser and are never sent. Each event contains only the kind, the tool or engine name from a short fixed list published in our repository (docs/ANALYTICS.md), the action where relevant, the name of the example template when you loaded one, the failure word, the kind-of-problem word, the step word, the outcome word or the duration range where the event is one of those just described, a plain date label, one rotating counting token, described in the next bullet, and a random identifier for the message itself, made up fresh for each message and unrelated to you, your account or your file, which exists only so that a message the sidebar had to send again after a network failure can be told apart from a new one and counted once. The event sent when the sidebar opens also carries the short build identifier of the add-on version that is running, a stamp our own build tools wrote into the code, so we can tell whether an update has actually reached people; it says which version of our code you have and nothing about you or your file. One account we run ourselves, for automated testing, adds one more field to its own events: the single character 1 under the name agent, which marks the event as ours so we can leave our own testing out of our counts. It is a setting on that one account, switched on by hand in the script editor; there is no button, menu or Setting anywhere in the add-on that can turn it on, so it can never appear on an event from your account. It says that a setting is on, and nothing about any person. Nothing else is attached: no spreadsheet data, no cell values, ranges or sheet names, nothing you typed, no email or account identifier, and no license key. Every one of those names, the template names, failure words, kind-of-problem words and outcome words included, is a word we chose and published; the build stamp identifies our code and nothing about you; none of them is anything you wrote, and none of them describes your file. As with any web request it arrives with an IP address attached; our code neither reads nor records it, though Google Cloud's own request logs hold it under Google's retention. When a message does not match the fixed vocabulary on this page, our server refuses to store it and keeps only a daily count of how many messages it refused, split by which of our own fixed reasons applied, for example that the tool name was one this server does not recognize, or that the duration range was. Those reasons are words our code chose about its own decision; nothing from a refused message is kept.
• Which step, which build, and an error code you can quote. From October 18, 2026 the event that names a failure may also carry three more things, none of them typed by you: one word from a fixed list saying where in the work it failed (read_selection, validate, run, write_output, chart, export, mount or other), the build number of the add-on that was running, and a short random error code of four characters (for example A7K2) that is drawn fresh for each failure and is not derived from you, your account or your sheet. The card that shows you a failure shows you the same code, so that if you write to us we can find that one failure. Where the failure happened inside Google's own service, the server records the same code in its error log beside the failure. Two newly named failure kinds are admin_blocked (an administrator's policy stopped the call), sheet_missing (the tab the panel was holding no longer exists) and quota (a daily Google limit was used up); each is a word, never the sentence Google showed you. Every error card has a button, "This didn't work", that sends one count (report_error) with that word, step and code and no text. Four more counts say a result may have been wrong: reconnect_press and reconnect_ok_remint (whether pressing Reconnect Sortia worked), rerun_changed (you ran the same tool again within two minutes with different inputs) and output_undone (you undid what a run wrote). One more, class_fallback, counts how often the add-on had to recognise a Google error by its English wording. Each is a count with a tool word and nothing else.
• The counting token, and exactly what it can and cannot tell us. So that we can tell one busy user from ten quiet ones, the add-on stores one random number in your account's add-on storage. It is generated on your device, it is not your email, your account id, or anything derived from you or your files, and it never appears on a sheet you can see. Beside it, in the same account storage and never transmitted, the add-on keeps the date it last opened and how many separate days it has been opened, and two one-line notes saying whether the third-day question and the Marketplace line have been shown; those exist only so each is asked once and are not part of any event. We never receive that number. What we receive is a one-way token derived from it that changes every day. So two events you send on the same day can be recognized as coming from one person, which is how we tell reach from repetition, and your three spreadsheets count as one user rather than three. Two events sent on different days cannot be connected to each other at all, by us or by anyone reading our data. No request ever carries more than that single day token. So that we can also count weekly and monthly activity without ever putting two different tokens in one message, the add-on additionally sends a separate one-field message, at most once a week and once a month, containing only a weekly or monthly token and nothing else, at a randomly chosen moment. Before August 28, 2026 the number was stored per spreadsheet and the counts meant files rather than people; our own dashboards label the change. One honest residual: your messages reach us from your IP address, and Google Cloud's request logs hold caller IPs under Google's retention; the random timing and once-per-period sending make that a weak correlation, not a join we or anyone could perform from our data. One exception, added 2026-09-26: the published-links feature sends a separate, non-rotating hash of the same stored number, so that a link you publish one day can be listed and revoked the next. It is sent only on publish, on revoke and when you ask Settings to show your links; it is never sent with a usage event, and our server cannot turn it back into the daily token or vice versa.
• Clicking an upgrade button opens our pricing page in a new tab, with the name of the limit you met and, if you had loaded one of the example templates, the name of that template in the address bar, so the page can show you the right plan. The address also carries a fresh random id minted for that click, which lets us count how many checkouts start and how many finish. That id is random: it is not the counting token, is not derived from it or from anything about you or your file, and cannot be connected to the anonymous usage counts above. You can see the whole address in your browser, and it carries nothing else.
• License checks. Your license key is verified inside the add-on, by checking its signature locally, so day-to-day use of a key involves no network call. Three things do reach our server, and each of the three carries the key. One. When your key is inside the last two weeks before it expires, or has already expired, the add-on sends the key to us to collect its replacement, so a renewal does not interrupt you. That one happens on a personal key as much as on any other. Two. If your key is an organization-wide site or school license, activating it sends the key and the work email address you type on the activation screen, so we can check the address belongs to the organization that bought the license and count how many people are using one key. Our server turns that address into a keyed hash and keeps only the hash and a running count on the purchase record; the address itself is not stored. Three. On an organization-wide site or school license, and only there, the add-on sends the key on its own to ask whether the administrator has turned the AI reading on. It is sent once per sidebar session, at the first moment a reading would be requested. Because that request is how the answer is found, it goes out before the answer is known, so it is sent on a seat where the feature turns out to be off just as it is on a seat where it is on. It carries the key and nothing else, and our server stores nothing from it. None of the three carries any spreadsheet data. The second and third are not sent for a personal key.
• No Google account information is read or stored by us through the add-on. The add-on asks for no email or profile permission, so it cannot read the address of the Google account it is running under, and it never asks our server who you are, except that once you connect it to a sortia.io account yourself, it can ask whether it is connected and is shown that account’s address with most of it hidden (an address that came from your own sign-in on the website, never from the add-on). On a personal paid plan the license key you paste does carry the email address you bought it with, which is how a plan is confirmed without an account system; that address came from you at checkout, never from your Google account or your file. On a site or school license the key carries the organization’s domain instead of any one person’s address, which the written-readings section below sets out. The one place we keep a Google account’s email address is a sortia.io account, which exists only if you sign in on the website yourself; Your sortia.io account sets out exactly what that keeps.
• Saved settings (risk-input distributions, scenarios) are stored inside your own spreadsheet on hidden sheets; they travel with the file and stay under your control.
• A committed plan, only when you press Commit. In the new Sortia, committing a Risk result as the plan writes three things into the model’s own tab: the plan figure, with its label and the run’s receipt under it; an Actual column beside your estimates, left empty for you to type what really happens; and a hidden plan record in the tab’s own metadata, which is not visible in the grid. The record holds the output cell, the goal’s direction (at least or at most), the 80 in 100 level, the plan figure, the cells Commit wrote with the formatting it gave them and the formatting they had before, each estimate’s cell and distribution, the trial count, the seed, the receipt’s hashes and the date. Nothing is written until you press Commit, none of it is sent to us, and Undo takes it back out: it clears what Commit wrote where it is still there, leaves the receipt and Actual cells you have typed in since exactly as they are, keeps any formatting you have changed, and removes the hidden record. If the plan’s cells have moved, or its label, figure or Actual header have been typed over, Undo changes nothing and names the cells it expected; if you have already cleared the plan yourself, it removes only the hidden record and changes no cell.
• Model files, only when you download one. Model files you download hold the model’s names, estimates and formulas, and stay wherever you save them. A model file (a .sortia file) is saved by your browser straight to your computer; nothing is published and nothing is sent to us. Its names come from your labels, so a label is in the file, and its title is the name of the tab the model is on; it also holds the question and goal shown in the new Sortia, and, when you leave them switched on, the run’s receipt (trial count, sampler, seed, two hashes, the cells the receipt was computed over, and the version) and every run of each result. It never holds other cells, the spreadsheet’s name, or anything about your Google account. Opening a model file reads it in the sidebar; the model goes only to the add-on’s own script in your Google account, to lay out the new tab, never to us.
• Model files you open on sortia.io/open or check on sortia.io/proof stay in your browser. Those two pages read a .sortia file you choose inside the browser tab, run its model there, and send nothing about it anywhere: the file is never uploaded and no part of it reaches us. The only thing either page fetches is our own sample model file, when you ask for it. Neither page loads Google Analytics or any other script that is not ours. “Download my version” on /open saves a new file straight to your computer.
• Purchases happen on our website via Stripe, not inside the add-on; Stripe's own privacy policy governs payment details. We receive your email and expiry to mint your license key.
• Published result links, only when you press Publish. The add-on, and the web app's answer card, can publish one result as a read-only page at sortia.io/r/. Nothing is published until you have seen a preview listing exactly what the page will contain and pressed Publish. A published page holds the verdict sentence, the odds, the "what matters most" line, the run receipt (trial count, sampler, seed, two hashes, version numbers and the run time), an optional title you type, and, only if you leave them switched on, your inputs as low-to-high ranges. It never holds cell values, formulas, other tabs, the file name, or anything about your Google account. Our server stores that page and a record of it under a hashed copy of the add-on's random owner id (or, for a link published from the web app, of the random id that browser keeps), never an email; it counts how many links you publish per day and per month, and it records nothing when someone reads the page. So that publishing cannot be used to spam, each publish can also be counted against the network address it came from (for an IPv6 address, the network part of it): our server keeps a keyed hash of that address and the day, never the address itself, with a count of that day's publishes, can refuse more than a fixed number a day from one address, and deletes the count automatically within three days: it expires an hour after that day ends (UTC), and our database removes expired counts, usually within a day. A page that would carry a web address, an email address or a phone number is refused before anything is stored. Links expire after one year and you can remove one sooner from the add-on. On an organization key the add-on also asks our server once per session whether your organization allows publishing, sending the organization's domain from the key and nothing else. If you connect the add-on to a sortia.io account, the hashed id your links are filed under is linked to that account so they list there; Your sortia.io account says what that keeps.
• Large simulation exports, on Pro only, and only when you press the button. This is the one request that carries anything out of the cells of your own model, so it is written out here in full. A simulation of more than 250,000 trials is larger than a browser tab can pair into an export file. When a Pro user asks to export a run that size, Sortia offers to run it on our server rather than refusing, and only then does anything leave: your model is translated into a portable specification, in which every cell the model uses becomes a named entry holding either its formula rewritten in those names or, where the cell holds a value rather than a formula, that value. That specification is sent with your license key and with the column labels from your own model, so the file that comes back carries names you recognize rather than machine-made ones. Our server runs the trials, writes the file, and hands your browser a one-time download link that stops working after one hour; the file itself is deleted by a sweep that runs every hour, so it can outlive its link by at most an hour more. We keep no other copy of the specification or the file beyond Google Cloud's request logs under Google's retention. There is no path to this on a free plan, nothing reaches it from any other engine, and no run below that trial count goes anywhere near it. This is the single exception to the sentence at the top of this page, and it is a button you press knowingly on a run you built.

The usage events, the three license-check requests above, the written-readings payload in the next section, the four published-link requests (publish, revoke, the list you ask for in Settings, and one organization check), the three connect requests (a code when you press Connect, the connection’s status when you press Check connection, and Disconnect) the large-simulation export just described and, with AI on, Ask’s AI fallback are everything the add-on sends. If we add anything to that list, this page is updated in the same release that adds it, and the date at the top moves.

Data processing details

• Tool inputs (the cell ranges you select) are processed in-memory during a run and written back as output sheets in the same spreadsheet.
• Saved risk inputs and scenarios are written to a hidden sheet inside your own file. Nothing on that sheet leaves your spreadsheet.
• A plan you commit is written to the model’s own tab: the plan figure, the Actual column and a hidden plan record, only when you press Commit. None of it leaves your spreadsheet.
• Templates you load are written to clearly named sheets (Template …) in your spreadsheet and are yours to delete.
• Error logs, if any, go to Google's own Apps Script logging (Stackdriver). You can see them for your account, and failures in the add-on's code are also logged to Sortia's own Google Cloud project, where the developer can see the error text. Our error messages are written in our own words and may name a cell reference or a count. The messages we send back to you never contain cell values, labels, formulas or text typed into your sheet. Two narrower things can reach the developer-only logs: when a write fails, the message may name the output tab it was writing, and when Google's own error quotes something back at us, that quotation travels with it, which has included a tab name, a sheet number, a spreadsheet's file id (in rare error messages) and, in one case, a value typed into a cell. We are removing those as we find them; this sentence will narrow again when we have. When a run fails for a reason Sortia cannot name (the failure words unknown, service and script), the first few words of the error sentence travel with the count, with every number, quoted text and cell address removed first, and are kept only in Sortia's own Google Cloud logs, never in the daily counts.

Your sortia.io account

The web app at www.sortia.io/app has its own sign-in, with Google only. It is separate from the add-on: the add-on asks for no new permission because of it, nothing you do in Google Sheets is sent to it, and you never need an account to use Sortia in Google Sheets.

• What we keep. When you press Continue with Google, Google sends our server a signed statement of who you are. Sortia asks Google only for your email address, but Google’s statement always carries your name, your profile photo and your language setting as well; our server reads past them and never keeps them. We check the statement and keep two things from it: your email address, in lowercase, and your Google account id (the number Google uses for your account, so the same Google account always reaches the same Sortia account). We also keep the date the account was made, and a random share id made once for the account (it is not worked out from your Google id or your address), which the links you publish from the web app are filed under so they list and revoke from any browser you sign in on. We do not keep your name, your photo, or the statement itself.
• Sign-in sessions. Signing in sets one cookie in your browser, holding a random number. We store only a fingerprint of that number (a SHA-256 hash), the account it belongs to, a second random value that stops other websites from pressing your account’s buttons, when the session started and when it was last used. Sign-in sessions are kept for 30 days after you last use them and are then deleted automatically, and none lasts more than 90 days from when it started, however often you use it. Sign out ends yours at once, and Sign out everywhere ends them all. Before you sign in, the same cookie holds a different random number for at most ten minutes, so that the statement Google sends can be used only by the browser that asked for it; we store nothing for it.
• Two lookups. One from a fingerprint (a SHA-256 hash) of your email address and one from your Google account id, so a sign-in finds your account. Each holds only the account’s random id.
• The tester list. A few people we invite to try Pro before it is sold on the web are on a short list of email addresses, kept by hand by the operator (Ben Malott) in our Google Cloud database. It is read when you sign in, to show Pro on your account, and holds nothing but the addresses. If you are on it and delete your account, your address is taken off it at the same time.
• Connecting the add-on. In the new Sortia, Settings, sortia.io account, Connect makes a short code for your install and opens a page here that asks before anything joins. Only when you press Connect there does the account list your shared links. What the add-on sends is the hashed id your links are filed under (never the add-on’s random number itself) and, if you tick Include my license (it starts unticked), your license key, once. We check the key and keep from it only the email address or organization domain the license was bought under and its expiry date; we never keep the key itself. For each code we keep a fingerprint (a SHA-256 hash) of the code, the hashed id of the install that asked, the license’s address or domain and expiry if a key came with it, whether the code has been used, and when it expires: a code works once and for ten minutes, and is then deleted automatically. When an install is disconnected, we also keep when that happened, filed under a fingerprint of the install’s hashed id, so no code made before it can reconnect that install; it too is deleted automatically after ten minutes. Once you connect, we keep the connection: the hashed id your links are filed under, the account it belongs to, and when you connected, with the license’s address or domain and its expiry date if that install brought one, so that disconnecting another install can bring it back; and, if the key came with it, the license link: the license’s address or domain, its expiry date, which connected install brought it, and when it was linked. A site or school license joins only an account whose address is at that domain. An account has one license link at a time: if connecting would replace a license already on the account, the page says so before you press Connect. Nothing goes from the account to the add-on: the add-on learns only that it is connected and the account’s address with most of it hidden, never a plan or a license. Your shared links show on the account as they show in the add-on, with no count of who opened them, because nothing is recorded when someone reads a page. Disconnect, in the add-on or under Account and license, removes the connection and the license link it brought (another connected install’s license, if there is one, comes back), and voids any code that install still has outstanding; your links stay live.
• Your plan on the web. To show Pro, the account looks, in order, at the tester list, at a license linked through Connect, and at Stripe: whether a paid Sortia plan is on record at Stripe for your email address, and until when. Stripe is asked at most once an hour; we keep that date and when we last asked, and nothing else from Stripe. If you turn Ask’s AI off (or back on) under Account and license, we keep that one choice, on or off, with the account; until you change it, nothing is kept and AI is on. Where the first-contact reader is offered to a free account, we also keep a count, from 0 to 10, of how many first-contact readings a free account has used, so the ten it has are counted for good; it holds no part of any message. Stripe does not check the email address a buyer types at checkout, so this match trusts it: we count only a purchase our own records at Stripe say was issued to exactly your signed-in address. Manage billing opens Stripe for that address only, never for a license linked through Connect, and a site or school license is billed to whoever bought it for your organization, so for it the account shows Manage billing only if you also have a purchase of your own at that address, and then it opens yours. Your license key is never shown on the web: it is in the add-on and on the activate page.
• The web app. Computation runs in your browser. Model files you open are read there and never uploaded, unless you press Commit as the plan. Threads stay in your browser (its own storage for www.sortia.io), and Clear threads in this browser, under Account and license, removes them. A question you ask in the web app is matched to a model in your browser. With AI on, a message Ask’s rules don’t understand is sent, with the names of the model’s estimates but no values, to Google to be interpreted (see Ask’s AI fallback); AI is on for a signed-in account unless you turn it off under Account and license, and with it off nothing you type leaves your browser. Signed out, see Questions asked without signing in. Signed in with AI on, a question you type that holds figures (“price is $52, cost is $34”) is sent as you typed it, figures included, through our server to Google’s AI model, which reads which figure is which; every figure in the answer is then worked out by Sortia’s engine. Figures in a model file or a template you open stay in your browser. Share on an answer publishes that result as a read-only page at sortia.io/r/ only when you press Publish after a preview of exactly what the page will hold (the verdict, the figures, the estimates as low-to-high ranges if you leave them on, and the run receipt; never the model file or the formulas), under a random id that belongs to your account, made once on the server and never worked out from your Google id or your address, so the links you publish here list and revoke from any browser you sign in on, as the add-on's published links are filed under its own (Your threads and answers still stay in your browser; only a link you press Publish on is kept on our server); the rules for those pages are under Published result links. What the web app does send is a count of a few moments, as the add-on counts its features, each one word from a fixed list: that a question was asked (ask_sent), that it matched a model the web can run (ask_match), one the web cannot run yet (ask_cannot_run) or nothing (ask_nomatch), that it was off topic (ask_offtopic), that a match was opened (ask_open), that a follow-up was asked in a thread (followup_sent), that an answer was shown (answer_shown), and that an answer was rated Right or Not right (react_up, react_down) with the reasons you pick (react_why_model, react_why_numbers, react_why_follow, react_why_asked, the same words the add-on uses), and, from October 7, 2026, Ask’s conversation about an open answer with the add-on’s words and meanings (edit_asked, edit_applied, edit_nomatch, edit_failed, goal_guard, wi_run, wi_landed, wi_failed, rerun_run, verify_run, clarify_shown, clarify_picked, newtopic_confirm, honest_shown, ai_parse_used, ai_parse_auto, ai_parse_confirmed, ai_parse_rejected, ai_parse_failed, ai_parse_capped, ai_kind_edit, ai_kind_fixed, ai_kind_shape, ai_kind_add, ai_kind_remove, ai_kind_pin, ai_kind_whatif, ai_kind_goal, ai_kind_newthread, ai_kind_answer, ai_kind_unknown, rate_match_up, rate_match_down, rate_follow_up, rate_follow_down, rate_edit_up, rate_edit_down, rate_whatif_up, rate_whatif_down, rate_setup_up, rate_setup_down, rate_answer_up, rate_answer_down, rate_help_up, rate_help_down, rate_nomatch_up, rate_nomatch_down, rate_meta_up, rate_meta_down, react_down_open, run_failed, engine_timeout, verify_failed), that a paid gate was shown to a free account (wall_compute, and, only where the pay line is switched on, wall_verify, wall_publish, wall_commit), and, from November 9, 2026, that a goal was said with a question (goal_set), that the model builder was opened from Describe your decision (build_open_describe), from Build it from your numbers (build_open_pill) or by Ask (build_open_ask), that its review was shown (build_review), that Run it here was pressed (build_run), that the model it built opened (build_ok) or did not pass its check (build_refused), that the builder was closed with Never mind (build_cancel), and that a template was opened from Templates or the library (tpl_open, never which template), and one count per closed turn, turn_ followed by how Ask read the message (new, follow, rematch, edit, whatif, rerun, meta, diff, goal, undo, clarify, help, offtopic, nomatch) and how the turn ended (acted, idle, failed, up, down, superseded). A count may carry one more word saying where on the page it came from (ask, card, answer, shared or plan). Each is sent with no question, no answer, no number, no thread and no cookie, and kept only as a daily total. On the browsers we run ourselves, a count may also carry the single mark agent described above, which keeps our own testing out of these totals. Our code does not store your IP address with it.
• Questions asked without signing in (November 2026). When this is switched on, a visitor who is not signed in can ask up to 10 questions a day on the web app the way a signed-in account asks them: a typed question that holds figures (“price is $52, cost is $34”), and the follow-ups in the conversation it starts, go through our server to Google’s AI model (Gemini, under our paid account), which reads which figure is which; every figure in the answer is then worked out by Sortia’s engine. What is sent: the question as you typed it, figures included, up to 2,000 characters; on a follow-up, what the conversation has built so far (the names it gave your figures and the figures you typed); and on the web sheet, its cells, estimates and formulas, which our server reads itself, so the model sees the sheet’s words and the shape of its formulas but never a figure from its cells. A formula reaches the model with every number, every piece of text and every other tab’s name taken out. Figures in a model file or a template you open stay in your browser. How the 10 are counted: your browser makes a random id for itself and keeps it in its own storage for www.sortia.io (under the name sortia.askId); it is not worked out from you, your device or your address. It is sent with a request for a ticket to ask, together with your IP address as every web request carries it. Our code keeps neither (Google Cloud’s own request logs hold the address of every request, under Google’s retention, as they do for every request to this site): it keeps a count of today’s questions, and of today’s tickets, under a scrambled form of the id and a scrambled form of the address, each made with a secret key and the date, so the same browser gets a different key the next day and no key can be turned back into the id or the address. Both counts are deleted automatically once their day is over (UTC), within an hour, so none is kept for more than two days. A question is counted against both, so 10 a day is the limit for this browser and for the address it asks from. The ticket itself lasts ten minutes and holds those two scrambled keys, the date and how many calls it allows; what the questions cost is added to the monthly total for all free questions, which names nobody. We keep no question, no figure and no answer on our server. Past the 10, the web app asks you to sign in. If the AI cannot answer, Sortia’s own rules answer in your browser instead, and the answer says so. To remove the id, clear this site’s data in your browser.
• Plans you track on the web. Only when you press Commit as the plan on an answer do we keep a plan, for your account alone: the name you give it, its question, its goal and the plan’s figure (the level 80 in 100 runs reach, worked out by our server from the model), the model you opened (exactly as the .sortia file or the public template held it: names, estimates and the formulas between them, and any data rows it carries, such as the past figures an estimate is drawn from, with the seed, the number of runs and the sampler), the date you want to check it by, the actuals you type in as they land, what happened when you enter it, and the odds history (each check’s odds out of 100, when it ran and why). Nothing else from a spreadsheet, never a file’s receipt or its list of every run. Our server runs that model again when you change the actuals, and once a day for a plan whose check could not run then, to keep the odds history; for that it also keeps how many times a check has been tried, and gives up after three tries (the plan then says it could not be checked). A plan is kept until you delete it or your account.
• Notifications. When a tracked plan’s odds fall below 50 in 100, when you enter actuals that differ from the ones it holds, and when its check-by date comes, a notification is added to the bell in the web app. Each holds the plan’s random id and its name, which of those three kinds it is, the odds, whether you have read it, and when it was made. Actuals entered again on the same day update that day’s one notification for the plan instead of adding another. Each notification is deleted automatically 90 days after it is made. We send no email about plans.
• Saved sheets and live sheet links. Both are on (live sheet links since November 11, 2026). This is what they keep. When you save an Uncertainty Sheet to your account, so that it opens on another machine you sign in on, we keep the sheet itself as the page saves it (its cells and what they hold, its estimates and its goals), the name you gave it, the sheet id your browser made for it, its size in bytes, the account it belongs to, when it was last changed on your machine and when our server saved it. A sheet you remove is kept only as the fact that it was removed, so your other machines remove it too, and that marker goes 180 days later. An account holds at most 100 sheets. Your own libraries of estimates (My libraries) are kept the same way: for each library we keep the library itself as the page saves it, its library name, the library id your browser made for it, the library’s size, its account, when it was last changed on your machine and when our server saved it, and a removed library is kept only as that fact, for 180 days. An account holds at most 50 libraries. A live sheet link points at one of your saved sheets and has one role: view or edit (a link made earlier may have the role comment). For each link we keep the account and sheet it belongs to, its role, a fingerprint (a SHA-256 hash) of the secret part of the link and never the secret itself, when it was made, whether you turned it off, how many notes it holds, how many changes came through it and when the last one did, and a count of its changes in the last few minutes, so a link that sends too many is paused. Each change made through an edit link is recorded on your account: the link it came through, the sheet, the link’s role, what kind of change it was and when. Only the newest 500 a link are kept, and never who made the change. A note left through a comment or edit link keeps the link it came through, the sheet it belongs to, its number, when it was left, the name the writer typed (or A reader if they typed none), the cell it is about if they picked one, and its text, up to 1,000 characters. A change sent through an edit link is kept in the sheet’s edit log with the link and sheet it belongs to, a random id the editor’s browser made for that visit, its number, the change itself, and when our server received it. Opening a link needs no sign-in and keeps nothing about who opened it. Turning a link off stops it at once for everyone who holds it.
• Deleting it. Delete account, under Account and license in the web app, removes the account, both lookups, every sign-in session and your address on the tester list, if it is there, at once. It also removes every connection to the add-on and the license linked through one. It removes every plan you track and every notification too. It removes your saved sheets, your libraries, your live sheet links, their notes, the edit log and the record of changes too. Links you published from the add-on are not part of the account: they stay live until they expire, or until you revoke them in the add-on. Links you published from the web app are filed under the account’s share id and stay live the same way, but once the account is deleted nothing can revoke them from here, so revoke any you want gone first (or email us). You can also email privacy@sortia.io and we will do it for you.

How your data is protected

• The strongest protection is not holding it. Sortia operates no database of spreadsheet content. Your spreadsheet data is never copied to us, so there is no store of it to breach, subpoena, or leak. The one thing of yours we keep is a plan you choose to track on the web: the model you opened there (with any data rows it carries) and what you typed about it, as listed above.
• Computation stays where your data already is. Analysis runs in your browser and in Google’s Apps Script environment, inside the spreadsheet you opened Sortia in. Access is limited by the spreadsheets.currentonly scope, so the add-on cannot reach any other file in your Drive even if it tried.
• Everything that does leave is encrypted in transit. The only network requests Sortia makes are the anonymous usage events, the license checks and the written-readings payload described above, and all of them use HTTPS with TLS.
• Secrets are held in Google Secret Manager, not in code or configuration files. The license signing key and the model API key are never exposed to the add-on or the browser.
• Access is limited to the developer (Ben Malott) through a Google account protected by two-step verification. No third party, contractor, or subprocessor has access to Sortia’s infrastructure.
• Payments are handled entirely by Stripe. Sortia never sees or stores card details.

Data retention and deletion

• Google user data the add-on reaches: retained for zero days. The add-on does not store your spreadsheet content, your Google account details, or anything derived from them, at any point. There is nothing to delete because nothing is kept.
• A sortia.io account, if you make one, is kept until you delete it, under Account and license in the web app or by email. Its sign-in sessions go 30 days after their last use, and 90 days after they started at the latest, as Your sortia.io account says. Plans you track there are kept until you delete them or the account; notifications go 90 days after they are made.
• What lives in your own spreadsheet stays yours. Result tabs, example sheets, the hidden settings sheet (saved distributions and scenarios) and, when you press Commit, a plan’s figure, Actual column and hidden plan record on the model’s tab are written into your file. Delete those sheets, or the file, and the data is gone; Undo removes a plan, and so does deleting the tab it is on. The random counting number described above is not on a sheet and is not in the file at all: it lives in your Google account's add-on storage, alongside three small bookkeeping markers (whether your first open has been reported, whether your first finished run has been reported, and which week and month were last counted). All of them are invisible in the grid, none of them is ever sent to us, and because they belong to your account rather than to any one file, deleting a spreadsheet does not remove them; removing Sortia from your Google account is what does. Before August 28, 2026 these were stored in each file and did go with it. Uninstalling the add-on removes our access immediately.
• Counting tokens are kept for 30 days, in a Google Cloud database in the United States, and are then deleted automatically. After that, all that remains is daily totals: how many accounts were active, how many runs finished, how many times each plan limit was met. Those totals are plain numbers with no token in them and we keep them indefinitely. Any daily total we publish that covers fewer than five accounts is suppressed rather than shown, so a small number can never point at one person.
• Purchase records are held by Stripe under their retention policy, because tax and accounting law requires keeping invoices. We keep your email address only for as long as your subscription is active, solely to issue license keys.
• To delete your counting data, remove Sortia from your Google account. The random id lives in that account's add-on storage, which only Sortia can read, and once the add-on is gone no future token can be derived from it. Deleting a spreadsheet does not remove it, because since August 28, 2026 the number belongs to your account rather than to any one file. Tokens already sent are not linked to you or to your Google account, so there is nothing to look up by name; they are deleted automatically within 30 days. For purchase records, which are held by Stripe and do carry your email address, email privacy@sortia.io and we will remove what we hold within 30 days and confirm when it is done.

Who is responsible for your data

Sortia is built and operated by Ben Malott, a sole developer based in California, USA, who is the data controller for the limited information described above. For any question about this policy, or to exercise the rights below, email privacy@sortia.io.

Two services process information on our behalf: Google Cloud hosts the license and usage endpoints, and Stripe processes payments. There are no other subprocessors, and no contractors or third parties have access.

Why we are allowed to process it

• To provide what you bought. Your email address is used to issue and refresh license keys. This is necessary to perform our contract with you.
• To keep the product working and improve it. Anonymous usage counts tell us which plan limits people meet and which upgrade prompts get clicked. This is our legitimate interest in maintaining and improving Sortia, and it is designed so it cannot identify you.
• To meet legal obligations. Stripe retains invoices because tax and accounting law requires it.

Your rights

Wherever you live, you may ask us to give you a copy of any information we hold about you, correct it, delete it, restrict or object to how we use it, or provide it in a portable form. Email privacy@sortia.io and we will respond within 30 days at no charge. In practice these requests are simple to satisfy, because the only things we hold on purpose that could identify you are an email address tied to an active subscription, the email address and Google account id of a sortia.io account if you made one, and, on a site license, the keyed hash of the work address the holder typed at activation. The one thing we do not hold on purpose is whatever a failure’s error text happened to quote into our error logs (set out under Data processing details); if you want something in them removed, email us and we will. A sortia.io account is identified by its email address; you can delete it yourself, under Account and license in the web app, or ask us to by email.

If you are in the EU, the UK, or Switzerland, you also have the right to complain to your national data protection authority. If you are in California, we confirm that Sortia does not sell or share personal information, and never has.

Where your data is processed

Your spreadsheet content stays in Google’s systems in your own account and is never sent to us. The small amount of information we do handle, license checks, anonymous usage counts and sortia.io accounts, is processed on Google Cloud servers in the United States. If you are outside the United States, that means this limited information crosses a border, and we rely on the standard contractual clauses that Google Cloud and Stripe maintain for such transfers.

Analytics and cookies

The marketing pages of this site ask before they load analytics. Until you press Accept, no Google Analytics script is created, no request goes to Google and no analytics cookie is set; the only thing the page stores is your answer, in your browser’s own localStorage, under the name sortia_ga_consent. Decline stores no, and analytics never loads, on this page or any other page of the site. Accept stores yes, and every marketing page then loads Google Analytics (measurement id G-KFVMX61RP9) from googletagmanager.com, which sets its own cookies in your browser. It receives the page you are on, the page that linked you here, and a random identifier kept in those cookies; it does not receive your name, your email address or anything from your spreadsheets. To change your answer later, clear this site’s data in your browser and reload, and the question comes back. With JavaScript turned off the question is never asked and analytics never loads. Two pages of the website, /open and /proof, load no Google Analytics at all, because they read model files you choose.

Advertising measurement. The Google Analytics property is linked to a Google Ads account (AW-18416109974). Because of that link, pressing Accept can also send conversion and remarketing signals to Google’s advertising systems, which may set their own cookies from google.com and doubleclick.net. We show no advertising on this site. Press Decline and none of it is sent.

Cookies and children

The website’s only analytics cookies are the Google Analytics ones described above, and they are set only after you press Accept. The add-on sets no cookies and sends nothing to Google Analytics.

The web app pages at www.sortia.io/app load no Google Analytics and no other analytics script; the only counts they send are the fixed words listed under the web app. They set one cookie, the sign-in session described under Your sortia.io account, and only on the sign-in screen and when you sign in: it is readable by our server alone, sent only to the sign-in addresses under www.sortia.io/api (never to the rest of the site or to shared result pages), and used for nothing but signing you in and keeping you signed in. A visitor who asks without signing in also gets one entry in this site’s own browser storage, the random id described under Questions asked without signing in, which is not a cookie and is sent only with a request for a ticket to ask. The Continue with Google button on those pages is drawn by Google, from accounts.google.com, and Google’s own privacy policy covers it.

Sortia is not directed at children and we do not knowingly collect information from anyone under 13. If you believe a child has provided information, email us and we will delete it.

Limited use of Google user data

Sortia’s use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements. Sortia does not transfer Google user data to third parties, does not use it for advertising, and does not allow humans to read it.

Changes and contact

Material changes to this policy will be reflected in the add-on listing and this document with an updated date. For questions about this policy or your data, email privacy@sortia.io.