Privacy Policy

1. Who we are

In short: this section says who is answerable for your data — Espinosa Bookkeeping LLC, doing business as LingoDesk — and how to reach us. This lead-in is explanation; the text below it governs.

LingoDesk is a business-management service for freelance translators, operated by Espinosa Bookkeeping LLC, a limited liability company doing business as LingoDesk, located in Las Vegas, Nevada, United States. For the data described in section 2 as ours to answer for, that company is the controller within the meaning of Article 13(1)(a) of the General Data Protection Regulation, and an operator within the meaning of NRS 603A.330.

Who the controller is

Article 13(1)(a) requires the controller's identity, and NRS 603A.340 requires an operator to identify itself in this notice. The controller and operator is Espinosa Bookkeeping LLC, a limited liability company, doing business as LingoDesk. The same identity is published in section 1 of our Terms of Service, and our mailing address is published in the next section. Las Vegas, Nevada appears above because it is why Nevada law governs this notice, and for no other reason.

How to reach us, and what happens when you do

You can write to us by post at LingoDesk, PO Box 335208, North Las Vegas, NV 89033, United States. Email is faster, and both routes reach the same person.

Write to support@lingodesk.net. That address is also our designated request address for the purposes of NRS 603A.345, through which a Nevada consumer may submit a verified request. The statutory response deadline, and the extension the statute permits, are set out once in section 8 rather than twice on one page.

Whatever the deadline available to us, we answer within 30 days.Article 12(3) allows a controller one month from receipt of a request — "without undue delay and in any event within one month" — extendable by two further months for complex or numerous requests. We do not take the extension, and 30 days is shorter than a calendar month in seven months of the year, so this is a commitment slightly tighter than the Regulation requires rather than a restatement of it. Requests are handled by hand, by one person; section 7 says so plainly rather than implying an automated pipeline that does not exist.

NRS 603A.345 also prohibits selling the covered information of a consumer who has opted out. We do not sell personal information at all, to anyone, for monetary consideration or otherwise. The obligation to publish a request address does not depend on selling, which is why the address above is published regardless.

No data protection officer

We have not designated a data protection officer, and we are saying so rather than leaving the heading out — an omission reads as an oversight. Article 37 requires a designation where processing is carried out by a public authority, where core activities require regular and systematic monitoring of data subjects on a large scale, or where core activities consist of large-scale processing of special categories of data. None of the three applies at this scale. Questions that would go to a DPO go to the address above.

2. The two roles

In short: two different sets of people's data run through one product, and we are answerable for them in two different ways. Everything after this section depends on which of the two blocks below your question falls under.

Getting this the wrong way round is the error a reader who works with these documents professionally spots first, so we have put it in the first screen rather than the last.

We do not use your clients' data for our own purposes. No aggregate benchmarking, no cross-customer insights, no training of machine-learning models, no enrichment, no resale. Article 28(10) is why that sentence matters rather than being a courtesy: a processor that "infringes this Regulation by determining the purposes and means of processing … shall be considered to be a controller in respect of that processing". The breach limb is part of the provision and we are quoting it rather than dropping it, because it is what makes the consequence a penalty rather than a relabelling. As at the effective date of this notice, that statement is verifiable in the product itself — there is no profiling, scoring, benchmarking or model-training code in it. We are making the commitment while it is still a description of what the software does.

3. What we collect

In short: we hold your account and business details because you asked us to run your invoicing, and we hold your client and project records because you typed them in. The two lists below follow the two roles in the section above.

Data we hold about visitors, before there is any account

• Page views on the public site. Since 3 September 2026 our own server records which public page was viewed, the language it was served in, and the host that linked you here — "reddit.com", never the full referring URL, because somebody else's URL can carry their own search terms. It also records a same-day-only fingerprint so that forty pages read by one person can be told apart from one page read by forty people. That value is a keyed hash of your IP address and browser, the key is random per server process and replaced every day, and the key is never written down — so the value cannot be traced to you, cannot be linked across days, and cannot be reversed by us either. Your IP address and browser are used to compute it and then discarded; neither is stored. That is the whole of it: no cookie, no account link, and nothing written to your device.

Data we hold as controller — about you

• Account and authentication data. Your email address, a hash of your password (never the password itself), a security stamp, an optional phone number, whether two-factor authentication is enabled, whether your email is confirmed, and failed-sign-in counters used for lockout.
• Business profile. Your full name, business name, account type, postal address, tax identifier, logo location, home currency, timezone, invoice and credit-note numbering, calendar-feed token and preferred language — and your bank details: bank name, account name, account number, routing number, SWIFT code and IBAN. We are naming them because they are the most sensitive fields in the product, and a disclosure that hides its most sensitive field is not a disclosure. They are there because your invoices have to carry them for your clients to pay you.
• Subscription records. The customer and subscription identifiers issued by our payment provider, the plan name, the status and the current period end. No card number, security code or expiry date is ever stored on LingoDesk servers — card details are entered with our payment provider and we never receive them.
• Email delivery log. For each message the product sends on your behalf: the recipient address, the subject, delivery status, timestamps, the provider's response identifier and any error — and the full rendered body of the message. For an invoice that body contains your bank details together with your client's name and address, which makes this the widest-reaching single field we store. See section 7 for what that means for retention.

Data we hold as processor — about your clients, entered by you

• Clients. Name, contact name, client type, email, phone, postal address, tax identifier, VAT number, preferred currency, payment terms, status and invoice language. A client recorded as an individual is a natural person, and their details are personal data.
• Projects. Name, language pair, specialisation, CAT tool, delivery format, purchase-order number, deadline, rush flag, rates and word counts.
• Invoices, credit notes and their line items. Numbers, dates, amounts, tax, currency and exchange rate, payment terms and reverse-charge status.
• Payments. Amount, date, method and reference.
• Your rate cards and per-client rates. Not personal data, but commercially confidential to you, and treated as such.
• Free-text notes on clients, projects, invoices, credit notes and payments. We do not inspect, index or classify free-text fields. They can hold anything you type, up to and including sensitive personal data about a client, and you are the controller who decides what goes in them.

This list doubles as the categories of covered information required by NRS 603A.340(1)(a). Nevada requires categories; we have listed fields instead, because Article 13 is the stricter standard and this notice is written once to the stricter of the two. NRS 603A.320 defines covered information to include a name, a physical address, an email address and a telephone number, all of which are in the first list.

4. Why we process it, and on what legal basis

In short: each thing we do with your data has its own reason and its own legal basis, and they are set out one per row rather than bundled into a single sentence about our business interests.

Article 13(1)(c) requires the purposes of processing as well as the legal basis for each, and Article 13(1)(d) requires that where we rely on legitimate interests we say which interests. A single blanket line does not discharge either. The bases are those in Article 6(1).

One row is a judgement rather than a citation, and we are marking it. The legitimate-interests basis for the email delivery log is our assessment, not a settled question. Necessity under Article 6(1)(f) is judged against the retention period, and that log currently has no retention window at all — which weakens the basis rather than supporting it. We have recorded it as an open item instead of writing it up as though it were resolved.

We rely on consent for exactly one thing, and Google Analytics is it. Not "analytics" — Google analytics. We also count page views on our own server, and that runs on legitimate interests rather than consent for the reasons in the row above and the section below. There is still no marketing email and no advertising here, but since 3 September 2026 there is one analytics provider — Google Analytics — and it runs on Article 6(1)(a) consent and on nothing else. Everything else in this notice rests on contract or legitimate interests, as the table above sets out. Nothing loads and no request reaches Google unless you say yes. That changes what this paragraph used to say: the right to withdraw consent under Article 13(2)(c) — which attaches only where Article 6(1)(a) consent is the basis — now has something to attach to, and withdrawal has to be as easy as giving it was, so section 9 carries a control that turns it off again in one click. Consent under the ePrivacy Directive is a separate question about your device rather than about a legal basis, and section 9 answers it row by row, including the one row where our answer changed.

5. Who receives it

In short: four companies other than us touch this data, they are named individually below rather than described as categories, and each row says what that company actually receives. The fourth only receives anything if you accepted analytics, and never receives anything at all from inside your account. Our own page-view counting has no recipient on this list because it has no recipient at all — it never leaves our server.

Stripe is not simply "our payment processor". It processes some data on our behalf, and it processes other data as a controller in its own right — for fraud prevention, anti-money-laundering and know-your-customer obligations, sanctions and trade-control screening, and its own compliance duties. For that second category Stripe determines the purposes and means itself, and its privacy notice governs, not this one. Describing it only as a processor would understate what happens to your data.

Email delivery is switched on. Resend receives the recipient address, the subject and the full rendered body of each message the product sends — for an invoice, that body includes your business details and your client's name and address. Every send is recorded, with its outcome, in the delivery log described in section 3.

Resend engages its own sub-processors, and we link their published list rather than transcribing it. That is deliberate: a copy on this page would be out of date the moment they change it. Reading their list is not how you exercise a right, though, and an earlier version of this paragraph said it was.Article 28(2) puts the duty on us, not on them — where you have given general written authorisation we must "inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object". The mechanism that discharges that is ours, and it is set out as an operative term in section 14(d) of our Terms of Service: at least 30 days' notice by email, objection by reply, and termination without penalty if we cannot accommodate it. Their list is third-tier transparency on top of that — read it before relying on the feature, because it names companies further down the chain that we do not choose. As at the effective date of this notice it carries 22 entries, every one of them marked as located in the United States.

Those three are the complete list. We also disclose data where we are legally compelled to, and we would tell you unless we were prohibited from doing so. Nobody else receives it: we do not sell it, we do not share it for advertising, and there is no analytics provider, no advertising network and no data broker anywhere in this product.

6. International transfers

In short: we are based in the United States, so if you are in Europe your data crosses a border. This section says which of those crossings is already covered by paperwork and which is not, rather than implying all of them are.

Article 13(1)(f) requires us to say whether your data goes to a country outside the EEA and what safeguard applies. There are four legs, and they have four different answers.

• To Stripe — covered. Stripe's data processing agreement incorporates a Data Transfers Addendum referencing the EEA standard contractual clauses (Modules 1 and 2 of Implementing Decision (EU) 2021/914) and the UK International Data Transfer Addendum — the Information Commissioner's addendum to those clauses, which is a different instrument from the UK's stand-alone transfer agreement and was named as the wrong one here until this notice was audited. That DPA "is subject to and forms part of" the Stripe Services Agreement, so it needs no separate signature. This leg needed nothing further from us and has nothing outstanding.
• To Resend — a transfer to the United States on every email sent, and it stays one regardless of where our hosting sits: every sub-processor on their published list is US-located. We cannot honestly offer "everything stays in Europe" under any configuration, so we are not going to imply it.
• To Google — a transfer to the United States, and the only one you control. If you accept analytics, your IP address reaches Google in the United States; if you decline or never answer, this leg does not exist, because no request is made. We rely on Google's processor terms, which incorporate the EEA standard contractual clauses. This is the one transfer on this page that happens only because you said it could, and the one you can switch off yourself in section 9.
• To MochaHost — unresolved, and we are not guessing. The region is a setting on our hosting control panel that we have not yet read. Until we have, we cannot tell you whether this leg is a transfer out of the EEA at all. It is an open item at the foot of this page.

What we are not claiming. We have not executed standard contractual clauses of our own under Article 46 for the legs that would need them, and we are not going to write that we have. Formalising a transfer mechanism, appointing a representative in the Union and executing a data-processing agreement are gated on a specific event — the first paid subscription taken from a customer resident in the EU — and they are recorded as open items with that trigger, so it is something we notice rather than something we remember. What this section describes is what actually happens today.

7. How long we keep it

In short: two things are deleted automatically — one by us and one by Google — and everything else is kept until you ask us to remove it. This is the section where a privacy notice is most tempting to write vaguely, so it is written as the code actually behaves.

Sign-in tokens. The tokens that keep you signed in are deleted 30 days after they expire or are revoked, by a job that runs every 24 hours. That is the only automated deletion in the product, and we would rather say so than let it stand in for a retention schedule.

Page views are deleted after 400 days, by a job that runs every 24 hours. That window exists so one season can be compared with the same season a year earlier, which is the longest question this data is ever asked. It is stated as a period rather than as a criterion because there is a sweep behind it, written in the same change as this sentence — a published period with nothing enforcing it is precisely the failure recorded further down this section about the email delivery log.

Analytics data expires after 14 months, and that one is deleted by Google rather than by us. If you accepted analytics, the event and user data Google holds for this site is set to the 14-month retention window — not the 2-month default, and not the indefinite retention that is not on offer at any price. It is the longest period Google allows on this plan, chosen so a year-on-year comparison is possible at all, and it is the shortest thing on this page we would call a genuine retention schedule. Declining, or withdrawing consent in section 9, stops anything further being added to it; what was already sent runs out its window and is then removed by Google.

Everything else is retained for the life of the account. There is no automated deletion of your profile, your clients, your projects, your invoices, your credit notes, your payments or your notes, and there is no self-service delete-my-account button in the product. Article 13(2)(a) is the provision that makes this section compulsory: it requires "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period", and "the life of the account" is the criterion rather than a period. We are not going to describe a retention schedule we have not built; Article 5(1)(e) is the separate principle of storage limitation, and this is an honest account of where we currently stand against it rather than a claim of compliance with it.

Erasure and export are handled by hand. Write to support@lingodesk.net and we will delete or export your data within 30 days — inside, and slightly tighter than, the one month Article 12(3) allows. It is a manual process carried out by one person, and describing it as one is the point: an automated mechanism we do not have would be a better-sounding sentence and a false one. Building a self-service path is an open item, triggered by the first request that arrives or by the first EU customer, whichever comes first.

The email delivery log has no retention window yet. Email is switched on, so the table storing the full rendered body of every message is now filling, and it grows without bound until a period is set. That gap is exactly what weakens the legitimate-interests basis in section 4. It is an open item whose trigger has arrived, which moves it to the front of the queue.

Data held on your instructions as your processor — your clients, projects and invoices — follows the same position, and what we owe you when you stop using the service is set out in the data-processing terms in our Terms of Service under Article 28(3)(g).

8. Your rights

In short: you can ask for a copy of your data, for it to be corrected, deleted or sent somewhere else, and you ask by writing to one address. Every request is handled by a person, by hand. Nevada and California each add something, and both are answered below. This lead-in is explanation; the text below it governs.

Your rights under the GDPR

Article 13(2)(b) requires us to tell you which rights you hold over the data section 2 describes as ours to answer for:

• Access — a copy of the personal data we hold about you (Article 15).
• Rectification — correction of anything inaccurate and completion of anything incomplete (Article 16).
• Erasure — deletion where one of the grounds in Article 17 applies.
• Restriction — processing paused rather than deleted while a dispute about accuracy or lawfulness is resolved (Article 18).
• Portability — the data you gave us, in a structured, commonly used, machine-readable form (Article 20).
• Objection — to the two operations in section 4 that rest on legitimate interests (Article 21). Nothing here is direct marketing, so that limb has nothing to attach to.
• Withdrawing consent does not arise (Article 13(2)(c)): as section 4 says, we rely on consent for nothing.

How you exercise them, exactly. Write to support@lingodesk.net. There is no self-service export, download or delete-my-account button in the product, and we are not going to describe one. Each request is a manual process carried out by one person, answered within 30 days — Article 12(3) allows one month, extendable by two further months where a request is complex or numerous, and we commit to the shorter period and do not take the extension.

You can complain to a supervisory authority (Article 13(2)(d)), and you do not have to come to us first. Article 77 gives you the right to complain to a supervisory authority, "in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement" — those three are named examples rather than an exhaustive list, and this page said they were the test until it was audited. We have no establishment in the Union, so there is no lead authority to route you to: your own national authority is the one to write to.

Whether you have to give us this data (Article 13(2)(e)): no statute requires it, but it is a contractual requirement. An email address and a password are what an account is, and the business profile is what an invoice is rendered from. Without them we cannot open an account or produce your documents. That is the whole consequence.

If you are in Nevada: the designated request address

NRS 603A.345(1) requires every operator to establish a designated request address. Ours is support@lingodesk.net, labelled as such here rather than left for you to infer that the support address doubles as the statutory one. NRS 603A.325 defines the term as an email address, toll-free number or website through which a consumer may submit a verified request. Through it you may direct us not to sell covered information about you. We must respond within 60 days, extendable once by up to a further 30 days where that is reasonably necessary and we tell you we are taking it; in practice we work to the 30 days above.

We do not sell covered information. The statutory definition is narrower than the ordinary word: NRS 603A.333 makes a sale the exchange of covered information for monetary consideration so that the buyer may license or sell it on, and expressly excludes disclosure to someone who processes it on our behalf. The three recipients in section 5 are that excluded kind. The duty to publish this address does not depend on selling anything — subsection 1 is unconditional — which is why it is published even though the answer to the question behind it is no.

Reviewing and requesting changes to your information

NRS 603A.340(1)(b) requires a description of the process, if any such process exists, for a consumer to review and request changes to their covered information. The real one has two halves:

• In the product, by yourself. Your business profile — name, business name, postal address, tax identifier, bank details, currency, timezone and language — is editable under Settings. Client, project, invoice and rate-card records you entered are editable and deletable by you there too, because you are their controller.
• Credit notes and payments can be created in the product but not amended or deleted in it. We are correcting that here: an earlier version of this section listed them alongside the records above, and the product has no route to change them once recorded. They are financial records that reference an invoice, and altering one is something we do by hand so that the invoice it points at stays consistent. Write to us and we will do it.
• By writing to us. Everything else, including the email address your account is registered under, which cannot be changed in the product today. We do it by hand, within 30 days.

If you are in California

The California Consumer Privacy Act does not currently apply to us. Saying so with the numbers attached is more useful to you than a boilerplate CCPA block that would misdescribe our position. Cal. Civ. Code §1798.140(d)(1) covers a for-profit business doing business in California that meets at least one of three thresholds. We meet none, and each is countable:

• $26,625,000 in annual gross revenue in the preceding year. The statute says $25,000,000 as adjusted for inflation; the figure the regulator publishes is $26.625 million, effective 1 January 2025. It counts global revenue, not California revenue.
• Buying, selling or sharing the personal information of 100,000 or more California consumers or households a year.
• Deriving 50% or more of annual revenue from selling or sharing personal information. We derive none of it that way, because we do not sell or share personal information at all.

What would reopen it, and note that two of the three are not about size. Selling or sharing personal information could satisfy the third threshold at any revenue, and 100,000 California consumers is a headcount rather than a turnover. Separately, the regulations the California Privacy Protection Agency finalised on 23 September 2025 take effect on 1 January 2026 and attach specific duties around risk assessments, cybersecurity audits and automated decision-making technology to businesses that are covered. So introducing analytics, advertising, profiling or automated decision-making would change the position from both directions at once. We do none of them today — section 9 and section 10 — and this paragraph is the trigger to ask the question again if that ever stops being true.

9. Cookies and local storage

In short: up to nine things can end up on your device and they are all listed by name below. Five of them are your session or your account. One is your language, which we now write only if you pick one yourself — and the last part of this section explains why that row is closer to exempt than this notice used to say, and where it still falls short. One records your answer to the analytics question, whichever way you answer it. The final two are set by Google rather than by us, and exist only if you accepted. This lead-in is explanation; the text below it governs.

The rule that applies is not a cookie rule. Article 5(3) of the ePrivacy Directive governs storing or gaining access to any information on your device, not cookies specifically, and the European Data Protection Board's guidelines on its technical scope confirm it reaches local storage, pixels, tracking links and fingerprinting alike. Browser local storage is in scope exactly as a cookie is. A page that says "we don't use cookies" and stays quiet about local storage is wrong in law, not merely incomplete — so here is all of it.

Both cookies are HttpOnly, which is the point of them being cookies. JavaScript running in the page cannot read either one — not ours, and not anything injected into the page — which is why the session lives there and not in local storage. They are also marked Secure and SameSite=Strict in production, and scoped by path to /api and /api/auth, so they are not sent with a request for a page, an image or a font. The four local-storage entries are ordinary readable values, which is exactly why none of them is a credential.

This site loads no third-party code until you allow it, and then it loads exactly one. Our fonts are served from our own domain rather than a font network, and there is no tag manager, no advertising pixel and no session recorder anywhere on it. Since 3 September 2026 there is one analytics provider, Google Analytics, and it is gated in the strict sense: if you have not answered, or you declined, gtag.js is never downloaded and no request of any kind reaches Google. We deliberately did not implement Google Consent Mode, which is the common way to do this — it loads Google's script anyway and pings Google with a "denied" signal. That is still a request to a US company made by someone who said no, so we refused it and gated the script itself. The links in this document point at the instruments we cite, but a link is not a request: nothing is fetched from another company until you choose to click one. A visitor who never signs in, never picks a language and never accepts receives exactly one entry — ld_analytics_consent, once they answer the banner — and nothing else at all. Measured on the built site, not asserted: with an answer given and nothing else touched, that key is the only thing in local storage and there is no cookie.

Nevada's answer changed on 3 September 2026, and it changed from a structural no to a conditional one.NRS 603A.340(1)(d) requires us to say whether a third party collects information about your activity over time and across other websites. Both halves have to be true for it to bite, and now exactly one of them is. Over time on this site: yes, if you accepted — the two-year _ga cookie above is precisely how. Across other websites: no — _ga is first-party and scoped to lingodesk.net, no other site can read it, and Google Signals is switched off in our configuration, which is the setting that would otherwise join what you do here to your activity elsewhere through a signed-in Google account. So our answer is still no, but it is now a no that rests on a setting we have to keep switched off rather than on there being no third party at all. If Google Signals is ever switched on, this paragraph is the first one that has to change. It also remains the one question on this page you can check without believing us — open your browser's developer tools and watch what this site requests before you answer the banner, and after.

There is now a consent banner, and it asks about one row and no others. Consent under Article 5(3) is required for storage that is not strictly necessary for the service you explicitly requested. The two session cookies, ld_token_expires, ld_user_email and ld_onboarding_complete all exist to keep you signed in and to run the account you asked us to open, and they are exempt on that ground. We do not ask you about any of them. A banner asking your permission for those is not compliance; it is a dark pattern with a checkbox, and it trains people to click through the ones that matter. The banner asks about analytics, its Accept and Decline are the same size and the same weight — an unequal pair is the design the EDPB's cookie banner taskforce treats as invalidating the consent it collects — and it never appears once you are signed in, because analytics does not run there.

The banner governs Google, and it does not govern our own counting. We would rather write that plainly than let you find it out. Since 3 September 2026 our own server also counts views of these public pages, and declining above does not switch that off — because the two are not the same act. One hands a company in another country a durable identifier for your browser, which is why it needs your permission and why nothing is sent until you give it. The other increments a number on the server that just sent you this page, stores nothing at all on your device, keeps no IP address, no browser string and no identifier that survives the day, and is shared with nobody. That is why the count of entries at the top of this section did not change when it was switched on: it adds none. Section 3 lists exactly what it records and section 4 gives its basis. Presenting a choice about Google as though it governed both would be the more dishonest design, not the less — and if you would rather we did not count you at all, say so and we will exclude you.

You can change your answer here, now, without leaving this page.Article 7(3) requires withdrawing consent to be as easy as giving it, and a notice that tells you to go and delete a key from your browser's developer tools does not meet that standard. This control is the same one decision, readable and reversible as often as you like. It shows what this browser currently says:

Turning it off deletes nothing that Google has already received — it stops anything further being sent, and it is why we keep the accepted window short by retaining event data for 14 months rather than indefinitely. This choice is stored per browser, because it is stored in your browser: answering on your laptop does not answer for your phone. That is a consequence of not tracking you across devices, which is the same reason we cannot do it for you.

The ld_language row does not meet the exemption it was relying on, and we found that out by reading the source instead of a summary of it. Until this notice was audited, this section said ld_language sat in a well-established exempt category and that only its application was arguable. The category is the "UI customization" one in the Article 29 Working Party's Opinion 04/2012 on the cookie consent exemption, §3.6 — and read directly, it sets two conditions that ld_language fails:

• Such preferences are "only set if the user has explicitly requested the service to remember a certain piece of information, for example, by clicking on a button or ticking a box". ld_language now satisfies this one. It is written only when you click a language in the switcher or set one in your profile, which is the "clicking on a button" the Opinion describes; a page load writes nothing. That was not true when this section was first published, and saying so is the correction rather than the boast — the code changed for an unrelated reason and this notice went on describing the old behaviour until it was measured against the built site.
• "Only session (or short term) cookies storing such information are exempted", because the user's intention "could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours)". The same Opinion adds that an exempt entry "must be set to expire once it is not needed". ld_language has no expiry at all.

So the honest position is that this row now fails on one condition instead of two, and one failure is still a failure. The expiry point above is unfixed: the entry has no lifetime at all, and the Opinion is explicit that an exempt entry "must be set to expire once it is not needed". It is in scope in the first place because Article 5(3) covers the act of storing information on your device whatever the medium, which is what the European Data Protection Board's guidelines confirm at §§35–38 and §44. The Opinion is guidance from 2012 rather than binding law, and it is guidance we are reading against ourselves. The fix is not a banner, which would ask you to approve something you get no benefit from being asked about; it is to bring the key inside the criteria. That fix had two halves — write it only on an explicit choice, and bound its lifetime — and the first half is now done. The remaining half is an open item at the foot of this page, and this is still the row on this table we would tell a regulator about before they asked.

10. Automated decision-making

In short: none. Not "none that affects you", not "none currently planned" — there is no profiling or scoring code in the product at all.

Article 13(2)(f) requires us to tell you about automated decision-making, including profiling, within the meaning of Article 22. There is none. We do not profile you, score you, rank you, segment you or make any decision about you by automated means. As at the effective date of this notice that is a statement about the software rather than a policy position: no profiling, scoring, ranking or model-training code exists in it.

Two things in the product are algorithmic, and neither is a decision about a person. An invoice calculator works out line totals, tax and currency conversion from the numbers you entered, deterministically — the same inputs always give the same output, and you can check the arithmetic. A rate suggestion offers a figure you previously used for similar work, which you accept or overwrite. Neither produces a legal effect or anything similarly significant for anyone, so neither engages Article 22.

The same absence is what lets section 9 answer NRS 603A.340(1)(d) with a verifiable no, and what keeps the California position in section 8 closed. If any of this changes, all three paragraphs change with it, and the changelog below will say so.

11. Changes to this notice

In short: if we change something that matters, we email you, we log it at the foot of this page with its date, and we tell you before we start doing anything new with your data, not after.

NRS 603A.340(1)(c) requires us to describe the process by which we notify you of material changes to this notice. It is this: we email every account holder at the address on their account, we add a dated row to the changelog in section 12, and we update the effective date at the top of the page. Minor corrections — a broken link, a clearer sentence — get a changelog row without an email.

Email delivery is switched on, through the provider described in section 5, and every send is recorded with its outcome in the log described in section 3. The email is how you hear about a material change; the changelog remains the permanent record.

Separately, Article 13(3) requires more than a changelog. If we ever intend to process your personal data for a purpose other than the ones set out in section 4, we will tell you that purpose and its legal basis, together with the rest of the Article 13(2) information, before the new processing starts. A new purpose is not a change we can make by quietly editing this page.

12. Effective date and changelog

In short: this notice takes effect on 17 August 2026, it was last changed on 3 September 2026, and every change to it gets a dated line in the table below. There are two entries for 3 September because two different things shipped that day.

The effective date of this notice is 17 August 2026; it was last updated on 3 September 2026. NRS 603A.340(1)(e) requires the date to be stated, and it is stated here as well as at the top of the page so that it is the first thing and the last thing you read.

These pages are structurally complete and pending professional review before the first payment is taken. Everything above is written from the code as it actually is, with a citation on every claim of law, and nothing on it has been reviewed by a qualified lawyer. We are telling you that rather than letting the format imply otherwise.

13. Open items: what still needs a lawyer

In short: this is the list of everything we could not settle, what our best answer is on each one anyway, and the specific event that would force us to settle it properly. It is not flattering and it is not meant to be. This lead-in is explanation; the text below it governs.

These two documents were written from primary sources — the Regulation, the Nevada Revised Statutes, the United States Code, the California codes and the vendors' own published terms — and then read a second time, in a separate sitting, against those same sources to check that each citation supports the sentence it is attached to. They were not written or reviewed by a lawyer, because the business cannot yet afford one. Everything below is either resolved with a source, or named here as open. Nothing uncertain was guessed. Where that second reading found a claim we could not trace, the claim was corrected or removed rather than reworded into something vaguer; several sentences on these pages now say plainly that an earlier version of them was wrong.

These pages are structurally complete and pending professional review before the first payment is taken. That is the honest description of where they stand: every disclosure the law we could find requires is present and answered, and none of it has been checked by anyone qualified to check it.

Settled, with the source and the event that would reopen it

Open, and needing professional review

Three of these share one trigger, and it is a condition rather than a date, so that it is something we notice rather than something we remember: the first paid signup from an EU-resident data subject.

Nothing on this page is legal advice, and this register is not a substitute for a lawyer reading these documents. It is what we can honestly offer instead of one: a full account of what we checked, what we could not check, and what would make us go and check it.