Bloomy: An AI-Powered Journaling Application with User-Controlled Mood Validation for Non-Clinical Emotional Reflection

Mental health is a growing global concern, particularly among students and young adults who face academic pressure, social challenges and lifestyle change. Access to professional care remains limited by cost, waiting times, stigma and a shortage of trained staff [1]. Mobile health applications, mood trackers and digital journals have therefore attracted attention as convenient complements to traditional care, because they let people reflect on their emotions and monitor their well-being in everyday life. Many of these tools, however, rely heavily on manual input and provide limited feedback, which reduces long-term engagement [2], [3]. Artificial intelligence (AI), and natural language processing in particular, can analyse free text, surface emotional patterns and generate personalised feedback. Combined with digital journaling, it could reduce user effort and give meaningful feedback while remaining accessible and non-clinical. Most AI-based mental health research, however, concentrates on detection and diagnosis rather than continuous, user-centred self-reflection [1], [4]. Users of mood trackers are also asked to label their own emotions manually, which is cognitively demanding and inconsistent. Mental health data is highly sensitive as well, so privacy, transparency and ethical safeguards must be part of the design from the start. Overly complex models, finally, can slow development and reduce responsiveness, which makes them unsuitable for small-scale, real-world applications. This paper presents Bloomy, an AI-powered journaling application for non-clinical emotional reflection. The system has four objectives: (1) a low-friction journaling interface for recording daily reflections and moods; (2) AI-based interpretation of the emotional tone of journal entries; (3) personalised insights and mood-trend visualisation; and (4) ethical, secure and privacy-aware handling of sensitive information. Bloomy is deliberately limited to non-clinical support: it provides no diagnosis, treatment or medical advice, it relies on pre-trained models, and its evaluation addresses functionality, usability and basic validation of AI output rather than clinical effectiveness. The contributions of this work are (i) a schema-constrained large language model (LLM) pipeline for mood validation and reflection generation that requires no in-house model training, (ii) a design in which the user's self-reported mood remains authoritative, (iii) engineering practices (caching, timeouts, graceful degradation) for using a quota-limited hosted model in a small-scale application, (iv) an evaluation combining functional testing, a check of the AI output and a user acceptance survey, and (v) a critical analysis of the findings, including the gap between technically correct and perceived useful AI output, the dominance of non-AI design in user ratings, and design lessons for applications built on hosted LLMs. From a computing perspective, the work shows how a hosted LLM can be integrated into a real mobile application with structured-output prompting and quota-aware design. From a social perspective, it offers a low-barrier tool for students and others who may hesitate to seek help, and it promotes self-awareness and early self-care. The rest of this paper is organised as follows. Section II reviews related work. Section III describes the system design and implementation. Section IV presents the evaluation, Section V analyses the findings and their implications, together with the limitations, and Section VI concludes.

AI has been widely explored in mental healthcare for early detection, diagnosis, treatment planning and continuous monitoring. Reviews report that machine learning, deep learning and natural language processing can exploit clinical records, speech, facial expressions, wearable data and text, and that classifiers such as CNNs, SVMs and random forests reach high accuracy in research settings [1], [4], [5]. Most of this work, however, targets detection on controlled datasets, which limits generalisation to everyday use, and the literature consistently stresses that AI should support rather than replace professionals, given the importance of empathy, trust and ethical responsibility [1]. Recurring concerns include privacy and data security, algorithmic bias from non-diverse training data, limited transparency of models, and the scarcity of longitudinal, real-world validation [1], [4]. Conversational agents are the most visible application of AI for self-help. Scoping reviews report that chatbots based on NLP and cognitive behavioural principles can reduce symptoms of anxiety, depression and stress, and that availability, anonymity and scalability address access barriers [6]. Retention remains a challenge once the novelty fades, most studies are short and small, and chatbots are rarely integrated with journaling or mood tracking [6]. More broadly, AI-driven personalisation is argued to improve engagement and retention in mobile and healthcare applications [2], [3], [7], and mobile health applications support self-monitoring, health education and reminders. Sustained engagement is nevertheless a persistent problem, and empirical evidence that AI improves engagement and outcomes in mental health contexts remains limited. Mood-tracking applications are the foundation of many digital mental health tools. Studies of their features and user reviews, and interview studies of how people use them, find that they help users notice emotional patterns but often fail to support preparation or action, that users want more personalisation and automated interpretation of their data, and that rigid input methods and avoidance of negative moods reduce data quality [8], [9]. Journaling and expressive writing are established means of emotional processing, with meta-analytic evidence of benefit [10], but they depend heavily on user motivation. Combining the two is the focus of recent AI journaling systems; for example, a Flutter and Firebase journaling application detects emotion from entries using a classifier trained on the GoEmotions dataset and offers reflection prompts and a link to counsellors [11]. Taken together, the literature shows that AI has been studied extensively for detection and diagnosis but much less for continuous, reflective self-support; that many mood-tracking applications collect data without giving actionable, personalised guidance; that AI-based tools tend to emphasise technical performance over user experience, ethical transparency and usability; and that few systems integrate journaling and mood tracking with AI-driven analysis in a non-clinical setting. Bloomy addresses this gap by using a prompted general-purpose LLM instead of a trained classifier, by checking the user's chosen mood against the entry without overriding it, and by grounding reflections in the user's own entries within an explicitly non-clinical scope.

Bloomy is implemented in Flutter [12] for the client and uses Firebase [13] services for the backend: Cloud Firestore for data storage and Firebase Authentication for accounts. All AI tasks are performed by the Gemini 3.6 Flash model (model ID gemini-3.6-flash) [14], accessed through Firebase AI Logic [15] with the firebase_ai package. Supporting packages include fl_chart for the mood-distribution pie chart and trend views, flutter_local_notifications with flutter_timezone for daily reminders, shared_preferences for local reminder settings, url_launcher for the support contact and intl for timestamp formatting. Three considerations drove this choice. First, journaling is an in-the-moment activity, so a native-feeling mobile client suits the frequent, low-friction use that sustained engagement requires better than a web application. Second, prompting a general-purpose LLM with a constrained JSON response schema avoids the effort of training and evaluating separate sentiment and emotion models, which would be difficult within an undergraduate project timeframe. Third, a backend-as-a-service provides authentication, a real-time NoSQL database and hosted LLM access from a single platform, reducing the custom infrastructure for user management, API routing and database administration. Development followed an iterative and incremental, system-oriented approach: features were implemented, tested on a device, diagnosed for defects and refined in repeated cycles, and the mood-validation feature, the caching mechanism and the visual design were each revised several times in this way.

The system uses a client-server architecture with four layers (Fig. 1) that separates user interaction from data processing and AI analysis, which improves maintainability, scalability and security. The user interface layer provides the journaling, mood selection, analytics, reminder and account screens. The application layer consists of Dart service classes (JournalService, DashboardService and NotificationService) that encapsulate Firestore queries, notification scheduling and business logic, decoupled from the interface widgets. The AI analysis layer is a GeminiService class that wraps the Firebase AI Logic SDK and performs mood-alignment validation, weekly reflection generation and daily micro-insight generation, each with a schema-constrained JSON response for reliable parsing. The data storage layer is Cloud Firestore, which holds journal entries, moods, cached AI output and reminder preferences, partitioned per authenticated user. Each layer can be developed, tested and optimised independently.

A journal entry passes through five steps. The user writes free text and selects a mood from a fixed set of ten labelled moods. Before saving, the entry, the selected mood and the list of allowed moods are sent to Gemini, which returns a JSON object with a boolean match flag, a best-fit mood and a short justification. If the judgement is a mismatch, a non-blocking dialog offers to switch to the suggested mood or keep the original one, so the system never silently overrides the user's self-report. The entry, final mood and a server timestamp are then stored under the user's UID, and scheduled or on-demand queries aggregate entries into mood distributions, streaks and week-over-week comparisons and supply recent entries as context for reflections. Mood validation is treated as a constrained generation task rather than polarity classification: Gemini receives the entry, the selected mood and the allowed mood list, and a low sampling temperature of 0.2 favours consistent, less creative judgements suited to an evaluative task. Weekly reflections are generated from the current week's entries and mood summary. A JSON response schema limits each reflection to three short fields, an observed pattern, a specific suggestion and a warm encouragement, of about twenty words each, which keeps the output concise and prevents runaway generation. Daily micro-insights use the same schema-constrained approach over a three-day window and return a single short observation. Recurring emotional themes are surfaced through the pattern field and through the mood analytics instead of a separate keyword-extraction step. Reflections and insights are cached in Firestore per calendar week and per calendar day, so that repeated screen visits do not trigger repeated API calls, which was necessary under the free-tier request quota encountered during development.

The journaling screen combines mood selection, free-text entry and optional writing-prompt chips, which offer a starting sentence to lower the effort of beginning an entry without constraining what the user writes. The mood picker uses a fixed ten-mood grid rather than free-form or continuous input. This trades some expressive granularity for the consistency that the analytics and the AI validation need, and the fixed grid also keeps the layout stable across label lengths and text-scaling settings. Keyboard-aware layout handling ensures that the text field is never obscured while the user types. The analytics dashboard shows the mood distribution, a week-over-week comparison of journal and mood counts, the weekly reflection and the daily insight (Fig. 2). Several engagement features were added that do not depend on the AI integration (Fig. 3): keyword search in the history screen, a garden that grows with the journaling streak and shows weather reflecting the mood of the latest entry, a user-set reflection goal that adds a decoration to the garden when it is reached, a mood-booster section with a Happiness Jar of saved memories and a Make Me Laugh button, and daily reminders. A calm, gender-neutral sage palette avoids the strongly gendered aesthetic common in wellness applications, and the streak and garden reward consistency without shame-based messaging.

Composite Firestore indexes on userId and createdAt keep date-range queries efficient as entries accumulate, and all network operations use explicit timeouts and try/catch/finally handling so that loading states always resolve even if a request stalls. For privacy, Firebase Authentication manages accounts and sessions, all Firestore reads and writes are scoped to the authenticated user's UID, and a Privacy screen lets users export a summary of their data and permanently delete their account together with all journal, mood and reflection data. Only the minimum journal text and mood data needed for each request is sent to the Gemini API, and no data is shared with other third parties, in line with data minimisation. Ethically, Bloomy makes no diagnosis or clinical claim. The prompts instruct the model to use warm, observational language rather than prescriptive advice and to avoid clinical labels or diagnostic framing. The mood validation is suggestive rather than corrective, so users keep full control over their own mood selection, and the help and support content and in-app wording avoid triggering or alarming phrasing.

The evaluation had three parts: functional testing of the implemented Android application on a device, a check of the AI mood validation on constructed entries, and a user acceptance survey. Together they address the four objectives: journaling and mood recording (Objective 1), Gemini-based mood validation (Objective 2), the analytics dashboard with cached weekly reflections and daily insights (Objective 3), and data export and deletion with user-scoped access (Objective 4).

Twenty-two functional test cases derived from the four objectives and the supplementary features were executed on a device, and all passed (Table I). They cover the mismatch dialog and both user choices, empty-entry validation, streak increment and reset, chart accuracy, reflection caching, data export, account deletion, scheduled reminders, the supplementary features, and saving an entry after the daily AI quota has been exhausted, in which case the entry still saves and a non-blocking message explains that the AI check is temporarily unavailable.

The mood validation was tested on ten deliberately constructed entries (Table II): five whose tone matched the selected mood and five clearly mismatched, for example Happy with clearly angry or stressed text. Gemini returned the expected match flag in all ten cases, and in all five mismatches the mood it suggested was judged reasonable, with the user keeping the option to accept it or retain the original selection. The sample is small and contains only clearly worded entries, so this shows that the pipeline behaves as designed but not how it performs on ambiguous or mixed-emotion text, which would need a larger, systematic validation set.

A survey of six participants covered four age bands (under 18, 18-22, 23-27 and over 27), an even gender split, and both students and working adults. Three participants had used a mood-tracking or journaling application before and three had not. The survey used 27 five-point Likert items (1 = strongly disagree, 5 = strongly agree) in four categories, plus three open-ended questions. Table III lists the mean ratings by category. Usability (M = 4.86) and analytics (M = 4.72) were rated highest, and several items, including visual appeal, navigation, overall design and dashboard clarity, received a mean of 5.0. AI features were rated lowest (M = 4.28), driven by two items, "the AI mood validation provides useful and relevant feedback" and "the AI-generated daily insight is meaningful and easy to understand" (both M = 3.83), the lowest scores in the survey. The qualitative responses point the other way: three of the six participants named an AI feature, the weekly summary (two participants) or the daily insight (one), as their favourite, with comments such as "really encouraging" and "interesting to know how I felt". A plausible reading is that the AI features are valued when they work well but are the least mature part of the system and the most sensitive to occasional imprecision. The reflection streak (M = 4.83) and the garden animation (M = 4.67) were rated highly for motivating continued use, and open-ended comments described the application as "very cute to use" and praised its colour scheme. Overall satisfaction was positive (M = 4.50): "I would continue using Bloomy if it were publicly available" scored 4.67 and "I would recommend Bloomy to my friends or family" scored 4.33. The lowest item in this category, "Bloomy would be useful for supporting emotional well-being" (M = 4.17), is consistent with the deliberately non-clinical framing and should not be read as a usability problem. Requested improvements included a calendar view of mood history, more detailed weekly analytics, a shareable analytics chart, additional mood options and theme customisation, and one participant asked for a chatbot to talk to about their feelings, which matches the planned conversational feature.

Development surfaced five issues that were diagnosed and resolved iteratively: missing Firestore composite indexes (a FAILED_PRECONDITION error on compound date-range queries), deprecation of the originally integrated gemini-2.5-flash model partway through the project, reflections truncated mid-sentence, a permanent loading state after an uncaught exception, and a free-tier quota of 20 requests per day that was exhausted during testing. The last three have design implications that are analysed in Section V.

Four findings from the evaluation go beyond confirming that the system works, and we regard them as the main empirical contributions of this study (summarised in Table IV). First, a prompted, schema-constrained LLM was sufficient to interpret journal entries against a fixed mood taxonomy without any model training, and it behaved as designed on every constructed test case. Second, the components that users rated highest were the non-AI interface and engagement features, while the AI-driven features were rated lowest, so technical correctness did not translate into perceived usefulness. Third, the development exposed failure modes that are specific to building on a hosted LLM, namely output truncation caused by the model's reasoning overhead, a very small free-tier quota and the deprecation of the integrated model during the project, and each led to a design decision that we recommend for similar applications. Fourth, a privacy-by-design architecture still has to send journal text to a third-party model in order to provide any AI feature, which sets a limit on what the privacy controls can guarantee.

Using a general-purpose LLM as the emotion classifier removed the need to collect labelled data, train and evaluate a model, and maintain it, which was decisive for a project of this scale. The trade-off is that the behaviour of the classifier cannot be inspected or retrained, only re-prompted, and its judgements depend on a provider's model version. The model's task was also made easier by the design: instead of open-ended emotion classification it chooses among ten allowed moods and decides whether the user's own choice is consistent with the text, which is a narrower question with a built-in reference point. The 10/10 agreement on the constructed entries should be read in that light. The coupling also has a cost: the fixed mood list that keeps validation and analytics consistent limits expressiveness, and a participant asked for additional mood options.

The mood validation returned the expected result on all ten constructed entries, yet the survey item on whether it provides useful and relevant feedback scored 3.83, equal to the lowest in the survey, while the AI-generated daily insight scored the same. The two results are not contradictory, because they measure different things. The constructed entries were deliberately clear-cut, whereas real entries are often mixed, brief or ambiguous, which is where a mismatch prompt is most likely to be wrong or unwelcome. A correct prompt that interrupts saving can also feel intrusive, which the non-blocking design only partly mitigates. The daily insight is capped at about twenty words, which may read as generic. We did not test these explanations, and with six participants they remain hypotheses. They do suggest that evaluation of AI journaling features should include ambiguous entries and measure perceived usefulness and intrusiveness, not only agreement with an expected label. The qualitative answers complicate the picture: half of the participants named the weekly summary or the daily insight as their favourite feature. The lower ratings may therefore reflect inconsistent quality across entries rather than general dislike, which matches the observation that trust and continued use depend on the quality of AI-generated feedback [6].

The highest ratings went to usability (4.86), analytics (4.72), the reflection streak (4.83) and the garden animation (4.67), and "I would continue using Bloomy" scored 4.67. These components do not depend on the LLM, and they were built to avoid the shame-based messaging common in habit-tracking applications. For this small group, the motivation to keep journaling therefore came mainly from a calm interface and a gentle, growth-oriented reward, with the AI feedback as a differentiating addition and not the main driver. This is consistent with the argument that AI should supplement rather than replace sound interaction design in mental-health-adjacent applications [1]. Interface and engagement design should therefore be evaluated separately from the AI features, because a strong result in one can mask a weaker result in the other.

The issues recorded during development translate into guidance for similar applications. Early reflections were truncated mid-sentence because the output token budget was shared with the model's internal reasoning, so a limit that appeared generous was not. Raising the limit was not the remedy that worked best. Moving to schema-constrained JSON with a short, explicit length limit for each field removed the truncation, made the output predictable and simplified rendering, so we recommend constraining structure and length in the schema instead of relying on free-form text. Second, the free tier allowed only 20 requests per day, which testing exhausted, and the originally integrated model was deprecated during the project. Both led to the same design response: cache generated content per period, wrap every call in a timeout, detect quota errors specifically, and let the core function (saving an entry) succeed when the AI step fails, which test TC-14 verified. Caching also had a benefit beyond quota savings, because insights stay stable within a week or a day instead of changing slightly on every visit, which gives a more coherent experience. Third, a stalled request left an early version of the save flow in a permanent loading state, so every network operation now resolves its loading state unconditionally. These measures were reactive here, and we suggest treating them as baseline requirements for applications that depend on a hosted model.

Bloomy scopes data access to the authenticated user, minimises what is sent to the model and gives users export and deletion, and the tests confirmed that deletion removes the account and its documents. These controls cannot, however, change the fact that journal text must leave the device and be processed by a third-party model for the AI features to work. Deletion in the application does not by itself govern how the model provider handles the transmitted text, and we did not assess the provider's data-handling terms, so the privacy objective is met for the application's own storage but is only partly addressed for the AI pathway. This is a structural limit of hosted-LLM designs for sensitive data, and it points to opt-in AI processing, clearer disclosure in the interface and, in future, on-device or self-hosted models as directions to evaluate. The ethical stance that the AI should suggest and never decide, which is visible in the mood-validation dialog and in the observational wording of reflections, limits the harm from a wrong judgement but does not remove it, since a reflection can still be mistaken or poorly timed for a user in distress. Because the system makes no clinical claim and has no crisis-detection function, it should be positioned as a self-reflection aid.

The application is implemented for Android only, so iOS-specific testing and configuration were not completed. The survey had six participants and the AI check used ten clear-cut entries, so the results are indicative and not statistically powered. The survey did not use a standardised instrument such as the System Usability Scale, and the participants were not followed over time, so the claims about motivation and continued use concern stated intention only. The effect of the application on emotional well-being was not evaluated, consistent with its non-clinical scope. Finally, the reliance on a hosted third-party model exposes the system to provider availability, rate limits and deprecation, and a production deployment would need a paid API tier. Caching mitigates but does not remove this dependence.

This paper presented Bloomy, an AI-powered journaling application that supports emotional reflection through schema-constrained LLM analysis of journal text, user-controlled mood validation, personalised weekly and daily insights, and privacy-aware data handling. All four objectives were met in the implementation, all 22 functional tests passed, the mood validation behaved as designed on ten constructed entries, and a small user survey rated usability and analytics highly. The work shows that a hosted LLM can be integrated into a mental-health-adjacent application without in-house model training while retaining user control and a non-clinical scope, and that engineering issues such as indexing, model deprecation, response truncation, state management and quota limits can be handled within an iterative development process. Future work includes iOS support by extending the notification, permission and platform configuration currently implemented for Android; a conversational interface ("Ask Bloomy") that answers natural-language questions about the user's own journal history using the same Gemini integration; longer-term trend analysis and correlation of mood with factors the user chooses to log, such as sleep, exercise and meals; migration to a paid model tier with usage monitoring to support a larger user base; and a larger and more diverse user study with standardised instruments such as the System Usability Scale, together with a systematic validation set that includes ambiguous and mixed-emotion entries.