-
-
Mind Minder web page home screen
-
Mind Minder app Social Lens screen
-
Mind Minder app Calm Brief screen
-
Mind Minder app Home Screen
-
Mind Minder app Profile Screen
-
Mind Minder app Profile Screen
-
Mind Minder app Profile Screen
-
Mind Minder Google Console API Screen
-
Mind Minder Billing Screen
-
Mind Minder Admin screens (judges added as admins)
About the Project
Inspiration
Mind Minder began with lived experience. As a neurodivergent person, everyday situations can become unexpectedly difficult when social cues are ambiguous, sensory input is intense, instructions are vague, or a task has too many possible starting points. Asking for support at work or in healthcare can add another layer of cognitive load precisely when clear words are hardest to find.
Most digital tools assume the user should adapt to the world around them. We wanted to reverse that assumption. Mind Minder's purpose is to make the neurotypical world more legible without making neurodivergent people smaller.
That led us to a focused question: could AI help turn one unclear or high-load moment into a practical next step while preserving the user's autonomy, privacy, and dignity? The answer became Mind Minder—a calm cognitive-access assistant designed to support the person, not judge, diagnose, monitor, or “normalise” them.
What it does
Mind Minder helps neurodivergent adults make sense of a situation and decide what to do next. A user starts by choosing their current capacity and the kind of support they need:
- Social lens separates observable facts from possible interpretations and offers a direct, low-pressure way to clarify or respond.
- Reset reduces sensory and decision load before asking the user to solve anything else.
- Plan it turns a vague demand into a small starting action, a short sequence, and a realistic stopping point.
- Work coach helps clarify instructions, prepare for interviews or meetings, and put workplace support needs into words.
- Advocate organises facts, questions, preferences, and requests for healthcare or support conversations.
Responses are structured for low cognitive load and can be tailored by tone, level of detail, self-described support needs, and preferred strategies. Users can type or speak, listen to a response, save and edit plans, and practise a conversation without the app pretending to know what another person thinks or feels.
Gemini powers the optional cloud guide, voice transcription, and Calm Brief. Calm Brief is an intentionally small alternative to an endless news feed: the user chooses up to three broad topics, deliberately requests an update, and receives exactly three concise items backed by Google Search grounding and visible sources. If complete grounding is unavailable, Mind Minder shows no summary rather than presenting an unsupported one.
The core experience remains usable without an account or network connection. Mind Minder never sends a message, makes a booking, submits an application, or takes another external action on the user's behalf. The user stays in control of what to keep, change, or do.
How we built it
We built the mobile experience with React Native, Expo, Expo Router, and TypeScript so one accessible design system could serve iOS, Android, and the web. The interface uses calm colours, large touch targets, short sections, explicit choices, and progressive disclosure to reduce visual and decision load.
At the centre is a hybrid response engine. A deterministic on-device guide provides immediate help for all five support modes and acts as the fallback when the cloud is unavailable. When a user chooses cloud assistance, a Node.js service on Google Cloud Run sends a tightly bounded request to Gemini 2.5 Flash through Vertex AI. Gemini returns a structured response that the app validates before displaying. The same service supports user-initiated speech-to-text and the grounded Calm Brief.
Alongside Gemini, we developed a smaller, specialised model pathway using LiquidAI/LFM2.5-1.2B-Instruct. Rather than train one model to do everything, we created five supervised LoRA adapters—one each for social, reset, plan, work, and advocate. They are narrow transformation models: they can organise facts and possible interpretations, shorten a task into a first step, or draft editable words, but they are not allowed to diagnose, infer consent or intent, supply current medical or legal facts, or act for the user.
We produced a provenance-tracked corpus of 13,200 project-authored synthetic records, including 9,600 functional coaching records and 3,600 high-risk boundary cases. No public datasets or personal stories were ingested. The five adapters were trained separately on an NVIDIA L4 using Modal, with low-rank adaptation of the Liquid 1.2B base model. Each training epoch was tested against guarded behavioural, schema, safety, and output-diversity checks. Human review was part of the training loop rather than a final cosmetic check: an initial 300-case review found that the candidate's answers were far too repetitive, so we revised the corpus generator, retrained the adapters, and added a diversity gate. The replacement candidate passed all 25 guarded behavioural cases at epochs 1 and 2; epoch 3 was rejected by the diversity gate, and the earliest passing checkpoint was selected to reduce memorisation and repetition risk.
The selected Liquid base model and five adapters live together in a private, authenticated candidate service on Google Cloud Run. The container includes pinned model and adapter artifacts so a cold instance does not download dependencies at request time. It scales from zero to one L4 instance and is isolated from the public production route while review is incomplete. When enabled in the future, opening Coach can begin a non-blocking warm-up; a cold, late, busy, invalid, or unavailable Liquid response falls through to Gemini, and the app can fall back again to its deterministic offline guide. Adapter hashes, training configuration, evaluations, immutable Modal artifact references, Cloud Run image details, model cards, and dataset cards are preserved as release evidence.
Safety and privacy were designed as system behaviour, not added as disclaimers at the end. Deterministic rules run before model generation for explicit self-harm, harm-to-others, and medical-emergency language. Model outputs must match a defined schema, social interpretations must remain possibilities rather than claimed facts, and no external action occurs without the user making it themselves.
The app works in guest mode by default. Questions, recordings, answers, capacity check-ins, recent guides, and conversation-practice content remain on the device. Optional accounts and cross-device sync use Supabase with row-level ownership, but creating an account uploads nothing: profile and plan sync must be enabled separately. Calm Brief requests send only the topic identifiers the user selected and do not use profile or prompt history for ranking.
The entire platform is designed around the Organisational Singularity framework, not only around a collection of features. Our Massive Transformative Purpose (MTP) is: “Make the neurotypical world legible without making neurodivergent people smaller.” We translated that purpose into constitutional product rules and into the DRIVE, SHAPE, SCALE, and IDEAS elements of the operating model. Decision architecture defines which actions may be deterministic, advisory, drafted, or prohibited; the intelligence stack carries each request through Purpose, Sense, Interpret, Decide, Act, and Learn; and safe autonomy, human accountability, adaptive architecture, and ecosystem trust determine how the system can evolve. Every roadmap item must identify its user-owned outcome, required data, evidence, foreseeable harm, reversibility, success measure, and stop condition.
These principles are operational controls, not just a strategy document. Mind Minder has a protected administration backend that stores the versioned MTP, its priority order, and hard constraints such as agency first, no mind-reading, no diagnosis, no normalisation, privacy by default, separate consent, safety before revenue, and named human accountability. Administrators can record a pass, warning, or breach against a constraint; assign an owner; document corrective action; and retain an audit trail. The same console maintains a maturity scorecard for every Organisational Singularity element, including its status, owner, supporting evidence, and next review date.
The admin backend also manages Mind Minder's recursive learning loops. Five initial loops cover assistant quality, user-led personalisation, conversation practice, planning outcomes, and access and reliability. Each has a defined purpose, success metric, counter-metric or guardrail, evidence source, status, and review cadence. Structured learning events can record a stage, outcome, latency, model mode, platform, and consent basis, but not raw prompts, transcripts, or personal scenarios. This lets the team ask whether a change genuinely improves clarity or task initiation while also watching for increased certainty, privacy complaints, coercive rewrites, excessive steps, distress exits, or fallback failures.
Human model review is managed through a separate protected workspace connected to the admin console. Administrators can invite lived-experience and safety reviewers, monitor progress, and export durable evidence. Reviewers receive blinded, hash-bound candidate outputs and score them independently, with space to approve, edit, reject, flag, explain concerns, or suggest a revision. The planned evidence packs contain 300 lived-experience cases and 200 safety cases. Reviewer notes are hidden from other reviewers, progress is saved securely, and completing a review never releases a model automatically: production promotion remains a named human decision. The current Liquid candidate remains private until this independent review and the physical-device gate are complete.
We backed the build with automated tests, privacy and safety specifications, service-isolation rules, model and dataset cards, guarded evaluation cases, and release gates. This helped us treat Mind Minder as a real product with accountable operational boundaries rather than a standalone AI demo.
Challenges we ran into
The hardest challenge was making AI useful without allowing it to become falsely authoritative. In social situations, an answer that sounds confident can cause harm if it treats a guess about somebody's intent as fact. We redesigned responses around what is known, what is uncertain, and what direct clarification or boundary could safely come next.
We also had to reconcile two goals that are often treated as opposites: personalisation and privacy. Sending an entire user history to a model would have been easy, but it was not acceptable for this product. Instead, we created explicit, separate controls for accounts, sync, and cloud profile sharing, while keeping the essential experience local.
Reliability across cloud and device boundaries created another challenge. Mobile permissions, audio-file lifecycles, simulator behaviour, network failures, model latency, and incomplete grounding all needed safe failure states. We built bounded requests, structured validation, short-lived processing, and multiple fallback layers so a failed AI call does not leave the user without support.
Training the Liquid adapters surfaced a different kind of failure. A model can pass simple lexical and schema tests while still being unpleasantly repetitive or insufficiently sensitive to context. Human review exposed a template-selection collapse that automated checks had not adequately captured. Converting that feedback into a measurable diversity gate—and ensuring the more repetitive third epoch was rejected—showed us why model quality needs both machine evaluation and accountable human judgement.
Finally, designing for neurodivergent users required us to question familiar product patterns. More content is not always more helpful. Notifications, infinite feeds, dense dashboards, automatic recommendations, and engagement loops can increase load. Building a calmer product often meant deliberately doing less.
Accomplishments that we're proud of
We are proud that Mind Minder has grown from a deeply personal problem into a working, end-to-end product across mobile and web. The signed iOS release has launched successfully on a physical iPhone, and the core experience also runs on Android and the web. Matching iOS and Android updates are being prepared from one tested source commit for store review.
The live Gemini service is connected through Vertex AI and Cloud Run, including structured coaching, user-initiated transcription, and a Calm Brief that fails closed when Google Search grounding is incomplete. At the same time, every primary support mode remains available through the offline engine.
We also completed an end-to-end, mode-routed Liquid training pipeline: synthetic-data generation with provenance, separate LoRA training for five support modes, behavioural and schema evaluation, diversity testing, artifact hashing, private scale-to-zero serving, and API fallback. The fact that the candidate remains locked away from production until its human and device gates are complete is itself an accomplishment; our deployment scripts cannot promote weights merely because an automated score looks good.
The protected admin platform makes the operating model visible and actionable. It brings product health, privacy-thresholded accessibility signals, learning-loop effectiveness, the Organisational Singularity maturity scorecard, MTP guardrail events, human model-review evidence, named ownership, and audit history into one place without exposing private user scenarios.
We are equally proud of the boundaries we built. Mind Minder can be used without an account; sync is opt-in; private rows are protected by owner-level access controls; sensitive scenario text is excluded from application logs; and safety routing occurs before model generation. Automated checks cover service isolation, safety interception, bounded profile context, audio validation, Calm Brief topic limits, grounding attribution, and cross-user data access.
Most of all, we are proud that the product's success measure is not time spent in the app. Success is a person reporting that something became clearer or easier to begin without losing autonomy, privacy, dignity, or safety.
What we learned
We learned that an AI assistant earns trust as much through restraint as capability. A clear statement of uncertainty, an editable suggestion, or a reliable offline fallback can be more valuable than a more impressive but less dependable answer.
We learned that accessibility cannot be reduced to font size or contrast. Cognitive accessibility also means reducing choices, making hidden expectations explicit, letting a person defer a decision, supporting different communication modes, and never requiring disclosure before offering help.
We also learned that privacy choices must be reflected in architecture. “Optional” only has meaning when the product still works after the user says no. Guest access, local processing, separate sync consent, minimal cloud context, and metadata-only operational logging made that principle concrete.
We learned that recursive improvement needs its own guardrails. A positive outcome metric is incomplete without a counter-metric that catches the harm created while optimising it. For example, higher conversation-practice completion would not be progress if coercive rewrites or distress exits also increased. The Organisational Singularity framework gave us a practical way to connect the MTP to those day-to-day product and model decisions.
Finally, we learned that lived experience provides a powerful starting point, but not a licence to assume every neurodivergent person needs the same thing. The next stage must be shaped through paid, consent-based co-design with a wider range of users.
What's next for Mind Minder
Our next priority is a representative co-design pilot with neurodivergent adults. We will measure whether each flow improves clarity, task initiation, and dignity; identify accessibility or safety failures; and revise the product using consented feedback without collecting participants' sensitive scenarios.
For the Liquid candidate, the next step is to complete the independent 300-case lived-experience review and 200-case safety review, respond to the findings, and repeat the required regression and physical-device tests. Only a candidate with complete human evidence, clean automated gates, named release approval, and a tested rollback path can be considered for production or eventual on-device deployment.
While store review proceeds, we will complete Android physical-device testing, broader accessibility and offline testing, independent safeguarding and security review, and final release checks. Production privacy, support, legal and account-deletion paths are now published. The dedicated RevenueCat offering is configured for both stores; sandbox purchase and restore validation remains a release gate before relying on the optional Supporter membership in production.
Beyond the first release, we want to expand conversation practice, improve support for transitions and changing plans, add carefully governed workplace and community pilots, and localise safety resources for new jurisdictions. Any future model pathway will remain behind automated evaluation, human review, and physical-device release gates.
The long-term vision is not an assistant that takes over a person's life. It is cognitive-access infrastructure that helps people understand a situation, express what they need, and take the next step on their own terms.
Log in or sign up for Devpost to join the conversation.