Privacy notice

Version 1.0 · in force from 3 November 2026

This notice explains what personal data we handle, and why. Three things are easy to confuse, so it tells them apart: our cloud service — your account, your team, your subscription and the content service your deployment fetches from; the platform you install and run yourself, which we do not host and cannot reach; and the third parties either of those talks to. Sections 1 to 11 are about our cloud service — section 11 for people whose data reaches us without their having signed up themselves. Section 12 is about the software you run yourself.

1. Controller and processor

Velnomix Kft.: 2310 Szigetszentmiklós, Arany János utca 5/A, Hungary
Company registration number: 13-09-222866
Contact for data protection: support@dether.net

We are the controller for the processing described in sections 3 to 9: your account, your team and its roster, your team's business details and our checks of them, your subscription, the records of what you accepted, your deployment's configuration, request metering, our application and security logging, and what you write to our support address. We decided that each of those exists and how it works.

There is one exception. The attributes your deployment sends us to evaluate are your data about your own systems. Your deployment decides what to send, we strip the request to the attributes the class declares, we evaluate it in memory and we never write it down. For that we act as a processor, on your instructions and on the terms of the data processing annex to your contract with us — not for any purpose of our own.

That split, and the legal basis given for each row in section 3, is our own assessment of how the law applies to what we built rather than a determination. We describe what we do and where we think it falls.

2. The short version

Your threat models stay on your machine. When your deployment asks us to evaluate an element, it sends that element's configured attributes, stripped to the attributes the class declares, and nothing else: no element name, no model, no diagram, none of the notes and descriptions you write. An attribute value is whatever was typed into it, so one can carry text of your own — we evaluate it in memory and we never write it down, never log it and never store it. The request also carries your sign-in token and your team's identifier, because that is how we know the request is entitled.

No record exists of which class you asked about. We run no access logging at our content edge or at our gateway. What we do keep is one line per request — at most two, because a request that reaches us without naming your team is recorded as such as well — so that we can rate-limit and see that the service works: the environment, which surface was called, whether it succeeded, your team's identifier and a single count, timestamped, kept for 30 days. Which count it is depends on what you called — for an evaluation, how many undeclared attributes we dropped; for a query against our knowledge graph (the reference data your deployment searches and cross-references with), how many keys the query named — and no line carries both. It never carries the class, the attributes, the keys themselves, your account identifier, your token or your IP address. Each attempt to sign in is recorded separately, and those records do carry your IP address. Section 3 lists them all, and section 6 says how long everything is kept.

There is no tracking of any kind. No analytics, no advertising, no third-party scripts, fonts or frames: our pages load nothing from another origin and are served under a policy that lets them talk only to our own sign-in, commerce and content services. The only things stored in your browser are the ones needed to sign you in and to bring you back to the page you asked for, which is why you have never been shown a cookie banner here.

3. What we handle, and why

Data	Why	Legal basis
Account — your email address and whether it is verified, an internal identifier, the sign-in credentials you set (a password, an authenticator app or a passkey, held by our sign-in service), the name Google gives us if you sign in with Google, and which version of the terms you last accepted	To give you an account, sign you in, let your deployment authenticate, and tell you by email when our terms or this notice are going to change	Performance of the contract — Art. 6(1)(b)
Team and membership — the team's name, which you choose, who owns it, each member's role, and who invited them. Each member's email address is shown to the people who administer their team, through their deployment	To let a team hold one subscription, and to let the people who administer that team see who holds its seats	Performance of the contract — Art. 6(1)(b)
Invitations — the email address a team owner asks us to invite, who invited them, and when it expires	To deliver the one invitation the owner asked us to send	Our legitimate interest, and the owner's, in getting that invitation to the person it is addressed to — Art. 6(1)(f)
Subscription — which packages or edition a team holds, subscription state, period dates, and identifiers issued by our payment provider	To bill you and to decide what your deployment is entitled to fetch	Performance of the contract — Art. 6(1)(b)
Business details and the registers' answers — for a team buying from us: the country in which the business is established, its tax number, its name and address, as the register returned them or as you gave them, and what the register said each time it was asked	To keep the evidence that each customer is a business, and where it is established	Legal obligation — Art. 6(1)(c): Article 18 of Council Implementing Regulation (EU) No 282/2011 and the Hungarian VAT Act (Act CXXVII of 2007), under which the VAT treatment of our invoices rests on evidence that each customer is a business and where it is established
The business check and the declarations — who declared that the business is buying for its trade, business or profession, when, and the wording declared; and the email address we write to about the check	To check the business before it buys, tell the person who gave the details the outcome, and keep the record of who declared it	Where the business is a sole trader, performance of the contract with that person — Art. 6(1)(b). Otherwise, and for keeping the record after the purchase, our legitimate interest in selling only to businesses and in being able to show who declared it — Art. 6(1)(f)
Sanctions screening — each screening of the business's name against the European Union's consolidated financial-sanctions list: the list's version and date and the result; and where a person checks a possible match, the clearance or, for a confirmed match, the block on the business's number	To avoid selling to a business subject to European Union sanctions, and to be able to show what we checked and decided	Our legitimate interest in complying with European Union sanctions law and in being able to prove it — Art. 6(1)(f)
A sanctions report — after a confirmed match, our report of it to the competent authority	Because sanctions law requires us to report it	Legal obligation — Art. 6(1)(c)
The European Union's sanctions list — the list as the European Union publishes it, with the names of the people on it	To screen the businesses that buy from us against it	Our legitimate interest in complying with European Union sanctions law — Art. 6(1)(f)
Where invoices are sent — the email address the team's owner signs in with. Your team's invoices are emailed to it, and our payment provider is given it for its receipts and payment emails; if the team changes hands, both move to the new owner. We store no separate billing email. The business's name, address and tax number are collected by us, or taken from the register that issued the number, kept with your team's business details and given to our payment provider and to our invoicing service; your card details are collected by our payment provider on its own page and are not stored by us	To have invoices issued and sent to the person who owns the team	Performance of the contract — Art. 6(1)(b) — where the business is you, as a sole trader. Where the team buys for a company, our and the company's legitimate interest in its invoices and receipts reaching whoever owns the team for it — Art. 6(1)(f)
Invoices — issued in our name by our invoicing service, which reports them to the Hungarian tax authority and keeps them for us as our processor. Each carries the business's name, address and tax number, and we send it by email to the sign-in address of the team's owner. We keep the business details above as VAT evidence	Because Hungarian accounting law requires us to keep them	Legal obligation — Art. 6(1)(c)
Invoice copies — a copy of each invoice we send, as the same document, with its number, date and total, kept in our own systems for the team it was issued to. Like the invoice, it carries the business's name, address and tax number	To give the team's owner the team's invoices, to download from the Billing page at any time	Performance of the contract — Art. 6(1)(b)
Contract records — which version of the terms you accepted and when. Accepting the terms is how our contract is made; it is not a consent you give under data protection law. When our terms change, also a record of the notice we sent you: which version it announced, when we sent it, the address we sent it to, and the identifier our mail service gave the message	To be able to show what you actually agreed to, and that we told you when our terms were changing, if it is ever disputed	Our legitimate interest in establishing and defending legal claims — Art. 6(1)(f)
Contract confirmation — when you buy, a record that we sent you the confirmation of the contract, where we sent it and when — not a copy of the email itself	We keep the record so that we can show we sent it if it is ever disputed	Our legitimate interest in establishing and defending legal claims — Art. 6(1)(f)
Deployment configuration — the client identifier issued to your team, the sign-in return addresses you register, which can carry your machine's host name, and which account registered them	To let your own deployment sign in against our sign-in service	Performance of the contract — Art. 6(1)(b)
Request metering — one line per request, as described in section 2, and at most two where a request does not name your team, kept for 30 days, together with short-lived counters keyed to your team or your account	To rate-limit requests, to keep the service available, to make bulk copying of the catalogue slow and obvious, and to see that the service works	Our legitimate interest in the security and availability of the service — Art. 6(1)(f)
Application and security logging — first, the lines our own services write as they handle a request: what was done, for which team and, for some actions, which account identifier, and whether it worked. They are kept for 30 days. Second, our cloud provider's audit trail, kept for 12 months. It records administrative actions on our own systems, and it also records the requests our sign-in service logs: each step of every sign-in — submitting a password, using a passkey, entering an authenticator code, choosing a second factor, though not the password itself — each exchange of a sign-in for tokens, and account actions such as changing a password or a second factor. Each of those records carries the IP address and browser the request came from and, where the request concerns an account, its internal identifier, so for twelve months the trail holds a history of the sign-ins to every account. Third, sign-in events, recorded by our sign-in service whenever anyone signs up, attempts to sign in to an account, resets or changes a password, or asks for a code to be sent again: your internal identifier and the email address you sign in with, the IP address the attempt came from, the approximate city and country our sign-in service derives from that address, a description of the device, what kind of attempt it was, which challenges were asked for and how each was answered, which application was used, and our sign-in service's own assessment of the attempt — a risk level, a risk decision, and whether the password used appears in a corpus of credentials known to have been breached. Nothing is decided on that assessment. No sign-in is allowed, refused, challenged or made harder because of it, and no other decision about you is taken on it: it is recorded. If it shows that the password used appears in such a corpus, or gives a sign-in a high risk level, we are alerted and may write to you to suggest that you change your password. We keep our own copy of these events for 90 days; our sign-in service separately keeps two years of sign-in history for each account inside its own system, which is its period and not one we set	To operate the service and find the cause of a fault, and so that an account takeover, a change made to an account, or misuse of our systems can be investigated — including a takeover found months after it happened, which is when the old sign-ins matter and why the audit trail is kept for twelve months, and to tell you if the password used on your account appears in a corpus of credentials known to have been breached or a sign-in to it is given a high risk level	Our legitimate interest in running the service and in its security and that of your account — Art. 6(1)(f)
Support correspondence — what you write to support@dether.net and our replies: your email address, your name if you give it, and whatever the messages contain. A request you make under section 7 has a row of its own, below	To answer your questions, and to handle complaints and cancellations	Our legitimate interest in answering the people who write to us, and in being able to show later what was said about a contract or a complaint — Art. 6(1)(f)
Your data-protection requests — a request you make under section 7, the identifiers we use to find your data, when we received the request and when we closed it, and our answer, which for an erasure includes the record of what we deleted and what we kept, and why. They are held in our support mailbox and kept until the end of the fifth calendar year after the request is closed	To answer the requests you make under section 7, and to be able to show that we answered them and how	Legal obligation — Art. 6(1)(c): data protection law requires us to answer these requests and to be able to show that we did

One basis at a time, and why the roster rests on the contract. We decide why the team roster exists — our seat and entitlement model — and what it contains and who receives it, which is what makes us responsible for it. Showing a member to the people who administer their team is part of what joining a team means, so it rests on the contract rather than on our legitimate interests: we could not keep you in a paying team while hiding you from the people who administer the team whose seat you hold, so for the roster the contract is the right basis. An invitation is different: we have no contract with the person invited, who has not joined anything and may never, so the contract cannot be its basis, and that row rests on legitimate interests.

The attributes your deployment sends for evaluation are not in this table, because we do not handle them for our own purposes. Section 1 says what we do with them and on what footing.

Business details, and whose data they are. A company's name, number and address are usually not personal data. Where the business is a sole trader, or its name identifies a person, they are that person's personal data. The identity of the person who gave the declarations, and the email address we write to about the check, are personal data in every case. The business details and the declaration are needed to buy, as a requirement of the contract: without them we cannot sell.

Decisions made automatically. Business details are refused automatically where a register says the number is not valid, or that the business is not one we can sell to; where the number is not in the form its country issues or fails its check digit; and where the number is blocked. A possible sanctions match is never refused automatically: a person decides it, usually within one working day, but meanwhile a paying team's access is paused and nothing is charged for the time it is paused. A number a later check finds no longer valid is taken off the invoices automatically, and no further purchase is accepted. A person reviews any of these decisions on request: write to support@dether.net.

Three kinds of person reach us without an account, or without one yet. If a team owner invites you, we hold your address to deliver that invitation and it expires after seven days — section 11. If you sign in to a deployment somebody else runs, what reaches us is the sign-in itself: we see that you signed in and issue the token your browser carries, and nothing you do inside that platform afterwards. And if your name is typed into an attribute that is sent for evaluation, it reaches us inside that one request, is evaluated in memory and is never written down.

If you are here on an invited evaluation. An evaluation account holds your email address so that you can sign in and use the build you were invited to look at, and, if you have accepted our terms of service, to tell you when they change. It lasts for the evaluation and we delete it when the evaluation ends — unless you have by then become a member of a team with a subscription, in which case your account continues like any other member's. The evaluation itself runs under section 2 of our terms of service.

4. What we deliberately do not handle

The names of your elements and your models, your diagrams, and the descriptions and notes you write in them.
A stored copy of any attribute sent for evaluation, or of any assessment we return.
A record of which class you asked about.
Your card number.
Any behavioural, analytics or advertising data.

The first three are architectural rather than promised: the evaluation request has no field for your model, nothing persists the attributes, and the content service emits no record that names a class. An automated test drives the content service and fails if a record linked to a payload or to a class is emitted at all, and a check at each deployment refuses a content distribution or gateway with access logging switched on.

What we do keep is in section 3: the metering line and the security records. They can show that a request happened and which team made it. They cannot show what it was about.

5. Who else is involved

Amazon Web Services — hosting. Everything we store with it is stored in the Frankfurt region (eu-central-1), and our commerce API terminates in that region rather than at a global edge. Requests to our pages, to our sign-in service and to the content service pass in transit through the provider's content delivery network, whose European and North American edges handle the request — your IP address, your browser, the address you asked for, and for an evaluation the request body. We keep no access log of any of it. The transfer mechanism for all processing by Amazon Web Services, the North American edges included, is the standard contractual clauses incorporated in its data processing addendum, which forms part of our agreement with it; Amazon Web Services publishes its own list of the parties it engages in turn. For the evaluation we carry out as your processor (section 1), Amazon Web Services is our only sub-processor, and it is the one section 9 of our data processing annex refers to.
Stripe — payments and the billing portal. Stripe is a controller for its own purposes and our processor for the payment services it provides to us; our contracting entity is Stripe Payments Europe, Ltd in Ireland, and transfers outside the EU rest on the standard contractual clauses together with Stripe's framework certification. Stripe receives the business details we hold for a team, and the email address the team's owner signs in with, which we keep up to date when the team changes hands; Stripe sends its receipts and payment emails there. The receipt Stripe gives for a payment is not an invoice.
Billingo — invoicing. Billingo Technologies Zrt., in Hungary, is our processor: it issues our invoices in our name, reports each one to the Hungarian tax authority as Hungarian law requires, and keeps them for us. For each invoice it receives the business's name, billing address and tax number. It does not send the invoices and does not receive any email address: we send each invoice ourselves.
The registers that check a business number — each receives what is listed here, and is also the source of what it returns: whether the number is valid and, where it publishes them, the business's name and address and facts such as its VAT registration (Art. 14(2)(f)). VIES, for a business elsewhere in the European Union, receives the number and, when you save the details and whenever we check them again, our own VAT number and, where you typed them, the business's name and address, which it compares with what the member state holds. Norway's Brønnøysund register and the Swiss UID register receive the number. HM Revenue & Customs (Great Britain), the Hungarian tax authority (NAV) and ABN Lookup (Australia) receive the number while our connection to each is switched on.
Checks made by hand — for a business in the United Arab Emirates, Singapore or Canada, and in Great Britain or Hungary while our connection to that register is switched off, a person on our side checks the number on the tax authority's own site, typing in the number and, for Canada, also the business's name and a transaction date. A Québec QST number is not checked with anyone. A number taken as given, in the United States, is sent to no one.
The Hungarian authority responsible for asset freezes — after a confirmed sanctions match, it receives a report.
Where the checks go outside the European Union. Norway is in the European Economic Area, and the European Commission has decided that the United Kingdom and Switzerland protect personal data adequately. Australia, the United Arab Emirates, Singapore and Canada have no adequacy decision that applies, and a check there rests on Article 49(1)(b): for the United Arab Emirates, Singapore and Canada, a person checks the number on the authority's site at the purchase and once a year while you are a customer; for Australia, our system asks ABN Lookup at the purchase and a person checks the number on ABN Lookup's public site once a year.
Email we send — the confirmation of a contract, a notice that our terms or this notice are changing, an invitation a team owner asks us to send, the emails about a business check — its outcome, a delay, and a pause of access while a possible match is checked — and each invoice, with the invoice attached, to the sign-in address of your team's owner, are all sent through Amazon Web Services’ mail service, in the same Frankfurt region (eu-central-1) as the rest of your account data. We send an invoice only to the team's current owner, read when it is sent.
Proton — our support address, support@dether.net, is a mailbox that Proton AG hosts for us in Switzerland. What you write to it, and what we write to you from it, are held there. The European Commission has decided that Switzerland protects personal data adequately, and that decision is what the transfer rests on.
Google — only if you choose to sign in with Google, in which case Google handles that sign-in as its own controller under its own notice.

We do not sell personal data and we do not share it for advertising.

6. How long we keep it

What	In the live system	In backups
Your account	While you have an account, and deleted on request. We also intend to remove an account nobody has signed in to for 24 months and that is not in a paying team — that is a review we carry out by hand, not an automatic deletion; it has not yet run, because no account is that old, and nothing deletes an account on a timer	A deleted record can be restored from the database's point-in-time backup for 7 days, and not after that
Team and membership records	For as long as the team exists, which can be longer than any one member's account and any subscription. Your membership goes when you leave the team, are removed from it, or have your account erased. The team's owner can close the team once its subscription has ended, or if it never had one; closing removes every membership and every pending invitation, all at once, and starts the removal of the team's invoice copies (below). The team's own record — its name, who owned it, when it was closed and its reference at our payment provider — is deleted at the same time, unless the team has a subscription record: then it is kept until that record is deleted, and deleted with it	7 days, as above
The subscription record	While the subscription runs. Once it has finished — ended, and confirmed cancelled or expired by our payment provider, so that nothing more can be billed on it — it is deleted 18 months after the end of its last billing period, or after it was created if it never had one, because a card payment can be disputed for about that long. The deletion is made by our database's expiry sweep, usually within a few days of that date. If the team subscribes again before then, the record is live again and is not deleted	7 days, as above
The business record — the business details, the registers' answers, the checks, the screenings and the declarations	For a team that never bought, 30 days after the last change. For a team that bought, while it is a customer and until the end of the ninth calendar year after the year in which its last billing period ends	7 days, as above
A block on a business's number, after a confirmed sanctions match	Until the end of the ninth calendar year after the year in which the match was confirmed	7 days, as above
The European Union's sanctions list	Each version, ten years after a newer version replaced it	None exists
The daily counters of business checks	2 days	7 days, as above
Deployment configuration	Once your team registers a deployment with us, the registration stays: there is no deregistration route, nothing removes it on a timer, and it can outlive the team it was registered for. Removing one is something we do by hand, on request	7 days, as above
Contract records — the terms you accepted, the record that we sent you the confirmation of the contract, and the record that we told you our terms were changing	As long as your account exists, and deleted with it; they have no period of their own. One exception, when you ask us to erase your account: if you paid us within the previous 18 months, your acceptance of the version of the terms that governed that payment and the record that we sent you the confirmation of that contract are kept until 18 months after that payment and then deleted, because that payment can still be disputed until then — section 7	7 days, as above
An invitation that is not accepted	It expires after 7 days and can no longer be accepted. The record itself is removed when our database's expiry sweep reaches it, usually within a few days after that. If the team is closed first, the invitation is deleted then	7 days, as above
A checkout you started but did not finish	Deleted when the payment page expires, and in any case it counts for nothing after 25 hours. A record still left after that is removed when our database's expiry sweep reaches it	7 days, as above
Attributes sent for evaluation	Not stored, not logged, and never written down. They are evaluated in memory, and the last request a given evaluation process handled stays in that process's memory until it evaluates the same class again or the process ends. Nothing reads it in the meantime and nothing can retrieve it	None exists
The request metering line	30 days	None exists
Application logs	30 days	None exists
Support correspondence	Deleted 12 months after the last message in the thread. Correspondence that bears on a contract or a complaint — a complaint and our reply, a request to cancel or end a contract, a refund or payment dispute, or a reply to a notice that our terms are changing — is kept until the end of the fifth calendar year after the last message. If you ask us to erase your data, these periods are shortened: ordinary correspondence is deleted straight away; all other correspondence about a contract, a complaint from a business included, is kept until 18 months after your last payment to us and then deleted, or deleted straight away if you never paid us or that date has already passed — section 7	We keep none of our own
Your data-protection requests and our answers	Until the end of the fifth calendar year after the request is closed. An erasure request does not shorten this: the erasure request itself, and our record of what we deleted and what we kept, are kept for the same period — section 7	We keep none of our own
Sign-in events	Two periods, and only one of them is ours. Our own copy of these events is kept for 90 days. Separately, our sign-in service keeps two years of sign-in history for each account inside its own system: that period is set by the service and not by us, we cannot shorten it, and there is no way to remove that history on its own rather than with the account it belongs to	None exists
Our cloud provider's audit trail — administrative actions, account actions, and the requests our sign-in service logs, with the IP address and browser each came from	12 months in the archive, so a sign-in history for each account is held for that long; the copy we raise alarms from, 7 days	None exists
The record of a revoke, refund or lapse on a subscription	5 years	None exists
Invoices	8 years, which the Hungarian Accounting Act (Act C of 2000, § 169) requires of us. The originals are ours, kept for us by our invoicing service as our processor — below says what we have and have not established about that period	None in our systems
Our copies of a team's invoices	While the team exists. When the team is closed, they are removed within a few days. None is kept for longer than about eight years after the invoice's date, the period the original is kept for	The copies themselves, none. Their index — each copy's number, date and total — up to 7 days, as above

About invoices. Your invoices are ours: our invoicing service, Billingo, issues them in our name, under our tax number, reports them to the Hungarian tax authority and keeps them for us as our processor. Our payment provider takes the payment and gives a receipt for it, which is not an invoice. We send each invoice by email ourselves, to the sign-in address of the team's owner at the time we send it; if the team changes hands, the invoices that follow go to the new owner. We also keep a copy of each invoice, so that the team's owner can download the team's invoices from the Billing page; the copies belong to the team, so a new owner of the team sees its earlier invoices too. We keep the business record the invoices rest on as VAT evidence, for the period above. The eight-year obligation attaches to the originals, so keeping them for that long is our responsibility, not an arrangement of Billingo's; our copies are not kept for that purpose, and go when the team does. We have not yet established that Billingo will in fact keep the originals for the full eight years, and we would rather say so than imply a period we have not secured. An accounting document has to be kept unaltered, so a field cannot be stripped out of one. We use the invoices for accounting and tax, and the copies to give the team's owner its invoices: not to contact you, not to recognise you if you come back, not for anything else.

A retention period is not a reason to refuse erasure. The periods above are a ceiling on the ordinary course of things, not a shield against a request. Where we keep something after you have asked us to erase it, it is because a legal obligation requires us to, or because the record is genuinely needed for a dispute that exists or is reasonably foreseeable — and that is decided case by case, on the record in question, not by a blanket policy. The standing rules are few, and section 7 sets each one out with its period: the card dispute that can follow a recent payment, which reaches two contract records and our correspondence with you about a contract; and the record of the requests you make of us under section 7.

Backups. When we delete something at your request it goes from the live system straight away, and out of the restore window within seven days. Our copies of invoices are the one exception to "straight away": they are removed within a few days, and the copies themselves are in no backup at all.

An erasure request never reaches the deployment you run yourself. Your models, your backups and your deployment's logs are on your own machine. They are yours, we have no channel into them, and nothing we do here changes them. Section 12.

7. Your rights

Which rights you have depends on why we handle the data, so read this against the basis given for each row in section 3.

A copy of your data, and correction of it — for everything we hold about you, whatever the basis.
Erasure — wherever we are not required to keep the record: your account and sign-in, your team memberships, invitations you sent or received, your contract records, the entitlement your deployment reads, what you wrote to our support address, and our copies of invoices that carry your personal data, in the way the box below explains. It does not reach the invoices the law requires us to keep, or the record of the requests you make under this section, and a team you belonged to — with its subscription — carries on if other members remain.
Portability — for the data we handle to perform the contract: your account, your team membership and your subscription.
Restriction — while we are checking a correction you have asked for or an objection you have made.

Your right to object. Where we rely on our legitimate interests — invitations, request metering and rate limiting, application and security logging, the contract records we keep to defend a claim, support correspondence, and, where a team buys for a company, sending its invoices and our payment provider's emails to the team's owner — you have the right to object at any time, on grounds relating to your particular situation. Tell us, and we will stop, unless we have compelling legitimate grounds that override your interests, rights and freedoms, which we will explain to you, or unless we need the data to establish, exercise or defend a legal claim. You can also ask us how we weighed our interests against yours for any of those uses, and we will tell you. The same right applies to what we keep about a business check on our legitimate interests, as section 3 sets out.

An objection does not reach what we keep because the law requires it: the invoices and the record of your requests under this section. If you object to our keeping what you wrote to our support address about a contract, we refuse only for as long as we would keep it against a request to erase it, which the box below sets out: at most until 18 months after your last payment to us, because a payment can be disputed until then, and then we delete it. If you never paid us, or that date has already passed, we delete it when you object.

Write to support@dether.net. We answer within one month, and will tell you inside that month if a request is complicated enough to need longer. Deletion is done by hand rather than by a button, so tell us plainly what you want removed, and expect us to check who you are before we do it.

What deletion cannot reach, and why we say so up front. If you have ever paid us, the law requires us to keep the invoices for those payments for eight years. They are ours, kept for us by our invoicing service as our processor, and they carry the business's details, which are your personal data where the business is you, as a sole trader. The law that requires accounting documents to be kept overrides the right to erasure for exactly that data — Article 17(3)(b) — and it is not something we can choose to ignore, so an erasure request does not reach the originals. We keep the business record they rest on as VAT evidence.

Our copies of the invoices. The copies we keep for a team's owner are not kept against your request. Where they carry your personal data — the business is you, as a sole trader — we erase them on request: all of them if the team goes, or those up to your request if the team carries on under someone else. A company team's copies usually carry none of your personal data, and they stay with the team's owner. The copies belong to the team, so a new owner of the team sees its earlier invoices. Erased copies are gone within a few days.

If you stop owning a team. When a team you own changes hands — you transfer it, or we transfer it because your account is erased — its invoices, and our payment provider's receipts and payment emails, go to the new owner from then on, and your address is taken off the team's customer record at our payment provider, usually within minutes. Some things stay where they are: the invoices our payment provider finalised before the transfer keep the email address they were finalised with; emails already sent stay in the mailboxes they reached; our payment provider keeps its own history of events; and your card stays on the team if you leave it there — receipts for charges to it then go to the new owner, so remove it before you hand the team over, or ask us to.

Your team's business record. On erasure, the VAT evidence is kept (Article 17(3)(b)), while the identity of the person who gave the declarations and the email address we wrote to about the check are removed; the declarations, the screening records and a block are kept only where they are needed for a legal claim (Article 17(3)(e)).

Your contract records go when your account goes, with one standing exception. They are the terms you accepted, the record that we sent you the confirmation of the contract, and the record that we told you our terms were changing. We keep them while you have an account because they evidence what you agreed to and what you told us, and we rely on our legitimate interest in defending a claim to do so (Article 6(1)(f)). The exception: if you paid us within the 18 months before you ask, your acceptance of the version of the terms that governed that payment and the record that we sent you the confirmation of that contract are kept until 18 months after that payment, because a card payment can be disputed for about that long and those two records are what answer a dispute; then they are deleted. Beyond that, if a claim is live or reasonably foreseeable when you ask us to erase, we may keep the particular record that bears on it. Both are exemptions from erasure that Article 17(3)(e) allows, and we will tell you when we have relied on one.

What you wrote to our support address. Ordinary correspondence is deleted when you ask. All other correspondence about a contract — a complaint from a business, a request to cancel or end a contract, a refund or payment dispute, a reply to a notice that our terms are changing — is kept until 18 months after your last payment to us, the same date and the same reason as the contract records above, and then deleted (Article 17(3)(e)); if you never paid us, or that date has already passed, it is deleted straight away.

Your requests to us under this section. The requests you make, the erasure request itself included, and our answers, including the record of what we deleted and what we kept, are kept for the period in section 6 whether or not you ask us to erase them, because the law requires us to answer them and to be able to show that we did (Article 17(3)(b)).

What runs on its own clock. Some traces of you outlive the deletion and then go by themselves: a restorable backup for seven days, application and metering logs for 30 days, our own copy of your sign-in events for 90 days, our provider's audit trail, with your sign-ins in it, for twelve months, what you wrote to our support address for the periods just above, our copies of invoices for a few days, the two contract records above for up to 18 months after your last payment, a finished subscription record for 18 months after its last billing period, and the record of a revoke, refund or lapse for five years. The two-year sign-in history our sign-in service keeps is held against the account itself, so it is not something we can remove separately from the account. A team's deployment registration belongs to the team rather than to you and survives with it, and the emails we sent you sit in your own mailbox like any other email. We will tell you plainly what remained and why, rather than reporting a deletion that did not fully happen.

8. Complaints

You can raise a complaint with us, and we would rather you did, but you do not have to come to us before going elsewhere. You have the right to complain to a supervisory authority — in Hungary the Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH), 1055 Budapest, Falk Miksa utca 9–11, Hungary — or to the authority where you live or work.

We are established in the European Union, so this notice describes our obligations under European Union data protection law, whoever you are and wherever you buy from.

9. Cookies and local storage

We set no advertising or analytics cookies, and this portal sets no cookies of its own. What is stored in your browser is this:

Your sign-in tokens — held in session storage for the tab you are using, to keep you signed in. When you sign out they are cleared, and we ask our sign-in service to invalidate the refresh token so that it cannot be used again. If that request does not get through — the network fails, or you close the tab first — the token is no longer on your machine but expires on its own schedule rather than at once.
Short-lived sign-in values — the values that make the sign-in exchange secure, the marker that brings you back from setting up a passkey, and a note of the page you were heading for so that we can return you to it. Each is removed as soon as it has been used. The note of the page you were heading for can hold an invitation link, and that one is cleared when you sign out as well. The others are not: if you break off a sign-in, a password reset or a passkey registration part-way, the unused value stays until you close the tab, which is what ends session storage.
Our sign-in service's own cookies — set on our sign-in domain while you sign in, so that its hosted pages recognise a session that is already open. They are the provider's, and how long they last is its arrangement rather than something we set.
Our payment provider's and Google's cookies — set on their own domains if you are sent to the payment pages, or if you choose to sign in with Google. They are theirs, under their own notices, and we cannot read them.

None of this is used to track you, and nothing is stored that is not needed to sign you in or to bring you back to the page you asked for, which is why no consent banner is shown. The platform you run yourself keeps its own browser storage, on your own machine — section 12.

10. Changes

We will update this notice when the service changes. The version is at the top and the date it took effect is in the footer. We do not ask you to accept it — it is information, not an agreement — but we will tell you by email, at the address your account uses, about a change that materially affects you.

11. If you did not sign up yourself

Some of the people whose data we hold never came to us. A team owner gave us their address. This section is for them.

If someone invited you to a team. The controller is Velnomix Kft., at the address in section 1. We hold your email address, together with the identity of the person who invited you, for one purpose: to deliver that one invitation and to let you accept it. Your address came from the team owner, who typed it in; the invitation names them where we have been able to verify their own address. We rely on our legitimate interest, and theirs, in getting the invitation to you — Article 6(1)(f) — because we have no contract with you, so the contract cannot be the basis. The balance is that it is a single message about a team you were asked to join, that we send you nothing else about it, and that you can object: write to support@dether.net and we will delete the invitation. If a team owner invites you again later, that is a new invitation. An invitation that is not accepted expires after seven days: after that it can no longer be accepted by anyone. The record is removed when our database's expiry sweep reaches it, usually within a few days, and until then your address stays on the inviting team's own list of pending invitations. If the team is closed before then, the invitation is deleted at that moment. If you accept it, you have an account, and the rest of this notice describes it.

If you are named on the European Union's sanctions list. We hold the names on the European Union's consolidated financial-sanctions list only to screen the businesses that buy from us against them. We take them from the list the European Union publishes, and keep each version of it for ten years after a newer version replaced it.

12. The software you run yourself

Your subscription buys the cloud content service. The platform itself is open source, and you deploy and run it on your own machine, under your own control. You are the controller for everything that happens inside it. We do not host it, we have no access to it, and there is no channel from our service into it.

What it keeps, it keeps on your machine. Everything you model — your elements, your notes, your assessments, and the record of who wrote and decided what — stays in the directory you installed it into, and so do the copies made by its own backup command. Its configuration holds your team's identifier, the identifiers of the people you allow to sign in, and your machine's host name. None of that is sent to us, and none of it is reachable by us.

What crosses to us, and that is all of it: signing in and our answer about what your subscription entitles you to; the content your deployment fetches — the catalogue of modules, and for each class its configuration form, its guidance and the reference data used to search and cross-reference them; the attributes sent for evaluation and the assessment sent back; and the artifacts your deployment downloads because your subscription entitles it to them. We also answer with your team's roster, which is how the people who administer your team see the addresses of its members.

What it fetches from elsewhere. On every start it fetches our signed index of published modules from GitHub, and on a first start or an update it pulls container images and the embedding model from public registries. Each of those sees the network address your machine connects from. Your installation also uses third-party components that you obtain and run under their own terms; we neither supply nor operate them, and the installation documentation says what they are and how to configure them.

Its logs are more verbose than ours, and they are yours. Your deployment records, for every request, the address it came from, the address asked for and the browser; the start of every query it runs; and, for administrative actions, the identifier and email address of the person who took them. Those logs are on your machine. We never see them, your container engine decides how long they are kept, and how they are handled is your decision to make.