Mature and explicit are product controls for two different adult visual outcomes. Mature is the default and can include sensual posing, lingerie, close contact, charged atmosphere, and strategic coverage without visible explicit anatomy or sex acts. Explicit can describe adult nudity or sexual activity directly and requires an active paid plan. Both still require clearly adult subjects, consent, authorized inputs, and provider approval.
Compare visible outcomes
Do not tell the model “standard intensity” or “high intensity.” Translate the selected control into actual scene instructions.
| Control | Intended visual direction | Still prohibited |
|---|---|---|
| Mature | Sensual adult styling, lingerie, close proximity, strategic coverage, suggestive pose, dramatic light | Minors, age ambiguity, coercion, unauthorized real people |
| Explicit | Directly described adult nudity or consensual adult sexual content | The same prohibited categories, plus provider-specific limits |
Mature should be strong enough to demonstrate the tool during a free trial. It is not a generic safe portrait. Explicit should be materially different, not mature plus the words “more intense.”
Keep controls outside the app-specific schema
Content level is shared across every NSFW Mini App. The Worker can validate it once as a common parameter, then pass the result alongside app-specific scene, style, action, or effect. This prevents five definitions from implementing slightly different entitlement rules.
The app’s own schema should validate only its scene or trait values. The common boundary should default missing content level to mature for compatibility. Quote and run must enforce explicit eligibility in the same request before run creation, trial reservation, credit deduction, or provider submission.
Lock explicit choices before generation
A free user can see the explicit option with the same lock interaction used for paid models. Clicking it should open the relevant subscription offer while leaving mature selected. It should not quote, create a run, reserve a trial, or deduct credits.
If a client bypasses the UI and calls explicit quote or run directly, the Worker should return subscription required. If a paid state expires between quote and run, preserve user inputs and show the same offer. The server remains the authorization boundary.
Flowith’s Adult Comic Generator and Adult Character Creator use this shared control.
Write separate prompts for each level
For mature comic output, specify clearly adult characters, sensual but non-explicit composition, strategic coverage, and no visible genital detail or sex acts. For explicit output, write the intended adult scene directly, without inserting the product label and without carrying mature-only coverage constraints into it. Provider review still determines whether the request runs.
For character creation, mature can focus on adult wardrobe, pose, expression, and atmosphere. Explicit can permit direct adult nudity or sexuality. For video, each action needs a distinct prompt at each level; two explicit-only actions can reject mature input as invalid.
The adult comic prompt guide shows how level-specific instructions combine with scene, composition, and exclusions.
Keep real-person capability separate
Content level and real-person mode solve different problems. A paid user can select explicit while still keeping real-person mode off for fictional or illustrated characters. If a real person is detected, the product should open the real-person control and verify paid eligibility. Specific consent remains required for both mature and explicit transformations.
Read the real-person consent guide before enabling it. An explicit entitlement is not consent, and a provider character-asset path is not a rights check.
Review mature outputs honestly
Mature output should deliver a meaningful adult result: deliberate styling, body language, relationship tension, and controlled composition. If it is indistinguishable from a generic portrait, the prompt is too weak. Strengthen the actual scene while preserving strategic coverage and non-explicit boundaries.
Review whether the subject is clearly adult, the chosen scene or style is readable, identity is preserved, and prohibited explicit details did not appear. A mature result that accidentally becomes explicit should be rejected or handled according to product policy.
Review explicit outputs carefully
Confirm all subjects are adults and the scene is consensual. For real people, confirm the output is within the exact permission. Inspect anatomy, expressions, added people, background text, and unintended changes in age or identity. Apply destination labels and access restrictions.
Provider acceptance does not mean every publishing destination will allow the result. The adult AI safety guide covers destination review.
Final takeaway
Mature and explicit should produce two clearly different adult directions, enforced as a shared product control. Mature is the meaningful free-trial default; explicit is paid. Neither bypasses adult status, consent, real-person controls, or provider review. The prompt should describe the intended scene, not the name of the switch.
Before submitting, compare the selected control with the visible request. If mature is selected, remove explicit anatomy and sex-act instructions rather than hoping moderation will reinterpret them. If explicit is selected, verify paid status before generating and keep the description direct. After generation, judge the artifact itself because a model can cross the intended boundary in either direction. Record the selected level as a safe enum, never by storing the private prompt in analytics. When a result is reused as a reference, keep its content level separate from identity so a later workflow can choose a different permitted direction without replacing the character.
For support and review, name the failed boundary without exposing the private prompt. “Explicit access required,” “real-person mode required,” and “provider declined the request” lead to different next actions. Clear categories prevent creators from spending retries on the wrong control and help teams distinguish product eligibility from safety moderation.
Use the same clear language in desktop and mobile interfaces.
