Data requests — TokenTriage

1. Before anything else: which TokenTriage are you asking about?

This is not a formality. The answer to “what do you hold about me” is completely different in each of three cases, and sending the request to the wrong place costs you the time it takes us to write back and say so.

You visited this website: We are responsible for that data and this page is for you. Go to §5.
Someone runs TokenTriage themselves and your prompt went through it: A gateway that somebody else operates sends us nothing, so that prompt never reached us and we cannot see it. The organisation running the gateway is the one to ask —§3 explains what they have to answer you with, which is worth reading before you write to them.
You use the hosted service: It is not open yet, so there is nothing to ask about today.§4 says which document will govern it when it opens.

2. This website: what we hold, and how little of it there is

We are the controller of this data. The complete inventory is in the privacy policy — §3 lists what is collected and §5 how long it is kept — and the providers that receive any of it are on the subprocessors page. What matters for a request is that most of it is keyed to one thing: an email address you gave us on purpose.

If you have written to us, subscribed to the mailing list, or booked a demo, that address is the handle on everything we hold about you, and a request from it is straightforward to answer. If you have only read pages, keep reading — the next paragraph is the honest part.

We almost certainly cannot find your analytics events, and that is by design rather than by evasion. Analytics on this site runs without storing any identifier on your device unless you switch it on yourself, so there is nothing connecting one page view to the next, let alone to a person. If you ask us to produce or erase your analytics history, the truthful answer is that we hold no key that would let us find it. We will say that plainly rather than send you an empty file and call it a report. Those events age out on their own after 12 months.

If you did turn the identifier on, it is a random value in your browser and not a name. Turning it back off in the site footer removes it from your device and stops further collection. That is the control that actually works; a request to us is the slower path to a worse outcome.

3. The software you run yourself: we hold nothing, and here is what your operator does hold

The TokenTriage software does not transmit anything to us. No telemetry, no usage reporting, no activation check, no update ping —the privacy policy, §2 is the full statement and it is unchanged. So if your prompt passed through a TokenTriage gateway that someone else operates, we did not receive it, we cannot search for it, and we cannot delete it. We also cannot tell you who runs it, because we have no way of knowing that deployment exists.

That leaves you writing to the organisation whose product you were using. This section is for both of you, because a request lands better when the person receiving it knows what they actually have. Three facts about a TokenTriage gateway, each checkable in the software:

The prompt text is usually not there. A gateway records a row about each request — a content hash, sizes, cost, which model answered — and verbatim capture of request and response bodies is a separate setting that isoff by default. Turned on, it sits behind its own privileged scope and writes an audit row on every read. So the first question to ask an operator is whether capture was on, because the answer decides whether your words were ever stored at all. This is documented at operational security.
Whatever a gateway holds, it can hand over in one piece. The eject bundle — tokentriage eject bundle, or the same operation over the dashboard API — produces a complete, verifiable copy of everything a gateway holds, and it restores. It is a real portability tool and an operator can run it today.It is also whole-deployment, not per-person: it was built so a deployment can be moved, backed up or handed over intact, not so that one person’s records can be lifted out of it. Anyone extracting a single person’s records from a bundle is doing that work themselves.
Deletion is a clock, not a verb. Records age out under a retention policy the operator sets, and each deletion writes its own audit row naming the file and the reason. The gateway’s API has no request that erases one person’s records from a ledger. The deletions it does offer are of operator objects — a dashboard user, a saved view, a schedule, a cache — not of a person’s history. We measured that rather than assuming it, and we are saying so because an operator who promised their own user an erasure on the strength of a vaguer sentence would have been let down by us. Whether one can be assembled out of retention settings and the tools an operator has is their question to answer, not ours to pre-empt.

None of that is advice about what an operator owes you — that is between you and them, and it depends on where you both are. It is a description of the machinery, so that neither side spends a month discovering its shape.

4. The hosted service: not open, and governed by its own notice

The hosted service is not open yet, so no request about it can exist today.

When it opens, the shape of a request changes in a way worth knowing in advance. For a customer’s own traffic we would be a processor and the customer the controller — which means a request from one of their end users goes to them, and we act on their instructions rather than reaching into their workspace on our own initiative. That is the ordinary arrangement and it is not a way of dodging the request; it is the only arrangement under which a customer stays in control of their own users’ data.

The specifics — what is recorded, for how long, and what a customer can ask us to do — belong to the hosted service’s own privacy notice and agreement: versioned documents accepted at signup. This page does not restate them and will not, for the reason the privacy policy, §11 gives: a document you accept and a page you read are different instruments, and a paraphrase of the first on the second is a second copy that nobody reviewed.

Your own account details — the personal data of the person who signs up, as opposed to the traffic their workspace carries — are ours as controller, and §5 below will apply to them unchanged.

5. How to make a request, and how we check it is you

Write to [email protected].There is no form, no account to create and no portal. Say what you want — a copy of what we hold, a correction, deletion, or just an answer to whether we hold anything at all — and send it from the address you think it is attached to, if you can.

Sending it from that address is normally the whole of the identity check.The email address is the key almost everything we hold is filed under, so control of the mailbox is the proportionate proof. If you cannot send from it, tell us why and we will work out something sensible for what is being asked — a deletion needs more confidence than a question about whether we hold anything.

We will not ask you for identity documents as a matter of course.Demanding a passport scan to answer “what do you hold about me” would leave us holding more than we started with, which is a strange outcome for a privacy request. If a request is high-risk and the mailbox alone is not enough, we will say what would satisfy us and why, and we will not keep whatever you send beyond deciding the question.

If we cannot establish that a request is yours, we will refuse it and say so.Handing someone’s data to whoever asked for it convincingly is the failure this step exists to prevent, and a refusal is not a stalling tactic — it comes with the reason and with what would change the answer.

You may use an authorised agent where your local law provides for one; we will want to see that they are authorised.

6. The clock

We work to one month from the day the request arrives, and we apply it to everyone rather than sorting requesters by jurisdiction first. One month is the period the GDPR sets in Article 12(3); the California statute allows longer. Running the shorter one for everybody is a scheduling decision, and it is the honest one — two clocks is how one of them gets missed.

The clock starts when the request arrives, not when we finish checking who you are. Where verification takes a few exchanges, that time is inside the month, not added to it.

If a request is genuinely complex the GDPR allows a controller two further months. If we ever need that, you will hear from us inside the first month with the reason. A request that goes quiet is a request we have got wrong, and the thing we are committing to here is not speed — it is that you are never left wondering.

We have never charged a fee for a request and we do not have a fee schedule.

7. What we do, in order

The procedure is short because the data is small. It is written down so that it is the same every time and so you can hold us to it:

Acknowledge. A human replies confirming we have it and the date the month runs from. If we need something to identify you, that ask goes in the same reply rather than a week later.
Establish it is you, proportionately, per §5.
Search what we actually hold — our mailbox, and each provider on the subprocessors page that could hold something keyed to you. That list is a reliable starting point for a website request specifically, because the browser-visible half of it is reconciled against this site’s enforced Content-Security-Policy by a build check: a third party cannot start receiving data from this website without being named there. The rows the check cannot corroborate are marked as such on that page, and they are the hosted service’s, which is not open.
Answer in full, including the gaps. If part of the request cannot be met — the analytics case in §2 is the usual one — we say which part and why, rather than answering the easy half and going quiet on the rest.
Do it, and confirm when it is done rather than when it is scheduled.
Keep a record that you asked and what we did. That record is itself personal data and we keep it deliberately: erasure evidence that the erasure destroys is not evidence. It is the request and its outcome, not a copy of what was deleted.

8. If you are not satisfied

Tell us — the same address, and say that is what you are doing so it does not read as a repeat request. If you are in the European Economic Area or the United Kingdom you may complain to your national supervisory authority, and that right is not conditional on contacting us first. We would rather you told us, but it is your right and not our permission to give.

9. Related documents

The privacy policy is the inventory: what is collected, why, who receives it and for how long. The subprocessors page names every recipient and says which rows a build check corroborates and which are declared by hand. The security page covers how what we hold is protected, how to report a vulnerability, and the data-processing-agreement question for a vendor review.

Written by INFEROPS LLC. This page describes our own procedure; it is not legal advice, and it does not decide which law applies to you.