Emotion tracking in XOM refers to the platform's sentiment layer: the components that read text a user has written and classify its emotional tone so that content can be labelled, surfaced, or moderated accordingly. It exists today as a working prototype and a set of registered integration points, not as a finished intelligence service.
01How it is implemented today
The sentiment capability ships as one of XOM's intelligent content containers, at components/container/intelligent/sentiment/. When a post of type intelligent/sentiment is opened, the container subscribes to the Realtime Database path Users/{uid}/latestText, reads the signed-in user's most recent text, and classifies it into one of three states: positive, negative, or neutral.
The classification in the current build is a keyword match, not a model call. The component checks the lowercased text for a small set of positive and negative markers and defaults to neutral when no marker is found or when no text is present. That makes it useful for demonstrating the container contract and the display surface, and unsuitable as a measurement instrument. Treat any output as illustrative.
A second, separate touchpoint is the Media Console extension catalog (components/bridge/mediaConsoleLibrary.jsx), which registers an "Emotion Detection Tool" controller described as detecting and analyzing emotions in media content. Like most entries in that catalog, it carries a status of offline — the registry lists it as an available slot, not a running service. The same catalog registers third-party sentiment endpoints (for example an AWS Comprehend NLP entry and a Claude sentiment-analysis entry) as extension slots.
02Where the real analysis is meant to come from
XOM's architecture places AI intelligence behind the Aware bridge rather than inside XOM itself. The platform architecture document lists sentiment analysis as one of the Aware subsystems, and the internal enhancement charter is explicit that XOM presents intelligence rather than owning models: the intended fix is to replace the local status board with a read against the AWARE intelligence layer through a documented API boundary. Until that boundary is wired, the status figures shown on the Aware panel are generated client-side and should not be read as live telemetry.
03What this means in practice
If you are evaluating XOM for a use case that depends on affect data, the honest position is that the plumbing is in place and the analysis is not. The container routing, the display surface, the data path, and the extension slots all exist; the scoring engine behind them does not yet.