Publishing Checklist
CLOVERA PUBLISHING CHECKLIST Last updated: October 21, 2026 Before publishing these documents on the live site, confirm the following: - The contact email is active and monitored. - The service actually follows the policies stated here. - The age requirement shown on Clovera matches the Terms: MINIMUM_AGE in routes_auth.py is 13, the registration form refuses a date of birth below it, and nothing from that date is written to the account record, a log or any other store; the only thing kept is a twenty-four-hour refusal in the refused browser's own session cookie. If the minimum age is changed, if the date is ever stored, or if the refusal is ever kept anywhere but that cookie, Section 2 of the Terms, Section 10 of the Privacy Policy, Section 3 of the GDPR Notice and Section 17 of both KVKK Notices are wrong and must be rewritten first. - The typefaces are still served from Clovera's own server: every font bundle under static/fonts is regenerated with tools/fetch_fonts.py and nothing in a template or stylesheet points at fonts.googleapis.com or fonts.gstatic.com. Section 16(b) of the Privacy Policy, Section 8(c) of the GDPR Notice and Sections 6(c) and 7 of both KVKK Notices say that no font request leaves the site; if a deployment ever loads a typeface from Google or any other host, those passages are wrong and must be rewritten first. - The privacy page matches the real data collected by the app and backend. In particular: what the login record holds, which records keep a digest of an IP address, whether anything is placed in a user's browser to recognise it again, and what restores a persistent session. - Any analytics, cookies, ads, or third-party processors are actually disclosed. - Any special local legal requirements for your target countries have been reviewed. - The Anthropic account that holds the Claude API key, and the terms it runs under (the Commercial Terms of Service and the data processing terms incorporated in them), have been verified: that content submitted through the API is not used for model training, how long Anthropic keeps it, when flagged content may be reviewed by its staff, and which transfer mechanism covers the move to the United States. The AI disclosures in the Privacy Policy, both KVKK Notices, the GDPR Notice and the Terms match those terms. - The in-app consent/opt-in flows for KittenAI features (feature buttons, the Live Translation toggle, and any registration-time policy acceptance) match the legal bases claimed in the Privacy Policy and GDPR Notice. - For cross-border transfers under Turkish law, the mechanism relied on for each recipient — an adequacy decision, or one of the appropriate safeguards in Article 9 of the KVKK with the notification or authorisation that safeguard requires — is in place and matches Section 7 of the KVKK Notice, which no longer treats the use of a feature as explicit consent. - The list of KittenAI features and moderated content types in the legal documents matches what the app actually sends to Anthropic. - Live captions are still written down in the speaker's own browser, and /voice/<id>/caption still accepts text and nothing else. If the server is ever changed to receive sound for captioning again, Section 15(b-ter) and 16(e) of the Privacy Policy, Sections 6(e-bis) and 7a(b-ter) of both KVKK Notices, Sections 7(c-ter), 8(e) and 8a of the GDPR Notice and Section 9 of the Terms are wrong and must be rewritten first. - No automated review reads a direct or group message, and no switch, setting or environment variable can make one do so. The serious-crime screen covers only what is written in a community's channels. A change that would read private messages needs counsel's review for every jurisdiction Clovera is offered in, a revision of the Privacy Policy, the KVKK Notice and the GDPR Notice, and renewed acceptance, before it ships. - The same screen over what is written in a community's channels is on by default and is not a community owner's setting. Where a deployment turns it off with KITTENMOD_COMMUNITY_CRIME_SCAN, the Privacy Policy, the KVKK Notice, the GDPR Notice and the in-app notice in Settings -> Privacy are read again against that state, and the reason for turning it off is recorded. - Web search in the chat assistant matches what is published. It is on by default (KITTENAI_WEB_SEARCH); Section 15(b-bis) of the Privacy Policy, the KVKK Notice (b-bis), the GDPR Notice (c-bis) and Section 9 of the Terms all describe it as on unless the operator switches it off, and all four say that no other KittenAI feature can search. Before shipping a change that attaches the search tool anywhere other than KittenAI.run_chat, those four passages are wrong and must be rewritten first. - The categories the serious-crime screen flags, as they are written in the prompt in kittenai/core.py, are the same closed list that Section 15(e) of the Privacy Policy sets out, and nothing has been added to the prompt without being added to the published documents. - Every third-party service that receives user data is named in the Privacy Policy, the KVKK Notice, and the GDPR Notice, and no service has been added to the app without being added to those documents. - Calls and voice channels in the deployment are still carried by Clovera's own relay alone. The documents say that no STUN server, TURN relay, or other outside party takes part and that nothing is recorded; if a deployment ever configures an external relay, or if the client is changed to connect participants directly, that provider and the disclosure of each participant's address to the other participants have to be added to the Privacy Policy, the KVKK Notice and the GDPR Notice before the change goes live. - The browser identifier is still described as it works. The clv_device cookie is set at sign-in and registration and on a signed-in visit without one, is kept across sign-out, and is stored only as a digest on login_log and user_device; administrators see which accounts share one at /admin/login-logs and /admin/login-logs/user/<id>, and nothing acts on a match automatically; terminating an account records its browsers in device_ban. Section 11 and 12 of the Privacy Policy, Section 4(a-bis) of the GDPR Notice, Section 9 of both KVKK Notices and Section 3 of the Terms say exactly this. A change that acts on a shared browser without a person deciding, that sends the identifier anywhere, or that adds anything read from the device to it, makes those passages wrong and must be preceded by rewriting them. - The list of records in which a digest of an address is kept — Section 12 of the Privacy Policy, Section 9 of the KVKK Notice, Section 4(b) of the GDPR Notice — still matches the code. Any new table that stores one has to be added to all three, and to the list in Section 3 of the Terms. - What is stored unencrypted, as Section 8 of the Privacy Policy and Section 18 of the KVKK Notice describe it, still matches the code: uploaded files of every kind, blog titles, scheduled messages, KittenAI assistant conversations, profile text and the names of communities, channels and groups. If encryption is applied to any of them, or removed from anything else, both texts are corrected in the same revision. - Requests to erase an account can actually be carried out by whoever monitors the contact address, and are recorded as the retention and destruction rules require. - The notices the DSA Information promises are actually delivered: a reporter is told the outcome of their report, and a user whose content is removed is told that it was, with the route to contest it. - The assessment of whether the service has a substantial connection to the Union, on which Section 1 of the DSA Information rests, has been made against the service as it actually stands and is revisited as it grows. If it is offered in the Union, a legal representative is designated in writing and named in that Section. - Section 1 of the DSA Information says the promotional material is published in English only. That is still true of the deployment: the landing page, the descriptions served to search engines and any advertising carry no German, French, Spanish, Italian or Portuguese. The interface and the translation feature are unaffected and are meant to stay that way. - The number of recipients in any single Member State, relative to that State's population, is still low enough that the position in Section 1 of the DSA Information holds. This is the criterion that revives the obligation on its own as the service grows, whatever language the marketing is in. - What is readable without an account in the deployment — public posts, blog articles, publicly listed communities and their channels and forums — matches Section 14 of the Privacy Policy, Section 8 of the KVKK Notice and Section 5 of the GDPR Notice, including whether indexing of channel and forum pages is switched on. - The summary of changes shown on the re-acceptance screen names the substance of the revision users are being asked to accept, in every language, and says nothing that the documents no longer say. A user who reads only that screen must not be misled. - The keyed-digest configuration that the address digests depend on is present in the deployment: IP_HASH_PEPPER is set, the app refuses to start without it unless ALLOW_UNKEYED_IP_DIGESTS=1 is set, and /healthz answers with X-Clovera-IP-Digest: keyed. A deployment running with ALLOW_UNKEYED_IP_DIGESTS=1 has digests that are not keyed, and the description of them in the Privacy Policy, the KVKK Notice and the GDPR Notice overstates the protection. - The automatic take-down of reported posts counts only reporters with the standing Section 7 of the Terms describes: REPORTER_STANDING_DAYS in routes_admin.py is 7, probation must be cleared, and reporters sharing a registration address digest or a browser digest count once. If that rule is loosened, Section 7 of the Terms must be rewritten first. - Call set-up messages (SDP offers and answers, ICE candidates) are cleared from audio_call_session the moment a call ends or goes unanswered, and the text of a scheduled message is erased once it is sent or cancelled; Section 8 of the Privacy Policy and the corresponding KVKK and GDPR passages say so. - Address digests of IPv6 connections are taken of the /64 network (ip_digest_subject in app.py); Section 2(b) of the Privacy Policy, Section 2(b) of both KVKK Notices and Section 4(b) of the GDPR Notice say so. - CLOVERA_ENCRYPTION_KEY is set in the deployment; the app refuses to start without it unless ALLOW_DERIVED_ENCRYPTION_KEY=1 is set, in which case the data key is derived from SECRET_KEY and falls with it. - The voice relay admits only a member who holds a seat in the channel, re-checks membership, channel visibility and bans on every presence touch, and drops the socket when any of them fails; leaving a community and a platform ban both end every seat the account holds. The captions endpoint requires the same seat. - Where the Digital Services Act applies, the position on a legal representative for the Union stated in Section 1 of the DSA Information is the true position, and the representative's details are published there once designated. - The technical configuration the published texts depend on has been verified against the deployment notes held with the legal review file. - A written procedure exists for a personal data breach, naming who assesses it, who notifies the supervisory authority within the 72 hours that Section 8 of the Privacy Policy and Section 18 of the KVKK Notice commit to, and who posts the in-service notice. That period cannot be met by improvising after an incident, and the notice route is the only one there is, since no contact detail is held for any account. - The registration position under the Data Controllers' Registry has been checked against the exemption figures currently in force, not the ones in force when this was last looked at, and against whether the processing of special-category data has become a main activity — a question the serious-crime screen over what is written in communities bears on. - The size thresholds recorded at the end of the legal review file are re-tested against real numbers: recipients per EU Member State, any United Kingdom user base, one million daily accesses from Türkiye, five million users, one hundred thousand users or 25M USD revenue. Each of those revives an obligation this deployment currently does not carry. - Kitguard is still described as it works. Its scores, stops, waiting periods and the per-second counters in flood_guard.py live only in process memory and are never written to the database, a cache server or disk, the exceptions being the kitguard_hold rows that persist_kitguard_holds in app.py writes for stops, waits and temporary address blocks still in force, which hold no score, are deleted when the measure ends and never outlive a day, and the KittenMOD user case kittenmod.refer_from_kitguard opens, with no address or digest, for a signed-in account stopped again after kitguard.REPEAT_CLEARS passes within the hour, which gets no wait; the events counted are exactly kitguard.SIGNALS, with rate-limit refusals limited to _KITGUARD_RATE_ACTIONS in app.py, floods counted only when flood_guard.sustained holds, and blocked content counted only for new accounts; an established account is never assessed by its address, and passing the verification on an address does not reset that address's score; the clv_kg cookie lasts six hours and holds only an expiry and a signature; and the hCaptcha script is loaded only on /login, /register and /kitguard. Section 12 and 16(c) of the Privacy Policy, Section 4a and 8(b) of the GDPR Notice, Sections 6(d), 9a and 11 of both KVKK Notices, Section 7 of the Terms and Section 3 of the DSA Information say exactly this. Moving that state into a shared store, adding a signal, keeping it longer, or loading the hCaptcha script on any other page makes those passages wrong and must be preceded by rewriting them. - Kitguard's attack detectors are still listed as they work: the hidden link (kitguard.TRAP_PATH, the last element of base.html, disallowed in robots.txt) stops at once whatever the threshold, but only when a browser navigates to it, never when a page embeds it as an image or script, and the hits counted while a stop is in force are navigations alone; kitguard.looks_like_attack reads the path, the User-Agent and the query string except kitguard._FREE_TEXT_KEYS; _kitguard_inspect in app.py also counts methods outside kitguard.STANDARD_METHODS, /admin requests from non-administrators, more than _PAGE_404_LIMIT page 404s a minute outside _MEDIA_404_PREFIXES, 413 responses, and more than _FORBIDDEN_PATH_LIMIT distinct paths a minute refused with 403 for lack of access (_note_forbidden). Section 12(i) of the Privacy Policy, Section 4a(a) of the GDPR Notice, Section 9a(a) of both KVKK Notices and Section 7 of the Terms of Service list them; only the fact that a pattern matched is kept, never the request. - The serious-crime screen never feeds Kitguard. KittenAI.review_serious_crime is deliberately not wrapped by the class in app.py that reports blocked content to Kitguard; the Privacy Policy promises that screen takes no action of its own. - The crowd-panel switches that screen new accounts in every community and in their private messages stay off. Section 15(c) of the Privacy Policy and Section 7a of the KVKK Notices say general moderation does not run there; those texts are revised, and acceptance sought, before either switch is turned on. - If Clovera later becomes a registered company, these documents are updated to show the correct operator details.