Relationship, identity, preferences and adult roles are different systems and should stay different. This article goes beyond the feature name and looks at the practical customer experience, the engineering trade-offs and the decisions AVRE is using while the product moves from development builds toward a commercial release.
Romance is not the same as adult mode
A customer can want a romantic Companion without explicit interaction, or adult roleplay without framing the relationship as marriage. Treating relationship stage and adult settings as the same switch creates bad assumptions. AVRE therefore stores relationship progression separately from adult preferences. A Companion can be a close friend, dating partner or spouse-style character while adult mode remains disabled.
This separation also makes onboarding less intrusive. The app does not need to ask every adult preference simply because the user chose a romantic relationship. Adult configuration becomes relevant only when the user chooses to enable it.
Identity is not anatomy
Gender identity, presentation and body configuration describe different things. A female identity can use feminine presentation with female, male or mixed/custom anatomy. A male identity can also use independent body choices. Non-binary/custom identities need the same flexibility. Calling a body configuration 'gender' would make the data model incorrect and eventually produce wrong avatar/media behaviour.
AVRE's independent fields allow future avatar and image-generation providers to select compatible assets without erasing the identity chosen by the user. This is both a respectful design decision and a cleaner technical architecture.
Preferences need more than yes/no
Adult preferences use Like, Neutral, Dislike and Hard Limit because those meanings are not interchangeable. A dislike means the Companion should generally avoid choosing the theme. A hard limit means it should not be proposed or inferred as acceptable. Initiation is another independent control: the Companion may suggest, ask first or never initiate.
Separating content preference from initiation preference reduces surprises. Someone can like a theme but want to bring it up themselves. Another person can enjoy spontaneous suggestions but still have clear hard limits.
Adaptive learning must be reviewable
A Custom/Adaptive personality can notice patterns in conversation, but sensitive preferences should not become permanent because of one line of text. AVRE's direction is to treat inferred preferences as suggestions that can be confirmed. That keeps adaptation useful while preventing a model guess from silently rewriting the user's profile.
The same rule helps with relationship context. A roleplay message does not automatically change the real saved relationship stage. Durable state changes should have clear triggers and remain visible in settings.
Adult imagery uses the same boundaries
Image generation should not bypass the profile architecture simply because the Generate Selfie button is convenient. Adult image refinement is only appropriate when adult mode is enabled, represented subjects are adults and the active Companion/profile allows the category. Hard limits remain relevant to media requests.
The user interface can still be simple: click Generate, receive the image in chat, then describe the next change naturally. Simplicity at the surface does not require removing the underlying adult-mode checks.
Real models remain separate
AVRE Originals is real photography/video. AVRE Companion is fictional AI. If a fictional preset ever uses an authorised likeness inspired by a real model, the product should say so clearly and should not imply the real person is secretly typing the AI responses. The same rule applies to media recommendations.
That distinction protects performers and customers. A personal AI can be immersive without relying on confusion about whether the character is a real human being.
What this means for AVRE customers
The standard AVRE is aiming for is simple: a customer should be able to understand what a feature does, where the data goes, what hardware it uses and what happens when it fails without reading developer notes. That is why the public site now separates finished behaviour from planned behaviour and why manual testing can reject a technically present feature when the visible workflow is poor. Product documentation will continue to change as the release build becomes more stable, but those changes should make the promises more precise rather than quietly changing what the product is.