Praximos Privacy Policy

In force from: 2026 08 06

Applies to: everybody whose personal data reaches Praximos. That is two different people with two different relationships to us, and this document keeps them apart throughout.

An Issuer holds the account. They chose Praximos, they agreed to our terms, and they decide who is written to and about what.

A Recipient was written to because an Issuer asked for a document or a piece of information. They have no account, they never agreed to anything with us, and in most cases they had not heard of us before the message arrived. Section 9 is written for them and can be read on its own.

The terms of service at /terms are a separate document. They are the agreement between us and an Issuer, and sections 6 to 13 of them govern what an Issuer promises us about the people they ask us to contact. This one is about what happens to the data itself.

1. Who is responsible

Praximos is a product of Techthos L.P. The company registration and the postal address are on the imprint published at https://www.techthos.net/legal/imprint/ and linked in the footer of every page here.

Write to info@techthos.net about anything in this document. It is a real mailbox read by a person, and it is the same address the support page gives.

Responsibility is split, and the split is the most important thing on this page.

For an Issuer's own account data, Techthos is the controller. The account exists because the Issuer created it with us.

For a Recipient's personal data, the Issuer is the controller and Techthos is the processor. The contact record, the request, and whatever comes back all exist because an Issuer put them there. We act on that Issuer's instructions, which are the requests they create, and we do not decide what is asked of whom.

This has a practical consequence for a Recipient. If you want to know why you were asked for a particular document, or you want the request itself changed or withdrawn, that is a matter for the Issuer who sent it, because we cannot answer it and cannot change it. If you want the messages to stop, or you want to reach a human about the link or the upload page, section 9 says how, and we act on that ourselves without waiting for anyone.

We enter into a data processing agreement with an Issuer covering that relationship. It is available on request from the address above.

2. What the product does

Praximos dispatches obligations on an Issuer's behalf. An obligation is one Recipient, one deadline, and a set of requested inputs.

The Issuer works entirely through an AI assistant such as Claude or ChatGPT, connected to us over the Model Context Protocol. There is no dashboard. The Recipient works through an ordinary web page opened from a single use link in a message, and needs no account and no password to use it.

Between those two points we send the first message, send reminders until the Recipient answers or the deadline passes, take what they send, and tell the Issuer.

3. What is collected

3.1 From an Issuer

• The email address the account is under, and a hash of the password. The password itself is never stored.
• A display name, which is the name Recipients see on every message sent in the Issuer's name.
• A language and a timezone.
• An optional logo, used on the pages and emails Recipients see.
• The date the terms of service were accepted and which version of them, and separately the date the preview clause in section 4 was accepted and which release phase it described.
• Account state and plan, and the settings for the digest email.

3.2 About a Recipient, entered by an Issuer

• A name and an email address.
• Optionally a phone number, when the Issuer wants to reach them by SMS or WhatsApp.
• A language and a timezone, so the message arrives in a language they read and a deadline means what they think it means.
• Which channels they have stopped, one flag per channel, and the date any WhatsApp opt in was recorded.
• Counters: how many requests were sent to them, how many they completed, how many they declined, and how long they took in total. These are used to show an Issuer a response rate rather than a list.

3.3 From a Recipient, when they answer

• The value they typed into each requested field. What those fields are is decided by the Issuer, one request at a time, so the categories are whatever the Issuer asked for.
• Any file they upload, its filename, its size and its type, and the PDF assembled from photographs of a paper document.
• A verdict on the quality of an uploaded photograph, and the detail behind it, such as whether it is legible or cropped.
• The date and time of each answer and which channel it arrived on.

3.4 Records the service writes about itself

• One row per message actually sent: which account, which contact, which channel, when, and what the provider afterwards reported about delivery.
• The history of each obligation: created, sent, reminded, answered, closed, and when.
• One row per access link: the expiry, how many times it was opened and when it was last opened. Only the SHA 256 of the link's token is stored, so a copy of our database does not hand anybody a working link into somebody else's request.
• IP addresses, held briefly in memory for rate limiting, in order to keep the service available and to make guessing at a link impractical.

4. Why it is processed, and on what basis

For an Issuer's account data, the basis is the contract between them and us. We cannot run an account without an address to reach it at, and we cannot bill without knowing which plan it is on.

For a Recipient's data, the Issuer sets the basis, not us, because the Issuer is the controller. In the ordinary case it is the professional relationship the Recipient already had with them: an accountant asking a client for an invoice is continuing work the client engaged them for, not marketing at them. What the Issuer warrants to us about that is section 6 of the terms of service.

We keep the send records and the obligation history for two purposes of our own: to enforce the sending limits an account is subject to, and to be able to show, if a carrier or a supervisory authority asks, which message went where and when.

We do not profile anybody, we do not use a Recipient's contact details for any purpose of our own, we never market to a Recipient, and a contact held by one Issuer is never disclosed or reused for another Issuer.

5. Who else sees it

These are the sub processors the service depends on. Each one receives only what the task needs.

The email provider. Amazon Web Services, through Simple Email Service. It receives the message: the Recipient's email address, the Issuer's name, the subject and the body, and the link. It runs in the us-east-1 region, which is in the United States, so email sent through Praximos leaves the European Union in transit. Section 6 says what that means and what does not follow from it.

Object storage. Files a Recipient uploads are held in object storage that runs inside the Praximos deployment itself, on the same infrastructure as the application, rather than at a third party. No separate company receives them.

The model provider. Anthropic, used for three narrow tasks: turning the Issuer's sentence into a list of requested fields, writing the wording of the message to the Recipient once when the request is created, and, only where the Issuer set a validation prompt, judging whether an answer satisfies it.

What Anthropic receives is bounded and worth stating exactly. For drafting: the Issuer's own sentence and the Recipient's name. For the wording: the title of the request, the fields, the deadline, the Issuer's name and the Recipient's name. For validation: the Issuer's prompt, the text the Recipient typed, and the filenames of any uploads. No uploaded file is ever sent to the model. The bytes of a document stay in object storage and are read only by the Issuer. Anthropic processes outside the European Union.

Every one of those three tasks has a fallback that does not use the model at all, and it is used whenever the model is unavailable, so nothing about the service depends on a model answering.

The messaging provider. Twilio, for SMS and WhatsApp, and Meta beyond it for WhatsApp. It would receive the Recipient's phone number and the text of the message. This is not in use today. Every account sends by email only, and an instance with no Twilio credentials has no phone channel at all. This section is here because the code is written and the switch is an operational decision, and we would rather name a processor before it starts than after.

The hosting provider. The servers the application and its database run on. Named on the imprint.

We do not use third party analytics, advertising networks, or tracking of any kind.

6. Where it is held, and for how long

The database and the uploaded documents are held in the European Union.

The two exceptions are named in section 5 and are both about transit rather than storage: email goes out through a United States region, and the model provider processes outside the European Union. Transfers are made under the European Commission's standard contractual clauses.

Uploaded documents are deleted thirty days after they are delivered to the Issuer. Praximos is not the archive of record. The Issuer is expected to keep what they asked for in their own system, and after thirty days it is not here to be asked for.

An obligation and its history are kept for as long as the Issuer's account holds them, because they are that Issuer's record of what they asked for and when. An Issuer deletes an obligation whenever they want, and section 7 is exactly what that destroys.

Send records are kept for as long as the account exists. They are the count behind the sending limits, and a count that shrinks when somebody deletes their own history is not a limit.

7. Deleting an obligation, and what survives it

An Issuer can destroy a request outright, not merely close it. When they do, all of the following are deleted and are never listed again: the request itself, the list of fields it asked for, the wording that was sent, every answer, every uploaded file and the PDF made from it, the history of the request, and every access link into it.

If the request had already gone out and had not yet ended, the Recipient is sent one last message telling them it has been withdrawn and there is nothing to do. That message is sent before anything is deleted, because somebody who was told to send a document is owed the sentence saying not to bother.

Two things deliberately survive, and this is the complete list.

1. The send records, with the reference to the deleted request removed. What remains is that a message went to a contact on a channel on a date. They are kept because they are the count behind the account's sending limits.
2. The contact's counters, described in section 3.2. They are totals across a relationship rather than part of the deleted request.

Neither contains the content of the request, the answers, or any file.

8. Deleting a contact

An Issuer can delete a contact.

A contact who was never sent anything is deleted outright and the row is gone.

A contact with history cannot be, because that history is the Issuer's own record of requests they made. That case is answered by erasure of the identifiers instead: the name and the phone number are cleared, the email address is replaced with a value that reaches nobody, every channel is switched off so no further message can be sent, and what is left is the counters. Nothing further can be delivered to that person through this account.

We record that some supervisory authorities do not accept this as a complete answer to an erasure request. We would rather write that down than pretend the question is settled. Anybody who wants the stronger outcome should write to the address in section 1 and we will deal with it individually.

9. What a Recipient can ask for

You have no account here and you did not ask us for anything. This section is what you can do about that.

To stop the messages. Every message we send carries a link that stops them. Use it and that Issuer sends you nothing further on that channel. We act on it ourselves and immediately, and a message already handed to the provider may still arrive.

Today every message is email, so that link is the whole of it. Once the phone channels described in section 5 are switched on, the same link is carried on them, replying STOP works wherever the sending number can receive a reply, and on WhatsApp you can block or use Meta's own stop control. In some countries a business sender cannot receive a reply at all, which is why the link and not the keyword is the route we rely on.

Stopping is per Issuer and per channel. It does not affect any other business that uses Praximos, because your details were never shared between them.

To ask what the request is about, or to change it. That is for the person who asked you. They set the request, they set the deadline, and only they can change either. We cannot.

To reach us. Write to info@techthos.net if the link does not work, if the page will not take your files, if you want the messages to stop and the link did not do it, or if you want to exercise any of the rights below.

Your rights. Under the General Data Protection Regulation you can ask for a copy of your data, ask for it to be corrected, ask for it to be erased, ask for processing to be restricted, and object to it. Because the Issuer is the controller of your data and we are the processor, a request usually has to be answered by them, and we will pass it to them and help them answer it. We will tell you which Issuer that is, and we will do so quickly and without asking you to prove anything unreasonable.

You can also complain to a data protection supervisory authority in the country where you live.

Nobody from Praximos will ever ask you for a password. You do not have one here.

10. What an Issuer can ask for

The same rights, exercised against us directly, because for the account itself we are the controller.

You can ask us for a copy of everything the account holds, and you can ask us to close it. There is no button for either yet: write to the address in section 1 and a person does it. Closing an account stops all sending immediately, ends every connected assistant session, and pauses every standing request.

What you delete inside the product yourself is described in sections 7 and 8, and it takes effect the moment you do it.

11. Automated processing

One decision in the product is made without a person, and it is worth naming.

Where an Issuer sets a validation prompt on a request, an answer that arrives is judged against it by a model. In advisory mode the verdict is only shown to the Issuer, who decides. In strict mode a failing answer is refused and the Recipient is asked again, with the reason in words.

That decision has no legal or similarly significant effect: it does not end a relationship, refuse a service, or decide anything about anybody. It asks for a better photograph. The Issuer sees every verdict, can override any of them, and can turn validation off. A Recipient who thinks a refusal is wrong should say so to the Issuer, and section 9 says how to reach us if that gets nowhere.

There is no profiling and no automated decision beyond this one.

12. Cookies

Two, both strictly necessary, neither for advertising.

• praximos_session keeps an Issuer logged in. It lasts thirty days, is not readable by scripts, and is not sent on requests from other sites.
• praximos_csrf protects forms against being submitted from another site. It lasts twenty four hours.

There are no analytics cookies and no third party cookies. Neither of these carries anything about a Recipient beyond keeping the submission page working, and nobody is tracked across sites or across visits.

The cookie notice for the company website is a separate document at https://www.techthos.net/legal/cookie-privacy/ and does not describe this product.

13. Security

Passwords are stored only as hashes. Access link tokens are stored only as hashes, so the database does not contain a working link. Every connection to the service is over TLS and there is no plaintext option. Uploaded documents are in private storage and are reachable only through a link that expires.

Each account's data is isolated from every other account's, and every query that reads a contact, a request or a document is scoped to the account that owns it.

If a breach affects personal data we notify the supervisory authority and, where the risk is high, the people affected, within the periods the General Data Protection Regulation sets.

14. Changes

The version in force is always the one published at this address, with the date at the top of this document.

A change that affects how personal data is used is announced to Issuers by email before it takes effect. A Recipient has no account to notify, which is another reason this page is public and needs no login to read.

15. Reaching a human

info@techthos.net, for anything on this page, whoever you are.

There is no telephone line and no chat. One address answers everything, and it is read by a person rather than a queue.