Privacy Policy

0. What's actually live today

A Privacy Policy that describes data collection in the present tense for features that don't exist yet would be misleading. So, plainly, here's what's actually live as of this Policy's last-updated date:

Live today, no account required:

• The zero-signup demo — five public-domain classic games, played solo against a bot or with friends via a share link.
• Anonymous draft storage — you can save a game you're designing and get back a private link that lets you read, edit, or delete it. There's no account attached; the link itself is the only key. Drafts that go unused for 30 days are automatically deleted.
• AI rule generation — you can turn a typed game description into a playable game definition. This sends your description to Anthropic's API (see §4.1). Anonymous visitors get one free generation; continuing past that requires an account. Enforcing that one-free cap briefly processes a hashed form of your IP address — see §2.7.
• Recovery email — you can attach an email address to a draft link you hold, confirmed by clicking a link we email you, and later ask us to resend your draft links if you lose them.

Live today, with an account — login is a passwordless magic link emailed to you; no password is ever set or stored:

• Accounts and login. Creating an account and signing in, kept active by session cookies (see §3). What we hold per account is listed in §2.7.
• AI Credits. A Free account is granted Credits, and AI generation deducts them per action (a failed generation is automatically refunded).
• Checkout — sandbox/test mode only. The Paddle checkout and subscription flow is built and running against Paddle's sandbox environment. No real payment has ever been processed — real charging is switched off behind a separate, deliberate flag — so no billing data for a real paying customer exists yet, although a test/sandbox billing record can now exist (see §2.5).

Built and tested, but not yet turned on for real users:

• Turn-notification email — you can register for it in principle, but nothing in the live service currently sends an email through this data; that delivery side isn't wired up yet. (Browser push turn notifications, by contrast, ARE live for multiplayer room games — see §2.4.)

Priced on our plans, but not built at all yet:

• AI-generated art.
• Uploaded-art recognition and auto-crop — no image-upload endpoint or image-analysis code exists yet. Nothing that looks like a photo or scanned artwork is processed, uploaded, or sent anywhere by Ludira today.
• Planning-chat as a separately metered feature.

This document is written mostly in the present tense because that's how a real Privacy Policy eventually has to read — but every claim above will be re-verified as the product changes, and this page will carry a genuine "last updated" date reflecting that.

1. Who we are

Ludira ("Ludira," "we," "us," or "our") is operated by Rekurzija DOOEL, a company organized under the laws of North Macedonia, as described in §1 of our Terms & Conditions. For data-protection purposes, Rekurzija DOOEL is the data controller for the personal data described in this Policy.

Registered details: full registered name Друштво за софтверски услуги РЕКУРЗИЈА ДООЕЛ Скопје ("Rekurzija DOOEL Skopje"), registration number (матичен број) 7237880, tax number (ЕДБ) 4080017569285, registered address Адолф Циборовски 21/1-6, 1000 Skopje-Centar, North Macedonia.

On payments specifically: when billing eventually goes live, Paddle is the merchant of record for your purchase, which has a direct privacy consequence worth stating plainly here even though it's primarily a contracts point covered in the Terms: Ludira's servers are never sent your card number, expiry date, or CVV, at any point, by any mechanism. Checkout happens on a page hosted and operated by Paddle itself — our server calls Paddle's API to create a transaction and receives back a checkout URL to send you to; your payment details are typed directly into Paddle's own hosted checkout UI and never transit our infrastructure. What our own server receives afterward is a signed webhook, and the only fields our server actually parses out and retains are a customer id, a subscription id, a plan tier, and a status string (see §2.5) — we deliberately don't even parse the billing-address or tax fields Paddle's real payloads carry, because we have no use for them. This is a genuine, architecture-level fact, not just a policy promise: there is no way for our systems to retain raw card data even by mistake, because card data never reaches our servers at all — it goes straight from your browser to Paddle.

2. What data we collect, and why

The table below is the honest, complete inventory of data tied to a product feature as of this Policy's last-updated date — cross-referenced against §0 for what's actually reachable today versus built-but-dormant versus not yet built. Detail on each row follows underneath. We also keep standard server and reverse-proxy access logs, as any web server does — that's covered separately in §6 and §10 rather than as a feature-specific row here.

2.1 Game content you create

When the anonymous draft system is switched on, saving a draft stores exactly two things: the game's rules definition (a document describing components, moves, and flow) and an optional sidecar of presentation metadata — board-position labels, arrangement, that kind of thing, never image bytes themselves. The store deliberately rejects anything that isn't a validator-clean game definition, specifically so this system can never become a general-purpose anonymous file host.

An anonymous draft's trust model is a capability link, not an account — an anonymous draft isn't tied to any account: the draft's URL contains a 128-bit random id, and holding that URL is the proof of access. (Accounts do now exist — see §0 — and a logged-in Creator can claim drafts to their account; this paragraph is about drafts saved anonymously, without logging in.) This is the same model a lot of "share a link, no login" tools use. If you share a draft link with someone, you're sharing edit and delete access, not just view access, and there's currently no way to have view-only sharing or to prove you're the "real" owner of a draft versus anyone else who has the link.

2.2 What you send to our AI features

The one AI feature that's actually implemented, end to end, is natural-language-to-game-definition generation. What it sends to Anthropic, precisely:

• A system prompt that is entirely Ludira's own fixed schema/instructions text — it doesn't vary per user and contains nothing about you.
• Your free-text game description — whatever you typed into the generator — verbatim.
• If the first attempt doesn't pass our structural validator, up to two repair rounds, each of which also includes the model's own previous (rejected) output and the validator's specific error messages.

That's the complete list. There's no separate account profile, location, device fingerprint, or identifier attached to a generation request. The obvious caveat, true of any AI text box: if you type personal information into your game description — a real person's name, an address, anything like that — that text is sent to Anthropic like any other part of the prompt. Don't put anything in a game description you wouldn't want processed by a third-party AI provider.

Ludira's own server does not write your prompt or the generated definition to any persistent log or database as part of serving this request — the only server-side log line records the generated definition's internal id, attempt count, and a playability true/false, not the prompt text or the full definition. What Anthropic itself retains, and for how long, is governed by Anthropic's own terms — see §4.1 and §5.

2.3 Multiplayer room data

Creating or joining a multiplayer room (playing one of the five demo classics with friends over a share link) generates: an unguessable room id, one unguessable seat token per player, and — while the game is live — the in-progress game state itself (whose turn, board state, scores). All of this lives in server memory only and is never written to disk, unlike drafts, which do get a disk file because they're the only copy of someone's work — a room is not. A server restart, or the game simply finishing, erases it completely. There's nothing to separately request deletion of; it doesn't outlive the game.

2.4 Notification data (browser push is live, email is not)

Registering for turn notifications stores either a browser push subscription (an endpoint URL plus two encryption keys your browser's Push API generates) or an email address, keyed to your per-game session token, not to a person. Browser push is live for multiplayer room games: if it becomes your turn and your browser isn't actively connected to that game, we send a push through your browser's push service. Email notifications are built but not yet wired — registering stores the address, but nothing in the deployed server currently sends an email through it. If and when it is, an email digest is plain text — game titles and turn counts, no tracking pixels, no HTML — not a marketing email, and it's sent through a plain SMTP connection we configure, not a third-party email marketing platform.

2.5 Billing and subscription data (sandbox today, no real payment yet)

As covered in §0, checkout runs today only against Paddle's sandbox — no real payment has ever run. When a sandbox (and, later, a real) checkout completes, here is precisely what our own servers hold: Paddle's customer id, the subscription's id and status string, which plan tier that maps to, your current AI-credit balance and when that balance's billing period started, and the id of the last transaction event received. Explicitly not held: your name, billing address, card details, or tax information — Paddle's real payloads carry these, and our billing code deliberately doesn't even parse them out, because nothing here needs them. If you ever need something like a formal invoice or a VAT record, that's a Paddle document, not a Ludira one.

2.6 What our analytics deliberately do not collect

Worth stating affirmatively, not just by omission: Ludira's own analytics are, by explicit design, counters and nothing else — a page view increments an integer, and that's the entire artifact. The analytics system itself keeps no cookies, sessions, fingerprints, IP addresses, user agents, per-hit timestamps, or any per-visitor record of any kind. No third-party analytics, advertising, or tracking script of any kind (Google Analytics, PostHog, Mixpanel, Plausible, Meta/Facebook Pixel, or similar) is integrated anywhere in the product or its marketing site.

Two honest exceptions, so this isn't read more broadly than it's meant: account login uses first-party session cookies (§3), and the signed-out one-free-generation cap briefly processes a hashed form of your IP address (§2.7). Neither is analytics, advertising, or cross-site tracking, and neither feeds the counters above.

2.7 Account data and the anonymous free-generation cap

Account record. Creating an account stores your login email address (we need it in the clear to email you a login link — there is no password), a user id, the list of draft ids you own, your AI-credit balance and billing period, and — only once you check out — your Paddle customer id. Your login session is a random bearer token stored hashed at rest, never in the clear, and carried in the session cookie described in §3.

Anonymous free-generation cap. Signed-out visitors get one free AI generation before an account is required. To enforce that without an account to key on, the server keeps — in memory only, per rolling 24-hour window — a SHA-256 hash of the caller's IP address (the raw IP is never stored) plus an opaque, unguessable per-browser cookie token (ludira_anon_taste, see §3). This is an abuse-prevention rate limit, not a profile: the raw IP is never stored, only its hash is held in memory for about 24 hours (and cleared on any server restart), and it's used solely for the one-free-generation limit — it holds no other attribute about you. We don't overclaim it's irreversible: a hash of an IP address is not personal-data-free (the space of addresses is small enough to test against), which is exactly why it's kept only in memory, only briefly, and only for rate-limiting.

3. Cookies and local storage

Ludira sets a small number of first-party cookies, all of them strictly-necessary or functional — for authentication, security, and one usage limit. There are no analytics, advertising, or cross-site tracking cookies anywhere in the product, from Ludira or any third party. Because these cookies are limited to what's strictly necessary to log you in and keep the service secure (plus one functional usage-cap cookie), we treat them as exempt from prior consent under the ePrivacy rules, so no consent banner is shown — but this is re-checked whenever something new ships, and we won't add a tracking cookie without adding the consent flow that would then be required.

The one piece of browser local storage in use is a crash-safety copy of whatever you're actively editing in the game builder, so a closed tab doesn't lose your work before it's saved to the server. It never leaves your browser, is not sent anywhere, and is cleared automatically once your edit is successfully saved to the server.

4. Third parties we share data with

4.1 Anthropic (AI generation)

When AI-assisted rule generation is used, your game description is sent to Anthropic (the maker of the Claude models) via Anthropic's Messages API. This is a real, working integration, and it is live for public traffic: a signed-out visitor's one free generation, and every generation by a signed-in user, is served by a real call to Anthropic's API.

We don't yet have full visibility into whether, or for how long, Anthropic retains or could use prompts sent through our specific commercial API arrangement — that's governed by Anthropic's own API terms and privacy policy. We'll state this plainly and link to Anthropic's current privacy policy and API terms once we've confirmed the details, rather than assume either a "never used for training" or "may be used for training" answer.

4.2 Paddle (billing, merchant of record)

Once billing goes live, Paddle processes your payment and holds payment-method data as the merchant of record, as described in §1. Depending on where you're purchasing from, the contracting Paddle entity is Paddle.com Market Limited (England & Wales), Paddle.com Inc. (US), or Paddle.com (Canada) Ltd — see our Terms §1 for the full explanation; the same entity that's your seller for the transaction is also the controller (or processor, depending on the specific data element) for the payment data itself, under Paddle's own privacy policy, not this one.

4.3 Our hosting provider

Ludira's server infrastructure runs on a virtual private server from Contabo GmbH. The machine currently serving our live services is physically located in France (an EU member state), reverse-proxied through nginx with a Let's Encrypt TLS certificate. This is a genuinely favorable fact for EU data residency, stated here because it's true, not because it resolves every cross-border question — see §9.

4.4 Nobody else

No advertising network, data broker, analytics vendor, or other third party receives any data from Ludira today — see §2.6.

5. AI-specific disclosures

This section exists because Ludira is an AI-generative product talking to a community of board game designers who — reasonably — care a lot about exactly what "AI-assisted" means in practice for something they made.

• What's AI-generated versus what's yours: the rules-generation feature produces a starting definition from your description; you can edit every part of what it produces on the same canvas as anything you wrote or uploaded yourself. Ownership of that output is a contractual/IP question, not a privacy one — see our Terms §4.3 for that, including its own honest flag that AI-output copyright is unsettled law.
• AI transparency and the EU AI Act (Article 50): Ludira's AI features are always presented as AI, so you know when output is AI-generated rather than written by a person. The EU AI Act's Article 50 transparency duties apply from 2 August 2026; we make that AI-vs-human distinction clear at the point of use, and are implementing machine-readable marking of AI-generated output ahead of that date. The contractual side of this lives in our Terms §6.5.
• What's actually sent to a third-party AI provider, and when: exactly what's described in §2.2 and §4.1 — your typed description (and, on a repair round, the model's own prior output), nothing else, and only when you actively invoke the generator.
• No image or artwork of yours is processed by any AI model today. As covered in §0, the "upload art, auto-crop it" feature described in our pricing plan has no implementation anywhere yet: no upload endpoint, no image-analysis code, no vision-model integration. Neither does AI-generated art. When either ships for real, this section will be rewritten to name the actual provider and describe exactly what image data is sent and why, before either feature goes live to real users.
• Nothing here is trained on your specific content by Ludira itself. We don't operate, fine-tune, or train any AI model of our own — we call a third-party provider's general-purpose API. Whether that provider's own systems use API traffic for their own model improvement is the open question flagged in §4.1, not something we control or can unilaterally promise about.

6. Data retention

Stated per data category, honestly distinguishing an actual enforced rule from a target we haven't built yet:

• Game drafts: a real, enforced 30-day sliding-expiry window from the last time the draft was read or written — both a read and a write reset the clock. An expired draft's link simply 404s; the underlying file is swept from disk shortly after. This number is configurable server-side and is exactly what the product's own UI is designed to state next to a draft's share link once that UI exists.
• Multiplayer rooms and live game sessions: not retained at all — in-memory only, gone when the game ends or the server restarts. See §2.3.
• AI generation prompts: not persisted by Ludira past the request/response cycle that serves them. See §2.2.
• Analytics counters: aggregate integers with no natural "age" or per-record retention concept, since no individual record exists to expire.
• Notification subscriptions and email: we're targeting a 30-day inactivity expiry, to mirror the draft store's convention. That automatic expiry isn't built yet — today a record persists until you remove it yourself (see §7) or we clear it manually on request.
• Billing/entitlement records: active subscription plus 12 months after cancellation, then deleted. Twelve months post-cancellation comfortably covers the realistic window for billing disputes/chargebacks, while Paddle — as merchant of record — is the party actually on the hook for formal tax/invoice retention, not our own thinner entitlement record. Automatic deletion enforcing this isn't wired up yet; contact privacy@ludira.io to request removal once your window has passed.
• Server and access logs: 30 days is our target retention, consistent with GDPR's data-minimization principle. Automated log rotation enforcing that target isn't fully configured yet at every layer.

7. Your rights

Because the product serves EU/EEA users and Rekurzija DOOEL is a North Macedonian company (a jurisdiction whose own data-protection law is modeled closely on the GDPR as part of EU-candidacy alignment), this Policy is written against a GDPR-flavored baseline of rights: access, rectification, erasure, restriction, portability, and objection. Stated honestly, split between what's a real, working mechanism today and what's currently only a policy commitment:

Real and working today, without needing to contact anyone, for the two kinds of data our capability-link design already makes self-service on:

• Delete a draft: delete its share URL directly, or use the delete control once it exists in the builder UI. Whoever holds the link can do this — see the ownership caveat in §2.1.
• Remove a push subscription: already supported by the client.
• Clear a registered email: submitting a null email clears it.

Not yet implemented, honestly flagged rather than promised:

• There's no self-serve export or deletion mechanism for your account or billing/entitlement records yet — exercising an access or erasure right over that data means emailing §12's contact and having a human handle it manually.
• Accounts, and the remaining capability-link gap. Now that accounts exist, an account holder can be identified by their login email, so we can look up and act on the data tied to your account on request. What's still not self-serve is the tooling — there is no in-product "download everything" or "delete my account" button yet, so exercising access or erasure over account data means emailing §12's contact and having a human handle it. For data that is still fully anonymous — a draft or demo session you reached by unguessable link or token without ever logging in — the original gap remains: with no account and no verified email, nothing in the system can distinguish "your" anonymous data from anyone else's who holds the same link, so we can only act through whoever holds that link or token. This is a genuine, structural tension between the anonymous-by-design parts of the product and a GDPR Article 17 erasure right; attaching an email (by logging in, or via the recovery-email mechanism) is what closes it for your own data.
• Right to lodge a complaint: you always retain the right to complain to your own country's data protection authority regardless of anything in this Policy or the Terms — nothing here limits that.

8. Children's privacy

Ludira does not knowingly collect personal data from children. You must be at least 16 years old to create a Ludira account, matching our Terms §3.1. No age-verification mechanism exists today — this is a stated policy, not an enforced technical control: account creation is live, but nothing checks a stated age at signup.

A separate, still-open question this 16+ line doesn't resolve: whether any age floor applies to someone who only ever plays as an anonymous Player via a shared link and never creates an account — anonymous, no-account use remains a live and fully supported way to use Ludira, and neither this Policy nor our Terms currently states a minimum age for that use, only for account creation.

9. International data transfers

Stated factually, because the actual chain of jurisdictions involved is more specific than a generic "we may transfer your data internationally" line would suggest:

• Hosting infrastructure: physically located in France (EU/EEA) — see §4.3. For an EU/EEA user, this leg of the chain does not involve a cross-border transfer out of the EU/EEA at all.
• The controller: Rekurzija DOOEL is incorporated in North Macedonia, which is not an EU/EEA member state (it's an EU candidate country). Data flowing to the controller's own operations is, formally, a transfer out of the EU/EEA, regardless of where the server hardware physically sits.
• AI processing: Anthropic is a US company; a generation request's content leaves the EU/EEA when sent to Anthropic's API.
• Payments: whichever Paddle entity contracts with a given buyer (England & Wales, US, or Canada — see §4.2) processes payment data in that entity's own jurisdiction.

None of this is unusual for a small, global SaaS product. Standard Contractual Clauses (or another valid GDPR Article 46 mechanism) apply to these transfers where required; formalizing the specific data-processing agreements with each provider is ongoing work.

10. Security measures

Stated honestly rather than with generic reassurance language:

Real, verified measures:

• All public traffic is served over TLS (Let's Encrypt certificates, auto-renewing).
• Every credential in the system (draft links, session tokens, room/seat tokens, push-registration keys) is 128 bits of cryptographically secure random output — not sequential or predictable.
• Paddle webhooks are verified by signature, and fail closed on any missing, invalid, or stale signature.
• Every user-facing endpoint enforces a request-size cap and a concurrency limit, specifically to bound abuse against an unauthenticated, pre-account system.
• As established throughout this document, our servers structurally never receive raw payment card data — see §1.

Honest gaps, not overclaimed:

• No independent security audit or penetration test of any part of the system has been conducted yet.
• No formal incident-response or breach-notification process exists yet; we intend to put one in place as the product and user base grow.
• The product is, in its own words on the live site, "open beta." No security posture described here should be read as a guarantee of any particular level of protection.

11. Changes to this Policy

We may update this Policy from time to time. When we do, we'll post the updated version here with a revised "last updated" date and make reasonable efforts to notify users of material changes (for example, by email, if we have one on file for you, or an in-product notice) before they take effect. Continued use counts as acceptance, mirroring our Terms §11 — including the same caveat that EU consumer law may require explicit consent for adverse changes touching an existing paid subscriber, regardless of this section.

12. Contact and Data Protection Officer

• General privacy questions and rights requests (§7): privacy@ludira.io.
• GDPR doesn't necessarily require a formal Data Protection Officer for a company this size, but the privacy@ludira.io address above is our named, accountable contact for data-protection questions.
• Company: Rekurzija DOOEL Skopje (матичен број 7237880, ЕДБ 4080017569285), Адолф Циборовски 21/1-6, 1000 Skopje-Centar, North Macedonia.