OME as a diagnostic face surface
A UI boundary note for keeping OME focused on expression, emotion, heartbeat, and lip-sync tests while the Builder remains the source of subject creation.
OME is framed as a diagnostic output surface, where affect, voice, camera, and mesh behavior can be checked against the authored self.
OME is the diagnostic face. Aura is the public soul signal. The Builder is where the self is made.
Why the boundary matters
OME is a strong visual system for expression testing. It can carry emotion, camera presence, listening state, heartbeat, gaze, and lip-sync. But if every screen becomes an OME screen, users may think the product is only a face demo.
The current product boundary keeps OME in diagnostic and conversation-test contexts. The ALIVE creation flow stays focused on Aura, source review, memory, rights, and relationship structure.
This boundary is also a codebase boundary. The face runtime can evolve quickly without pulling the entire product into experimental rendering logic. The Builder can evolve as a source, memory, rights, and identity workflow without waiting on every face feature.
The user should eventually experience these pieces as one living ALIVE. Internally, they need to remain separate enough that expression, memory, voice, and source review can be tested, replaced, and improved independently.
What OME should expose
The OME screen should show only the controls that help face and emotion runtime QA. It should not become a second builder, a marketing page, or a hidden admin surface.
The useful OME surface is a diagnostic room: what emotion is active, what expression is visible, whether the mesh is stable, whether the camera state is consented, whether heartbeat and arousal are connected, and whether lip-sync can follow the speech output.
It should expose enough to test realism without becoming visually noisy. The point is to help the team see whether the face is reading and expressing the same state as the self, not to turn the user-facing product into a face-control panel.
- Expression state and blendshape quality.
- Emotion and heartbeat response.
- Camera presence and listening status.
- Lip-sync readiness for voice sessions.
- Affect state alignment with the conversation and memory loop.
- Reduced-motion and low-power behavior for browser stability.
The difference between Aura and face
Aura is the first public signal because it can represent a forming self before the self has a body. It is abstract, personal, and less demanding. A face is more specific. Once a face appears, users read identity, age, intention, realism, and emotion into it immediately.
That is why OME should arrive at the right moments: conversation testing, emotion diagnostics, voice sessions, and ALIVE CAST demonstrations that need a visible performer. Aura can stay present everywhere else as the quieter signal of continuity.
This division keeps the product from overpromising. A beautiful face without memory is a demo. A memory system without presence feels like data. XALIVE needs both, but they should enter the experience in the right order.
How face state should connect
The face should not invent its own emotional truth. It should receive state from the ALIVE runtime: pleasure, arousal, dominance, pain, focus, listening, speaking, uncertainty, and relationship context. The face is an output surface for the self, not a separate personality.
When conversation becomes more emotionally charged, the mesh can show subtle shifts. When the memory loop is working, the face can become more focused. When voice output starts, lip-sync should follow the generated speech while preserving the same emotional state.
This makes the diagnostic face useful for objective testing. If the ALIVE says it is calm but the face looks tense, something is wrong in the state mapping. If the heartbeat reacts too strongly, the user feels that immediately. OME gives us a way to catch those problems visually.
How it connects back
Once the face runtime is stable, ALIVE CAST and ALIVE ME testing can use it as an output surface. The source of truth still remains the same subject contract: identity, emotion, memory, desire, and relationship.
For ALIVE ME, OME can eventually become a private companion surface for voice, camera, and emotional check-ins. For ALIVE CAST, OME can become a performer surface for characters, founders, artists, and other official selves. In both cases, the same rule holds: the face expresses the self that was authored. It does not replace the authoring tool.
The next UI work is to make the test surface clearer. The screen should reveal emotion, lip-sync, camera, and heartbeat state in a way that helps development, without leaking debug controls into the public product.