Two systems can both contain images while belonging to completely different privacy and commercial boundaries. 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.
Why the names had to change
Early AVRE planning used the word 'Vault' for more than one media concept. That creates a real customer problem. If the Companion has a private media vault and the website also sells a real-content vault, a customer can reasonably wonder whether their private images are connected to the commercial service. The solution is not another disclaimer; it is different product names and different technical boundaries.
AVRE therefore uses Private Media for the local Companion function and AVRE Originals for the online real-content membership. The words tell the customer what kind of system they are entering before they open it.
Private Media belongs to the Companion
Private Media can include generated Companion images and media associated with private chats. Its purpose is continuity inside the local personal relationship. Media should remain scoped to the active Companion and correct conversation. Switching Companion should not expose another Companion's private images simply because they live in the same application.
The storage model also follows the local security approach: user-selected Windows storage, password protection and recovery planning. A website subscription has no reason to ingest those private files.
Originals is an online publishing service
AVRE Originals has the opposite requirements. It publishes real photography and video to subscribers. That means online accounts, subscriptions, content delivery, messaging, performer records, complaints/removal and payment processing are necessary. The media is meant to leave the creator's workstation and be distributed through a controlled service.
Those differences justify a separate backend. Trying to reuse local Companion storage for a subscriber platform would create unnecessary security and scaling problems.
The privacy policies are different for a reason
A Companion customer expects intimate private conversation data to stay local by default. An Originals subscriber expects an online account to remember subscription status and messages. Both can be privacy-respecting, but the data flows are not the same. The site should explain each honestly instead of flattening everything into one generic policy sentence.
This is also why the My AVRE account should know what a customer purchased without becoming a cloud copy of every local Companion preference.
Real and fictional identity cannot blur
A real performer in AVRE Originals is a real person. A Companion character is fictional AI. Even if a future fictional preset uses an authorised likeness, the user must understand that the real model is not personally operating the AI. The Companion can recommend AVRE Originals content as real content, but it should not say 'these are photos I took of myself' if that statement would falsely attribute a real shoot to the AI character.
Clear provenance can be stored with media so the dialogue layer knows whether an asset is generated/private or real published content.
The simple rule for future features
When AVRE adds a media feature, ask one question first: is this user-private Companion material or AVRE-published subscriber content? If it is private Companion material, it belongs in the local/private domain by default. If it is a commercial AVRE Originals post, it belongs in the online subscriber platform.
That rule is simple enough to survive future growth. It prevents product naming, privacy language and backend architecture from drifting back into confusion.
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.