Legal & Safety

How Safety Works

Last updated: 1 September 2026

1. The floors that never move

Some categories are enforced for every user, on every surface — chat, character creation, photos, clips and her voice — on the free plan and on every paid one, with no setting, no tier and no phrasing that reaches past them. A refusal on one of these is never softened into a warning:

• Anything minor-coded. Ages, age nouns, developmental description, regression framing and role proxies — however the request is dressed, and whatever number appears in a profile. Detailed on the Child Safety Standards page.
• Real-person likeness. Requests that target an identifiable person, whether by name or by resemblance. No real photograph can enter the product at all — see the Synthetic Content Statement — so this floor governs what can be described into existence.
• Non-consent. The hard vocabulary of sexual violence, scenarios framed on it, and distress language paired with sexual content.
• Technical evasion. Attempts to disable, instruct around or encode past the safety system. This floor is enforced with known false positives — some innocent roleplay openers are refused by it — and we have accepted that trade deliberately. A refused opener is an annoyance; a hole in a floor is not.
• Crisis. This one is deliberately not a refusal: a message signalling self-harm or suicidal intent is answered, but a fixed support note is appended that does not depend on her persona and cannot be written out of it by a character sheet. She is software — stated plainly on the AI Disclosure page — and this is the moment where pretending otherwise would be dangerous. Over-triggering is the safe direction here, and it is the direction we chose.

One relaxation exists, and it cannot reach any of the above. A verified adult on a paid plan may switch off a small, defined set of soft categories for their own account. It requires all three of an age-verified session, a paid plan and the user’s own toggle; a database column set on a free account does nothing. It is off by default, every suppression it performs is written to an audit log with the category and no prompt text, and the global generation stop still applies to it. In the code, one named constant is the boundary and every surface reads it, so the chat path and the image path cannot drift into disagreeing about what is a floor.

2. Both sides of the model

Before submission. Everything a user authors is classified before it reaches any model: chat turns, the name and description of a companion you create, and the requests that produce a photo or a clip. Text is normalised before it is read, so cosmetic disguises of a term do not change the verdict. A refusal happens before the request is sent and before anything is charged.

After generation. Every generated asset is created in a pending state, and the only path that serves media requires the state to be cleared. There is no admin bypass and no signed-URL shortcut around it. A still is classified on its pixels; a clip on a frame drawn from it; her voice notes on the exact line about to be spoken, before it is synthesised at all. If the safety pipeline never runs, the result is an empty gallery — not an unscreened one.

A separate rule sits underneath both: a companion whose description reads as minor-coded is never rendered. She is re-minted as an adult and any assets made under the earlier description are quarantined, and no path through the product skips that step.

3. What happens when something breaks

Failing closed is easy to write down and easy to abandon under deadline pressure, so the behaviour is specified rather than described:

Money follows the same rule. A refusal, a failure or a timeout returns the credits to your ledger as a row with a plain-language reason, without you asking — see Billing, Credits & Refunds.

4. We do not rely on a vendor filter

Most products in this category have an unstated safety story: the model provider filters the output, so the product does not have to. That is not our story, and we would rather say so than let it be assumed.

Flirtly runs with the generation vendor’s own content filter disabled, deliberately, on an account entitled to disable it. An uncensored adult product cannot run under a filter built for a general audience — it would refuse the product’s ordinary vocabulary while catching none of the things that actually matter. We accept the consequence in full: the vendor will never catch anything on our behalf, so our own classifiers are the only line of defence — on text, on images and on audio alike. That is precisely why sections 1 to 3 fail closed rather than fail open, and why the gate in section 5 blocks a deploy.

5. The red-team gate

The classifiers are held to a corpus of adversarial prompts written specifically to get past them, covering every surface. Every prompt in the refuse-set must be refused — one miss fails the build — and a second set of benign-but-adjacent prompts holds over-refusal to a ceiling, because a system that refuses everything is not safe, it is broken. The corpus runs in the same command as the linter, the type checker and the tests, and a build that fails it deploys nothing.

Cases we know are not covered are recorded in that corpus alongside the ones that are, rather than quietly deleted. A red-team set that only contains passing cases is a scoreboard, not a test.

6. What we deliberately do not publish

This page names architecture and commitments. It does not publish the detection vocabulary, the thresholds, the internal category identifiers, or any phrasing known to sit near a boundary — and that omission is deliberate rather than evasive.

A published blocklist for this product would be an instruction manual for generating exactly the content it exists to prevent. Anyone who can read the terms can enumerate what is not in them, and the readers with the strongest motive to do so are the ones the minor-safety floor is built against. So the parameters stay unpublished, and the properties above are written so they can be checked from outside instead: request something on a floor and it refuses, on any plan, with the same result. Regulators, payment processors and researchers with a legitimate need can request detail directly at abuse@flirtly.co.

7. If something gets through

No classifier is perfect, which is why the commitment we make is the removal process rather than a promise of perfection. Report anything through the report form or at report@flirtly.co. You get a case reference and a deadline that starts when the report arrives, not when someone opens it — the targets are in the Content Removal Policy, and the metrics we commit to publishing are on the Transparency Report.