Privacy Policy — Consilium Artis Belli

Effective date: 2026-09-18

Data controller: Consilium Artis Belli, Spain — hola@consiliumartisbelli.com

Language: This policy is published in English and in Spanish. English is the original version; if the two versions differ, the English version prevails.

1. What we collect

This section is about the data of people who have a CAB account. Data about people who do not have one — competitors of tournaments we mirror — is a different matter and has its own section (Section 5).

Account data (when you sign in with Google or Discord, or with the sign-in link the Terms describe): your verified email address, your display name and your profile picture URL as the provider supplies them, the identifier that provider uses for you, and the tokens that keep your sign-in valid. We receive these from the provider; we never see your password. The sign-in flow also stores short-lived verification records, and what is in them depends on which way you came in: signing in with Google or Discord stores a random value and the data needed to finish that exchange safely — no email address — while a sign-in link stores the address it was issued for, which is what the link is checked against. Both expire on their own clock.

Your public identity in CAB: every account gets a unique nick, and you may choose a display name to go with it. Those two are what other accounts see of you — in shares, in teams, in events and on published dashboards. Separately, there is a public profile link setting, off by default: turning it on allows the link between your account and the identities imported from external tournaments to be shown publicly. It is a consent, so it is off until you give it.

Account preferences: whether you read grades as numerals. It is the one preference we store on the account; the others — the language you read the app in, which rule set you have open — are choices of the device and stay in your browser (see below).

Feature entitlements: where a feature has to be enabled for an account, we store one record per account and feature, with its plan (free today) and an optional expiry date. It is what decides which features your account may use.

Session data: to keep you signed in we store session records including IP address and browser user-agent, and set strictly necessary session cookies. We set no advertising or analytics cookies, and we run no analytics in your browser.

Your content:

• the rule sets, rules and notes you create, and the sharing invitations you send or receive (which reference the other user's account);
• the rule links you mint for someone else to fill in: the name you give the link, the HASH of its token (never the token itself, which exists in the clear only in the address you hand out), the moment it was used, if it was, and the answers submitted through it. Nothing about whoever opened it is kept — see that surface in Section 4;
• your War Rooms: their name, your own roster (the player names you type, their factions and dispositions, and the army lists you paste), the rival teams and rosters you register or import, the grades and notes your team writes about rival players, the marks you share, and the rounds and pairings you run;
• your teams: their name and the accounts you invite into them;
• shared pairing sessions with another captain: the rosters both sides freeze and the picks of the sequence;
• the events you organize: the event and its competition, participants, rosters, army lists, rounds, pairings, results, standings and groups, the roles you grant to other accounts, and the publication matrix you decide;
• the dashboards and stream overlays you publish for an event, including the images you upload for them.

Usage records. We keep two, and they are not the same thing:

• Per-account usage: one record per API request your account makes, with the method, the route pattern (/api/teams/:id, never the concrete URL), the response status, the duration and the moment. No IP address, no user-agent, no query string and no request or response bodies. It exists to answer one question — whether the application is being used — and it is deliberately minimized to that. It is deleted with your account.
• The server's request log: one line per request, written to our hosting platform's log stream and not to our database, with the method, the path without its query string, the status, the duration and the browser user-agent. It carries no account id and no IP address, but the path can contain public identifiers — a nick (/api/handles/:nick), the address of an event, the id of a resource. It is not a log of accounts: it records EVERY request, so somebody with no session — a visitor opening a published dashboard, the public card of an event or a rule-fill page — leaves the same line, with nobody behind it. On the rule-fill surface not even the user-agent is written, so that the address of a link is never accompanied by a fingerprint of the device that opened it. It expires with the platform's log retention.

Public dashboard counters: when a published dashboard is opened, when its call-to-action is clicked, or when a stream overlay of it is mounted, we count the event — the moment, which dashboard, which of those three things happened, and nothing else. There is no account id, no IP address, no user-agent and no session or device identifier: the visitor is anonymous by construction. This is also why CAB shows no cookie banner — there are no advertising or analytics cookies and no client-side analytics, and what we do count identifies nobody.

In your browser, not on our servers: to keep working without network access (e.g. in a venue with poor wifi), your browser keeps a temporary replica of the War Room you are actively running and a queue of writes that have not yet reached our servers. This is transit, not a second copy of your data: it is refreshed from the server whenever you reconnect and is cleared when you sign out. The server is always the single source of truth. Your browser also keeps three things of its own, and all three go the same way: your per-device choices — the language you read the app in and which rule set you have open; a cache of the last identity it confirmed, holding your account id, your name, your email address and your avatar URL, so that a reload without network still knows who you are; and a cache of your rule sets with their grades and notes, plus one marker per feature enabled for your account, holding your account id and nothing else, so that opening the app without network shows what it showed last time. The identity cache, the rule sets and the markers are all erased when you sign out.

That is the complete list. We do not buy, sell, or enrich data.

2. What we use it for (legal bases)

• Providing the Service (contract): account, sessions, your content, sharing, teams, events and the publication the organizer decides.
• Security and abuse prevention (legitimate interest): IP address and user-agent on sessions, the server's request log, rate limiting.
• Knowing whether the Service is used, and whether public dashboards bring people to it (legitimate interest): the per-account usage records and the anonymous dashboard counters, both minimized as Section 1 describes.
• We do not use your data for advertising or profiling, and we do not send marketing email.

3. Where it lives

Data is processed in the European Union: application servers on Fly.io (Frankfurt, Germany) and database on Neon (AWS eu-central-1, Frankfurt). Sign-in is provided by Google and Discord under their own privacy policies.

Email is the exception, and it is worth saying plainly because it is the channel you use to exercise your rights: hola@consiliumartisbelli.com is not a mailbox of ours. It is a forwarding address run by our domain registrar (Porkbun) that delivers into a Gmail mailbox held by the operator, so a message you send us passes through Porkbun and Google before we read it.

4. Who can see your content

• Rule sets are private by default. They become visible to another user only when you share them and that user accepts the invitation, and only until you revoke the share or delete the content.
• Some content belongs to more than one account. The members aligned in a War Room linked to a team share its roster, its scouting of the rivals and its marks. A shared pairing session is a session between two captains: each side sees the state the server arbitrates for it, including the roster the other side froze. Leaving a team, or the team being deleted, ends that access.
• An event can be held by several accounts: its organizer grants roles over it (owner, admin, organizer, editor, viewer, streamer, scout), and each role sees and may change exactly what that role allows.
• What is published of an event is the organizer's decision. For each class of data — competition, participants, rosters, army lists, pairings, results, standings, groups and rankings — the organizer decides whether it is served to the event's own participants, to the general public, to a stream overlay or through the public API. Every class is born closed to the public, to overlays and to the API. Army lists are stored exactly as the player hands them in, and are published only if the organizer opens that class.
• There are five surfaces that are public on purpose, and every one of them is born closed: an event dashboard, which is private when it is created until the organizer opens it; the public card of an event, served to whoever has its address, which appears in the public search only if the organizer lists it (off by default); the stream overlay, which is off until someone turns it on and is reached only with a token generated on request; the playable demo, which carries sample data and nobody's real data; and the page where a team-mate fills your rules in, which does not exist until you mint a link for it.
• The rule-fill page deserves its own paragraph, because it is the one public surface where somebody who has no CAB account WRITES. It opens only with the token carried in the address you sent (a token we keep only as a hash, and which is never part of the request's path), and what it shows is the name you gave the link and a list of pairs to grade — a faction and a disposition each. Never a player, a team, a roster, an army list, a nick or the name of any rule set of yours. What it sends back is what that person answers, and it becomes content of yours. Of the person who filled it we keep nothing at all: no IP address, no user-agent, no visit counter, no identity. The link's name is a label you chose, not a claim about who answered.
• Your nick and display name are seen by the accounts you share with, team up with or play an event with, and appear on what the organizer publishes. The link between your account and an identity imported from an external tournament is shown publicly only if you turned on the public profile link (Section 1).
• We (the operator) can technically access stored data for operation, debugging and support, and do so only when needed.
• We disclose data to authorities only when legally required.

5. People who are not CAB users

CAB mirrors tournaments that other people run and publish, and organizers and captains enter into CAB what happens at the tables. Both mean we hold data about competitors who have never used CAB and never gave us anything. This section is for them.

What we hold. For each competitor: a person record with the name CAB shows for them, and one identity per external provider, with the name that provider publishes about them and, where the provider exposes one, its identifier for them. Around those, the record of the competitive play itself — entries and participants, rounds, pairings, games, results, army lists as published, groups and league placings. A person record is linked to a CAB account only when that link has been asserted; by default it is linked to none. Separately, a captain may type or import into their own War Room the names of the players of a rival team, their lists and the notes their team writes about them: that is content of that War Room and is deleted with it.

Where it comes from. From public tournaments and from the providers that host them (today Best Coast Pairings), and from what organizers and captains enter in CAB. It does not come from the person themselves.

What we do not hold. The providers' responses also carry emails and phone numbers of captains and players. We read none of them and store none of them: only the fields our own model declares are read at all, and those two are not among them.

On what basis. Legitimate interest in keeping a faithful record of public competitive play — the same play the tournaments themselves publish — balanced against the fact that nothing sensitive is held and nothing is enriched, profiled or sold.

How to exercise your rights. You do not need a CAB account. Write to hola@consiliumartisbelli.com saying which tournament you played and under which name you appear, and we will act on your request for access, rectification, erasure, restriction or objection. Where erasing a result outright would break the record of a competition that the tournament itself published, we remove what identifies you and keep the play anonymous, and we tell you what we did.

6. How long we keep it

• Account, content, shares, teams, entitlements, nick and display name, and your per-account usage records: until your account is deleted. They all hang off the account and go with it.
• Sessions: until they expire or are revoked.
• The server's request log: it is not in our database; it expires with our hosting platform's log retention.
• Public dashboard counters: they are tied to no account and identify nobody, so there is nothing in them to give back or to erase. We keep them as the measurement history of each dashboard; deleting a dashboard leaves its counters with nothing to point at.
• The mirror of external competitions (Section 5): it belongs to no account, so it survives the deletion of any CAB account. Requests over it go through Section 5.
• Backups follow our database provider's retention and expire on their schedule.

7. Your rights

Under the GDPR you can ask for access, rectification, erasure, restriction, portability, and object to processing. Write to hola@consiliumartisbelli.com. You can also complain to the Spanish supervisory authority (AEPD, aepd.es).

Account deletion is handled by support rather than a self-service button, and the reason is verification: deletion is irreversible and takes your content with it, so before running it we check that the person asking is the holder of the account. Email hola@consiliumartisbelli.com from your account address and we will verify and delete your account.

What deletion removes: your account and its sign-in records, your sessions, your rule sets, the shares of them, given and received, and the rule links you minted, with the answers they carry; your War Rooms and everything inside them (rosters, rival teams, scouting, marks, rounds and pairings); the teams you own and your membership of other people's teams; your pairing sessions; your entitlements; your nick and display name; and your per-account usage records.

What deletion does not remove: the record of what was played. Where you appear as a player of a competition, the link to your account is cleared and the record stays without you attached to it. That is deliberate: the history of a tournament — its pairings, its results, its standings — belongs to everyone who played it, and it must not break because one participant closes an account. An event you organized survives too, with your credit as its organizer cleared, and so do the credits kept elsewhere — who granted a role, who recorded a consent. The fact survives; the link to your account does not. A slot another captain typed in their own War Room also keeps the name they typed, because that is their content. If you want the name shown in a competition record changed as well, say so in the same email (Section 5).

8. Children

The Service is not directed at children under 14, and we do not knowingly process their data.

9. Changes

We will announce material changes in the app before they take effect. The current version is always at consiliumartisbelli.com/privacy.

10. Change history

• 2026-09-18 — first published. The text was brought in line with what the system actually stores, checked table by table against the database schema. Section 1 gained the public identity of an account, the account preferences, the feature entitlements, the rule links a captain mints, the two usage records — the per-account one and the server's request log, which also sees visitors with no session — and the public dashboard counters, and it no longer claims there is no counting of any kind. Section 3 says where our contact address really lives, which is not on our servers. Section 4 gained the five public surfaces — the rule-fill page among them, with a paragraph of its own — the organizer's publication matrix and the content that belongs to more than one account. Section 5, about people who are not CAB users, is new. Sections 6 and 7 now say what deletion removes and what it deliberately does not, and Section 7 states the real reason deletion goes through support: verifying that whoever asks holds the account. There is no purchase trail to protect — nothing in the Service is paid for today.