Praximos Terms of Service

Date: 2026 08 08

Applies to: the Issuer, meaning the account holder, acting in a professional capacity. Not a recipient facing document, and not offered to consumers.

These terms are not the only document that governs the service. They govern it together with the data processing terms in section 13, the privacy policy, and the provider policies named in section 12; section 12 says which one applies where a provider policy is stricter. Everything about messaging permission is sections 6 to 13 of this document rather than a text of its own, because an agreement that lives in two places drifts between them and an Issuer accepting one of them has accepted half.

The whole of the messaging half rests on one fact about the product. Praximos sends messages that carry the Issuer's name to people who have no Praximos account and never agreed to anything with Praximos. The permission that makes those messages lawful was given to the Issuer, before Praximos was involved, and Praximos cannot observe it. So the Issuer asserts it, and sections 6 to 13 are what that assertion means.

The whole of the remaining half rests on a second fact, which is that this product is not finished. Section 4 is that statement and it is one of the sections an Issuer accepts separately, because a preview is not something anybody should be able to agree to by not reading.

A third fact frames both. Praximos is a business service. Every surface assumes an Issuer with clients, a professional relationship with each of them, and obligations of their own as a controller, so it is offered only to people acting in the course of a trade, business, craft or profession. Sections 2 and 3 say what that includes and what it excludes.

1. Definitions

Techthos is Techthos L.P., the company that operates Praximos. Where this document says Praximos, it means the service; where it says Techthos, it means the party on the other side of this agreement.

Praximos is the service: an obligation dispatcher whose issuer facing interface is a remote MCP server, reached from an assistant such as Claude or ChatGPT.

Issuer is the account holder: the natural person who holds the account, acting in a professional capacity. They are the party to this agreement, the party whose name appears on every message, and the data controller for every recipient record in the account.

Professional capacity means acting for the purposes of a trade, business, craft or profession, whether on one's own account, as a partner, as an office holder, or as an employee. Its opposite is a consumer, meaning a person acting for purposes outside all of those, and section 2 says Praximos is not offered to one.

Recipient is the person an obligation is addressed to. They have no account. They exist in the system as an email address, and optionally a phone number, plus a language and a timezone.

Contact is the stored record of a Recipient inside one Issuer's account. A contact belongs to one account. The same person held by two Issuers is two contacts with no relationship to one another, and permission recorded on one says nothing about the other.

Channel is email, SMS, or WhatsApp. Each has its own permission standard, its own withdrawal, and its own record.

Messaging Permission is the whole of what an Issuer must hold before Praximos may send to a Recipient on a channel. It is four separate things, and holding one of them is not holding another:

1. A lawful basis under applicable data protection law for processing that Recipient's personal data and for sending them the message. Which basis applies turns on facts only the Issuer has, and this document does not choose one.
2. Transactional messaging permission, meaning that the Recipient gave the Issuer the address or number for work of this kind and would expect a message of this kind, on this channel, about this subject matter.
3. Provider policy consent, meaning whatever the messaging provider's own policy requires before a first message on a phone channel, in the form it requires. Section 7.2 is the SMS case.
4. WhatsApp opt in, which is explicit, names WhatsApp, and names the Issuer. Section 7.3 is that case, and none of the other three is a substitute for it.

Messaging Permission is given to the Issuer, not to Praximos, and it is not transferable to any other Issuer. Where an earlier revision of this document said consent without qualification, this is what it meant.

Obligation is the unit of work: one Recipient, one deadline, a set of requested inputs. Every message Praximos sends is about one.

Release phase is the state this instance declares itself to be in, being alpha, beta, or stable. Section 4 says what each means, and the bar at the top of every page says which one is running.

2. The service, and what it is not

Praximos takes an instruction from the Issuer, expressed to an assistant in ordinary language, and turns it into a request addressed to a Recipient: an email or message naming the Issuer, a page the Recipient opens with no account, a deadline, and a ladder of reminders until the Recipient answers or the deadline passes.

There is no dashboard. The Issuer's entire interface is the assistant they already use, and everything the product can be asked to do is a tool call from inside it. An Issuer who stops using that assistant has no other way in, which is a design decision rather than an omission.

Praximos is a business service. It is offered only to people acting in a professional capacity, and it is not offered to consumers or for private or household use. Every surface assumes an Issuer with clients, a professional or contractual relationship with each of them, and the Issuer's own duties as the controller of those clients' personal data; none of that describes somebody chasing a friend for a photograph.

A person registering confirms, in a tick box of its own under section 18, that they are opening the account for business or professional purposes and are not acting as a consumer. That confirmation is recorded on the account with the date. It is continuing rather than a formality at signup: an Issuer whose use ceases to be professional closes the account.

Praximos is not an accounting system, not a document management system, and not a system of record. Documents a Recipient submits are delivered to the Issuer and then deleted on the schedule in section 13. The Issuer keeps their own copy.

Praximos does not read a Recipient's documents for any purpose other than assembling them, checking that a scan is legible, and, where the Issuer asked for it, comparing a submission against the Issuer's own stated criteria.

3. The account

One account is one user. There are no organisations, no roles, and no additional seats. An account is created with an email address the holder controls and is usable once that address has been verified.

The party to this agreement is the natural person who holds the account, acting in a professional capacity on their own behalf. Praximos has no company accounts and no mechanism by which one could exist: there is no organisation record, nobody to countersign, and no way to give a second person access. Registering in the name of an employer, a partnership, a firm, or a client is therefore not something this agreement provides for, and the person who registered is the Issuer whoever else benefits from the work done through the account.

That is a deliberate limit and it is stated rather than left to be discovered, because it decides who is liable under sections 12 and 15. An Issuer who needs their firm to be the contracting party should wait for entity accounts, which section 21 records as open.

The Issuer is responsible for everything done through their account, including everything done by an assistant connected to it. Connecting an assistant grants that assistant the ability to create obligations and to send them, and the read back the product speaks before and after each send is the mechanism by which the Issuer stays in control of what it does. An Issuer who is not reading those sentences is still bound by them.

An account may be closed by the Issuer at any time and for any reason. Techthos may suspend or close an account under section 12 or section 17.

4. Release phase: alpha and beta

This section is one of the three an Issuer accepts separately at registration, and it is the reason there is a coloured bar above every page while the instance is in alpha or beta.

Alpha means the product is not released. It is being built and changed daily. The data in an alpha instance is not fully backed up, and the database may be reset in whole or in part when the product changes shape. Accounts, contacts, obligations, submitted documents and history may be deleted without warning and without any way to recover them. An Issuer must not put anything into an alpha instance that they cannot afford to lose, and must keep their own copy of anything that matters.

Beta means the data is kept and the behaviour is still changing. Features may be incomplete, may behave differently between one week and the next, or may be withdrawn. Bugs are expected. Data loss is less likely than in alpha but is not excluded. Anything found in beta is reported through the support page, which is the only support channel.

Stable means neither of the above is asserted and this section stops being offered for acceptance. It does not retroactively change what happened to data during a preview phase.

The Issuer accepts, for as long as the instance they use is in alpha or beta:

1. That the product is not released and is not represented as fit for any particular purpose.
2. That data loss, data reset, downtime, and incorrect behaviour are expected outcomes rather than faults, and that no service level of any kind is offered.
3. That messages Praximos sends on the Issuer's behalf during a preview phase are nonetheless real messages reaching real people, and that every obligation in sections 6 to 13 applies to them in full.
4. That, to the fullest extent applicable law permits, Techthos is not liable for loss or corruption of data, for a message that was not sent, for a message that was sent twice, for a deadline that was missed, or for any other consequence of a defect in either preview phase. Section 15 is where that limit lives, and it states both the cap that applies and the liabilities that cannot be limited at all.
5. That the preview is provided free of charge and that no payment is due for it.

Point 3 is the one that is easy to miss. A preview does not make a Recipient's inbox a test environment. There is no mode in which Praximos sends to a stranger and it does not count.

The preview is free. That is a statement about the price and nothing more. The limits in section 15 apply whether or not anything is paid and do not depend on the preview being free, and this section is not an attempt to trade one for the other.

Acceptance of this section is recorded on the account with the date and the phase it was given under. It is not pre ticked, it cannot be given by an assistant on the Issuer's behalf, and registration does not complete without it.

5. Fees

Praximos is free of charge during alpha and beta. No payment method is collected and no charge is made.

The free tier carries caps, which are enforced when an obligation is sent rather than when it is created: a number of obligations per calendar month, a number of contacts, a number of model assisted validations per month, and a daily ceiling on messages to any one recipient domain or dialling code. The current values are stated in the product when a cap is reached.

Paid plans do not exist yet. When they do, the terms for them will be a change under section 20 and an Issuer who does not accept them will not be charged.

6. What the Issuer warrants

By adding a Contact, and again by enabling a channel on that Contact, the Issuer warrants each of the following, for that Contact and that channel, at the time of the action and for as long as messages continue:

1. The Issuer holds an appropriate lawful basis under applicable data protection law for processing that Recipient's personal data and for sending them messages of this kind on this channel. Which basis it is, is the Issuer's own assessment on facts only the Issuer has. This agreement neither chooses one nor warrants that any particular one is available.
2. The Recipient gave the Issuer the address or number themselves, in the course of a professional or contractual relationship between them.
3. The Recipient would reasonably expect to receive messages of this kind from the Issuer, on this channel, about this subject matter.
4. On SMS and on WhatsApp, the Issuer holds the prior express permission the messaging provider's policy requires and the permission the law applicable to that Recipient requires, in the form each of them requires, obtained before the first message. Section 7 says what that means channel by channel.
5. The Issuer holds evidence of what was given, by whom, when, and through what route, retains it, and can produce it promptly. Section 11 says how long and what promptly means.
6. Permission has not been withdrawn by any route, including one Praximos cannot see, such as a phone call or a conversation in person.
7. The relationship with the Recipient, the content of the messages, the data the obligation asks for, and the use the Issuer makes of it are lawful in the country the Issuer operates from and in the country the Recipient is in. Praximos does not assess any of that, does not advise on it, and nothing in this document is a representation that a given use is lawful anywhere.

The warranty is per channel. Adding a phone number to a contact who was reachable by email is a new assertion about a new channel, not an extension of the old one.

The warranty is continuing. An Issuer who learns that a Recipient no longer wishes to be contacted must record it in Praximos, whatever route the withdrawal arrived by.

7. Messaging permission, per channel

The three channels do not share a standard. This is the part Issuers most often get wrong, because the differences come from three separate sources: data protection law, the messaging provider's contract, and Meta's platform policy.

What follows is what Praximos requires. It is not a statement of what every provider and every jurisdiction require, and it does not displace them: where the local rule or the provider's own rule is stricter, that is the one the Issuer has to meet under section 6.

7.1 Email

An obligation notice sent to a client of the Issuer is a service message about an existing professional relationship rather than direct marketing, and that is the only use of email this product is built for.

This agreement does not decide which lawful basis covers it. Performance of a contract, legitimate interests, and consent are each capable of applying, and which one does depends on the Issuer's own relationship with the Recipient and on the country they are in. Section 6 point 1 is the Issuer's warranty that they hold an appropriate basis and have made the assessment behind it. What is not available is the assumption that no basis is needed because a message is not marketing.

What Praximos requires on top of that is that the Recipient can stop it. Every email carries a way to do so, and a Recipient who uses it is not messaged again by that Issuer on that channel.

Email is also the fallback for every channel strategy. A Recipient who has stopped email and given no other channel cannot be reached at all, and their obligations will not be delivered.

7.2 SMS

Having the Recipient's number is not permission to text them. Section 6 point 2 is necessary and it is not sufficient, and a number sitting in a client file with no record of how it arrived is not a number Praximos may send to.

Before the first SMS to a Recipient, the Issuer must hold the prior express permission required by the Twilio Messaging Policy as it stands at the time, and the permission required by the law applicable to that Recipient, in the form each of them requires. Where the two differ, the stricter is the one to meet. Where either requires the permission to be in writing, to name SMS, to name the Issuer, or to state what the messages will be about, that is what the Issuer must hold before the first message and not after it.

Whatever form the permission takes, the Recipient must have been told all of the following before they gave it. The messaging provider's own verbal consent checklist requires each one, and an earlier revision of this document named only the first two, which left an Issuer warranting under section 6 that they had met a standard this document never stated.

1. Who is asking. The Issuer's name, being the name the messages will carry.
2. What the messages are about. Documents and information the Issuer needs, and the deadlines for them.
3. How often they arrive. One message for each request, then reminders weekly until the last three days before its deadline and daily after that, and in no case more than one text message a day from that Issuer however much is open.
4. That message and data rates may apply.
5. How to get help and how to stop, being the words HELP and STOP, and where the terms of service and the privacy policy are.

Praximos publishes a script carrying all five at /consent-script, in the wording registered with the messaging provider as this product's consent method. An Issuer who reads that script has told the Recipient what this section requires. An Issuer who reads something else is warranting under section 6 that whatever they read did the same job.

The Issuer retains proof of it and produces it under section 11: what was given, by whom, when, through what route, and for which channel. An assertion recorded in Praximos is a record that the Issuer said so, which section 11 explains is not the same thing.

Two further conditions are about content rather than collection.

The message must be about the obligation. The moment an SMS sent through Praximos carries promotion, cross selling, or anything a Recipient did not hand over their number to receive, nothing in section 6 covers it and separate permission for marketing would be needed. Praximos does not generate such content, and an Issuer must not enter it into an obligation's fields.

The message must identify the Issuer. A Recipient who cannot tell who is texting them treats it as spam, and carrier filtering follows for every other Issuer on the same route.

7.3 WhatsApp

WhatsApp is stricter than SMS and the difference is not a formality. Meta requires opt in that is explicit, that names WhatsApp specifically, and that names the business the Recipient will hear from. A Recipient having given the Issuer a phone number does not satisfy it. Neither does an existing client relationship, nor permission to send SMS on the same number, nor anything an Issuer holds under section 7.2.

The opt in must be given before the first business initiated message. Praximos initiates every conversation it sends, so the twenty four hour service window Meta allows for replies never opens, and every message is a template Meta reviewed in advance.

Praximos refuses to send a WhatsApp message to a Contact with no recorded opt in, whatever the account's channel strategy says. That refusal is deliberate and is not a setting.

Meta accepts opt in collected through any channel, provided it is unambiguous. A tick box on the Issuer's own intake form naming WhatsApp and the Issuer, a written reply, or the Recipient's own preferences page described in section 10 all qualify. A pre ticked box does not, and neither does silence.

8. What is prohibited

The Issuer must not use Praximos to send messages to any Recipient in the following circumstances. Each of these is a breach of these terms and, on SMS and WhatsApp, of the downstream policies in section 12.

• The Issuer does not hold everything section 6 warrants, for that Recipient and that channel.
• The address or number came from a purchased list, a scraped source, a public directory, or any third party the Recipient did not direct to pass it on.
• The address or number was given for an unrelated purpose and the message concerns something the Recipient would not connect to it.
• The Recipient has withdrawn permission on that channel, by any route.
• The message content is marketing, promotional, or solicits business, on any channel.
• The message is sent on SMS or WhatsApp in order to obtain permission to send further messages. Section 9 is the rule and the reason for it.
• The Recipient is a person the Issuer has no professional or contractual relationship with.
• The message, or the data the obligation asks for, would be unlawful in the country the Recipient is in or the country the Issuer operates from.

An Issuer who is uncertain whether a particular list satisfies section 6 must not load it. There is no test mode for permission, and section 4 does not create one.

9. Praximos does not solicit permission on SMS or WhatsApp

This is a product rule before it is a term, and it exists because it is a question every Issuer eventually asks: a Contact has a phone number and no email address, so may Praximos text them to ask whether they agree to being texted?

It may not, and the product will not.

The rule is Praximos's own and is stated as such rather than as a claim about the world. A message asking for permission is itself a message. The Twilio Messaging Policy and Meta's policy each require permission before the first message and neither writes an exception for the message that asks, and there are jurisdictions in which the request is treated as exactly the message the law regulates. Praximos does not attempt to state what every provider and every country require. What it states is that this product will not carry such a message in any case, so no Issuer has to work out whether theirs is the exception.

It is also unnecessary. If the Recipient gave the Issuer the number and the Issuer holds what section 7.2 requires, the first SMS can be the obligation notice itself. If they did not, section 8 forbids messaging them at all, and asking permission by SMS does not repair that.

A Contact with a phone number and no email address is therefore messaged directly about their obligation, on the Issuer's recorded assertion, with the Issuer named in the body and a way to stop.

WhatsApp is the one case where permission genuinely must be collected in advance, and it must be collected somewhere other than WhatsApp. The Issuer's own intake, a phone call, or the preferences page.

10. Withdrawal

Every message Praximos sends carries a way to stop receiving them, and the way differs by channel because the channels differ in what they can receive.

Email carries a link. SMS carries a link, and honours the STOP keyword and its local equivalents wherever the sending number can receive inbound messages. WhatsApp honours the block and the stop control Meta provides in the client, and carries a link as well.

The link matters more than it looks. In Greece an alphanumeric sender ID cannot receive inbound messages at all, so STOP can never arrive and the link is the only working route. An Issuer sending SMS from an alphanumeric sender relies on it entirely.

A withdrawal is per channel and per Issuer. A Recipient who stops SMS from one Issuer continues to receive email from that Issuer and continues to receive everything from every other Issuer, because permission was never shared between them in the first place.

A withdrawal takes effect immediately on messages not yet sent. Messages already handed to the provider may still arrive.

Praximos will honour a withdrawal it learns of by any route, including an inbound keyword, a provider side opt out enforced by the messaging provider, and a delivery error indicating the Recipient has blocked the sender. An Issuer must not re enable a channel a Recipient has withdrawn from unless the Recipient asks for it, and the Issuer bears the record of that request.

11. Records and proof

The Issuer keeps the primary record. Praximos records what it can observe: which channel was enabled, on what date, by which account, and by which route, whether the Issuer asserted it or the Recipient granted it on their own preferences page. That record is available to the Issuer at any time and is retained for the life of the contact record.

It exists for the two phone channels, which are the two a permission standard in section 7 applies to. Email has no enablement to record: section 7.1 asks only that the Recipient can stop it, so what is held there is the withdrawal rather than the grant.

What Praximos records is evidence that the Issuer made an assertion. It is not evidence that the assertion was true. Only the Issuer holds that, and section 6 point 5 is the obligation to hold it.

The Issuer retains the underlying evidence for as long as messages to that Recipient continue and for as long afterwards as the limitation period applicable to a claim about those messages requires, and in no case for less than two years after the last message. Retaining it is an obligation of this agreement, not a recommendation, and it is not discharged by the assertion recorded in Praximos.

Where a carrier, the messaging provider, Meta, a supervisory authority, or Techthos asks the Issuer to substantiate a message, the Issuer produces that evidence within five working days, or sooner where the request allows less. Techthos passes on a request it receives rather than answering it, because the answer is not Techthos's to give. An Issuer who does not produce the evidence will have the relevant channel suspended under section 12, and the indemnity in that section covers what follows.

12. Downstream policies and suspension

Praximos sends SMS and WhatsApp through Twilio, and WhatsApp reaches Recipients through Meta's platform. Both impose policies on the party sending, and both hold Praximos responsible for what its Issuers send.

The Issuer is bound by the Twilio Messaging Policy and Acceptable Use Policy, and by the Meta WhatsApp Business Messaging Policy, as those documents stand from time to time, as though the Issuer were a party to them. Those policies change without the agreement of either party to this one, and a change binds the Issuer when it takes effect rather than when this document catches up with it.

Where such a policy is stricter than these terms, it governs. That precedence runs in one direction only: it raises the floor under the Issuer's obligations and is never a licence, and no section of this document may be read as permitting what a provider policy forbids. Where a reader finds this document contradicting itself, the stricter reading is the one that applies, and section 21 is where the contradiction gets fixed rather than argued.

Praximos may suspend a channel, an account, or all sending, immediately and without notice, where it has reason to believe a message was sent without permission, where a carrier or provider requires it, where complaint or filtering rates on an Issuer's traffic threaten delivery for other Issuers, or where an Issuer has not substantiated a message under section 11. Email delivery continues where the breach concerns a phone channel only, so that work already in flight can still resolve.

Suspension for cause is not a refund event.

The Issuer indemnifies Techthos against claims, penalties, and provider charges arising from messages sent on the Issuer's behalf to Recipients for whom the warranties in section 6 were not true, or whose messages breached section 7, section 8, or a policy named in this section.

13. Data protection

The Issuer is the controller for Recipient personal data. Techthos is the processor and acts only on the Issuer's instructions.

This section is the data processing agreement between them, and it is here rather than in a separate file on purpose: a second document is one an Issuer accepts without opening, and two texts that cross reference each other drift apart the first time either is edited alone. It is accepted with the rest of these terms. Where an Issuer's own obligations require a separately signed instrument, Techthos will execute one on these terms.

13.1 Scope of the processing

Subject matter: dispatching obligations to Recipients in the Issuer's name, and collecting what a Recipient submits in answer.

Duration: for as long as the account exists, and afterwards only for the periods in section 13.7.

Nature and purpose: storing contact records; generating and sending messages on the channels the Issuer enables; hosting the page a Recipient submits through; assembling and storing what they submit; delivering it to the Issuer; chasing an unanswered obligation on a schedule; and, where the Issuer asked for it, checking a submission against the Issuer's own stated criteria.

Categories of personal data: the name, email address, phone number, language, timezone and notes held on a Contact; the content of every message sent and its delivery result; the values a Recipient types into an obligation's fields; and the documents a Recipient uploads, whatever those contain.

Categories of data subject: the Issuer's clients, and anyone else the Issuer addresses an obligation to.

13.2 Instructions

Techthos processes Recipient personal data only on the Issuer's documented instructions. The obligations the Issuer creates, the contacts they hold, the schedules they arm, and the settings on the account are those instructions; this section is the rest of them.

Techthos tells the Issuer where an instruction appears to it to infringe applicable data protection law, and may decline or suspend that processing until the point is resolved. Where Union or member state law requires Techthos to process for another purpose, it tells the Issuer before doing so unless that law forbids the telling.

13.3 Confidentiality

Every person Techthos allows to process Recipient personal data is bound by an obligation of confidentiality that survives their engagement, and is given access only to what their task needs.

13.4 Security

Techthos maintains technical and organisational measures appropriate to the risk, as Article 32 of the General Data Protection Regulation requires. They include at least: TLS on every connection to the service, with no plaintext option; passwords and access link tokens stored only as hashes, so the database holds no working credential and no working link; uploaded documents in private storage reachable only through a link that expires; every read of a contact, an obligation or a document scoped to the account that owns it; administrative action recorded against the account it touched; and backups of the database.

That list is a floor rather than an inventory, and the measures change as the product does. The current description is in the privacy policy, which is where it can be corrected without a new version of this agreement.

During alpha the backups are not complete, and section 4 says so plainly rather than leaving it to be discovered. That is a stated limit on the measures rather than an exception to this section, and it is why an alpha instance must not hold anything the Issuer cannot afford to lose.

13.5 Subprocessors

The Issuer authorises Techthos to engage subprocessors. Each is engaged under a written contract imposing obligations no weaker than this section, and Techthos remains liable to the Issuer for their acts and omissions as for its own.

The current list is in the privacy policy rather than here, so that adding or replacing one does not require a new version of this agreement. At the date above it is: the hosting provider; Amazon Web Services, for email delivery; Anthropic, as the model provider that drafts recipient copy and checks a submission against the Issuer's criteria; and Twilio, for SMS and WhatsApp, with Meta beyond it for WhatsApp delivery. Object storage runs inside the deployment itself and is not a third party.

Techthos gives the Issuer notice before a new or replacing subprocessor begins processing. The Issuer may object on reasonable data protection grounds within fourteen days, and where the objection cannot be resolved the Issuer may close the account under section 17.

13.6 Where the data is, and transfers out of the European Union

The database and the documents a Recipient uploads are stored in the European Union. That is the primary storage location, and it is not the whole of the processing, so the exceptions are named rather than left implied.

Two of them concern transit rather than storage. Email is delivered through an Amazon Web Services region in the United States. The model provider processes outside the European Union what section 16 says it receives, which never includes an uploaded file.

The third is the phone channels: Twilio, and Meta beyond it, process a Recipient's phone number and the content of a message on their own infrastructure, which is not confined to the European Union.

Every transfer to a country outside the European Economic Area is made under the European Commission's standard contractual clauses, another safeguard permitted by Article 46, or an adequacy decision covering the recipient. The privacy policy names each recipient, what it receives, and where it processes.

13.7 Deletion and return

Documents a Recipient uploads are deleted thirty days after they are delivered to the Issuer. Praximos is not the archive of record, and the Issuer keeps their own copy.

An obligation and its history are kept for as long as the Issuer's account holds them. An Issuer who deletes an obligation destroys it, and it is not recoverable.

On termination of this agreement, Techthos deletes Recipient personal data within ninety days, except what it must keep to comply with a legal obligation, and except the send records, whose Recipient identifiers are removed and whose counts are retained as the record behind the sending limits. An Issuer who wants their own copy takes it before closing the account; there is no export period afterwards.

An erasure request is answered by stripping identifiers and retaining the record as statistics, with the caveat recorded in the specification that some supervisory authorities do not accept anonymisation as a complete answer to an erasure request. Section 21 records that as open.

13.8 Assisting the Issuer

A Recipient's rights run against the Issuer, and Techthos does not answer a Recipient on the Issuer's behalf. A request that arrives here is passed to the Issuer without undue delay.

Taking into account the nature of the processing and the information available to it, Techthos assists the Issuer by appropriate technical and organisational measures in answering a Recipient's request for access, rectification, erasure, restriction, portability or objection, and in meeting the Issuer's own obligations under Articles 32 to 36 of the General Data Protection Regulation.

13.9 Personal data breach

Techthos notifies the Issuer of a personal data breach affecting Recipient personal data without undue delay after becoming aware of it, and in any event within seventy two hours. The notice says what is known at the time: what happened, which categories of data and roughly how many records are involved, the likely consequences, and the measures taken or proposed.

Notifying a supervisory authority, or the people whose data is involved, is the Issuer's duty as controller. Techthos provides what the Issuer needs in order to do it. Section 19 says what Techthos does about a security defect independently of any of this.

13.10 Audit

Techthos makes available to the Issuer the information needed to demonstrate compliance with this section, and answers a request with that information and with any third party report it holds.

Where that is not enough, the Issuer may audit, or appoint an independent auditor to audit, no more than once in any twelve months, on thirty days' written notice, during working hours, without disrupting the service, under an obligation of confidentiality, and at the Issuer's own cost. A supervisory authority exercising its own powers is subject to none of those limits. Where an audit establishes a material breach of this section, Techthos bears its cost.

13.11 What Techthos does not do

Techthos does not use Recipient contact details for its own purposes, does not market to Recipients, and does not disclose or reuse a Contact held by one Issuer for any other Issuer.

Techthos does not use an Issuer's content, or a Recipient's documents, to train a model, and requires the same of the model provider.

13.12 Survival

This section applies for as long as Techthos processes Recipient personal data, and survives termination of the rest of this agreement until deletion under section 13.7 is complete.

The privacy policy is the fuller account of what is held, for how long, and on what basis. It is a separate document because it is written for two audiences, the Issuer and the Recipient, and only one of them is a party to this agreement.

14. Availability, and the absence of a warranty

Praximos is provided as it is and as it is available. To the fullest extent applicable law permits, Techthos does not warrant that it will be uninterrupted, that it will be free of defects, that a message will be delivered, that a deadline will be enforced, or that it is fit for any particular purpose. No warranty is implied by anything said on the product's own pages, in its documentation, or by an assistant describing what it can do.

There is no service level, no uptime commitment, and no support response time. The support page is the only channel and it is answered by people rather than by a rota.

Techthos may change, suspend, or withdraw any part of the service. During alpha and beta it may do so without notice, which is what section 4 means. Once an instance is stable, Techthos will give reasonable notice of a withdrawal that removes something an Issuer relies on.

Three things Praximos depends on are outside its control, and a failure in any of them is not a failure Techthos can undertake to prevent: the assistant the Issuer connects from, the email and messaging providers that carry the messages, and the Recipient's own mail server or handset.

15. Liability

Nothing in this section excludes or limits liability that cannot lawfully be excluded or limited. That is at least: death or personal injury caused by negligence; fraud or fraudulent misrepresentation; gross negligence; wilful misconduct; liability under Article 82 of the General Data Protection Regulation, including the liability a processor owes a data subject directly; and anything else that applicable mandatory law does not permit to be limited. A Recipient who suffers damage from a breach of Techthos's obligations as a processor may claim directly, and nothing an Issuer accepts here affects that.

Subject to that paragraph, and to the fullest extent applicable law permits:

1. Techthos is not liable for indirect or consequential loss, for loss of profit, for loss of business, contracts or goodwill, for the cost of substitute services, or for loss or corruption of data, however the loss arises.
2. During alpha and beta, where the service is provided free of charge and unfinished, the total aggregate liability of Techthos for all claims arising in any twelve month period is limited to five hundred euro.
3. Once an instance is stable and the Issuer is paying for it, the total aggregate liability of Techthos for all claims arising in any twelve month period is limited to the greater of the fees the Issuer paid in that period and five hundred euro.
4. Where a court finds a limit in this section unenforceable, the other limits stand, and the unenforceable one is read down to what the law does permit rather than struck out entirely.

Point 1 names loss of data separately from the general exclusion, because it is the loss an Issuer of this product is most likely to suffer and the one they are most likely to assume is covered. It is not. The Issuer keeps their own copy of anything that matters, and during alpha the product tells them so above every page.

There is no contractual deadline for bringing a claim. The limitation periods of the applicable law are what apply, and this document does not shorten them.

The Issuer's own liability is not limited by this section where it arises from the indemnity in section 12 or from a breach of section 6, section 7 or section 8.

16. Intellectual property

Techthos owns Praximos, including its software, its interface, its documentation and its name. Nothing in this agreement transfers any of it. The Issuer is granted permission to use the service for as long as this agreement is in force, and nothing more.

The Issuer owns their own content: the obligations they write, the contact records they hold, and the documents their Recipients submit. Techthos processes that content to provide the service and for no other purpose. In particular, Techthos does not use an Issuer's content, or a Recipient's documents, to train a model.

Praximos passes some content to a model provider in order to draft recipient copy and, where the Issuer asked for it, to check a submission against the Issuer's criteria. What that provider receives is the Issuer's own sentence, the title of the request, the requested fields, the deadline, the two names, and, on a validation, the Issuer's prompt with the text the Recipient typed and the filenames of any uploads. It never receives the bytes of an uploaded document. It is named as a subprocessor in section 13.5 and is under an obligation not to train on the content either.

Feedback an Issuer sends about the product may be used freely and without attribution or payment. That is the one exception, and it does not extend to anything the feedback is about.

17. Termination

The Issuer may close their account at any time, from the product or by writing to the support address. Closure ends this agreement.

Techthos may end this agreement on thirty days' notice for any reason, or immediately where the Issuer is in material breach of section 2, section 3, or sections 6 to 13, where a provider requires it, or where the Issuer's use exposes Techthos or another Issuer to legal or delivery risk. Suspension under section 12 is not itself termination and may precede it.

On termination, the account stops sending immediately. Obligations already dispatched are not withdrawn from the Recipients who received them, because a Recipient who was asked for a document is owed either the document request or an explicit withdrawal, and a silently abandoned request is neither. Data is deleted on the schedule in section 13.7, and an Issuer who wants their records must take them before closing the account.

Sections 12, 13, 15, 16, 19 and 22 survive termination.

18. Acceptance

These terms are accepted at registration. Three of them are accepted separately, each in its own tick box, because a term accepted once inside a longer document is not a record of anything.

The first is the confirmation in sections 2 and 3 that the Issuer is opening the account for business or professional purposes and is not acting as a consumer. It is recorded on the account with the date it was given.

The second is section 4, the release phase, while the instance is in alpha or beta. It is recorded with the date and the phase.

The third is the messaging warranty in section 6, which is also re asserted at two points in the product, because a term accepted once at signup is not a record of permission for a contact added eight months later. Those two points are adding or editing a contact with a phone number, where the Issuer states that the number was given by the Recipient and, separately and per channel, whether the Recipient has given SMS permission and whether they have given WhatsApp opt in; and enabling any channel strategy other than email only on an account, which is the point at which phone channels begin to carry traffic.

No assertion in this document is pre ticked, and none can be set by an assistant on the Issuer's behalf without the Issuer's own action.

19. Governing law, and how a dispute is handled

This agreement is governed by Greek law. The courts of Thessaloniki have exclusive jurisdiction, save that Techthos may bring proceedings to protect its intellectual property wherever the infringement occurs.

Choosing Greek law does not displace rules that apply regardless of the choice. Data protection law applies where the processing and the people are, not where this clause points. The same is true of a country's own rules on electronic messaging, of the rules governing the profession the Issuer practises, and of any other mandatory provision of the law of the country the Issuer or the Recipient is in. Section 6 point 7 and section 8 put compliance with all of those on the Issuer, and this section does not soften them.

Praximos is not offered to consumers, per section 2. Where a court nonetheless finds an Issuer to be a consumer, this section does not deprive them of the protection of the mandatory law of the country they live in, nor of the right to bring proceedings there.

Before either party goes to court they will raise the matter in writing to the other and allow thirty days for an answer. This is a step, not a bar: it does not prevent an application for an injunction, and it neither shortens nor extends any limitation period.

A security defect is not a dispute and is not handled through this section. It is reported to the support address, and Techthos will acknowledge it, say what it is doing about it, and notify affected Issuers and, where the law requires it, the supervisory authority and the people whose data is involved. That duty exists independently of this agreement and cannot be waived by it.

20. Changes to these terms

Techthos may change this document. A change is published at the same address under a new date, and the date an Issuer accepted is recorded on their account, so an account carrying an older one is visibly an account that has not accepted this one.

A change that corrects, clarifies, or reflects a change in a provider policy takes effect when it is published.

A material change is one that reduces the Issuer's rights, adds an obligation, changes the fees, or changes how Recipient personal data is processed. It is notified to the Issuer by email to the account address at least thirty days before it takes effect. It then takes effect on the earlier of the Issuer accepting it and the end of that period, and an Issuer who continues to use Praximos after it has taken effect is bound by it. An Issuer who does not want it may close the account before then at no cost, and section 17 applies.

Continued use is not enough for two kinds of change, which require the Issuer's own acceptance rather than their silence: a change to the messaging warranty in section 6 or to the permission standards in section 7, and a change to the data processing terms in section 13. Those are put to the Issuer in the product. Until the Issuer accepts one, it does not bind them, and Techthos may suspend sending on the account rather than send under a term nobody accepted. Section 21 records that the product cannot yet ask a second time.

During alpha and beta this document changes often, and section 4 is why that is safe: nothing is being paid for and nothing is being warranted. Notice of a material change is given in a preview phase all the same.

21. Open items

These are unresolved. The first group is for counsel; the second must be settled before SMS or WhatsApp carries production traffic.

For counsel:

1. This whole document. It has not been reviewed. The caps in section 15, the jurisdiction clause in section 19, and the business only restriction in sections 2 and 3 are the parts a court would read literally and the three most likely to be wrong.
2. The figure in section 15 points 2 and 3. Five hundred euro is a placeholder chosen so that the preview phase carries a cap rather than a total exclusion. It is not a number counsel has approved.
3. Whether the data processing terms in section 13 suffice as a section of these terms or whether a controller will insist on a separately signed instrument, and what the security measures in section 13.4 should say once they are checked against what is actually deployed rather than what is intended.
4. Whether restricting the account to a natural person acting professionally, per section 3, is workable, and what entity accounts would require of the product and of this document.
5. The active acceptance in section 20. The product records an acceptance at registration and has no way to ask an existing Issuer for a second one, so the clause currently describes a mechanism that does not exist.

Before SMS or WhatsApp carries production traffic:

1. Whether Greek EETT pre registration of an alphanumeric sender ID carries conditions that belong in this document. Tracked in deploy/TWILIO.md.
2. What the SMS permission standard in section 7.2 requires in each country the product sends to. It is written to require the stricter of the provider policy and the local rule without stating either, which is defensible and is not a substitute for knowing them.
3. Whether the per contact assertion in section 18 should capture the date and method of the underlying permission itself, as free text. Praximos now records the date the assertion was made and the route it arrived through, which is what section 11 describes. What it still does not hold is when and how the Recipient actually gave the permission, which is the thing a substantiation request asks about, and capturing it would make section 11 meaningfully stronger at the cost of friction on every contact.
4. Whether a Recipient who withdraws from every channel should be anonymised or retained, and how that interacts with the Issuer's own retention obligations as an accountant.
5. Complaint handling, and what happens when a Recipient reports an obligation as spam. Open item 6 in docs/SPEC.md section 16. The support path named in the message footer, whether a confused Recipient contacts the Issuer or Praximos, is open item 7 there.

22. What this document does not do

It does not create a relationship between Praximos and a Recipient. A Recipient's rights run against the Issuer as controller, and Praximos assists the Issuer in answering them under section 13.8. The one exception is the direct processor liability in section 15, which is the law's and not this document's.

It does not replace the Issuer's own privacy notice. Recipients are the Issuer's clients and were told about the Issuer's processing by the Issuer, not by Praximos.

It does not make Praximos the Issuer's compliance function. Whether a message may lawfully be sent, whether the data an obligation asks for may lawfully be collected, and whether either is permitted in the country the Recipient is in are the Issuer's questions. Sections 6 and 8 put them there, and nothing the product does or refuses to do is advice that a given use is lawful.

It is not legal advice and has not been reviewed by counsel. It records what the product actually enforces and what it relies on the Issuer to be truthful about, so that a lawyer can be pointed at the gap between the two.