Vueniverse

Vueniverse is an evidence-to-action system that makes health data tangible, helping you find and challenge patterns, test changes, learn what works, and preserve a trustworthy personal history.

Comment

Inspiration

Health apps are good at showing isolated numbers, but they rarely answer the question we actually care about: what is this repeated part of my day doing to me? Heart rate, sleep, calendar events, workouts, and personal context usually live in different places. Putting them on another dashboard still leaves the user doing all of the interpretation.

We built Vueniverse as a complete evidence-to-action system. The name comes from "View + Universe": one clearer view of the small universe of data around each person. Initially, we planned to call it Baymax, but unfortunately Marvel holds the trademark :(

What it does

Vueniverse is a private mobile system that turns health data into useful actions. It currently combines heart rate, HRV, sleep, steps, and workouts with privacy-safe Calendar categories and manual check-ins for mood, caffeine, illness, exercise, and travel. In the future, it can connect with more wearables, screen activity, communication, music, and environmental sources. Instead of showing separate numbers, Vueniverse looks across days and weeks to show how routines and repeated moments may affect how someone feels.

Vueniverse can compare repeated moments, such as a recurring one-to-one or late-night screen use, with similar periods when those events did not happen. It also considers missing data, workouts, illness, travel, and examples that do not follow the pattern. MedGemma runs on the device to explain what the evidence shows, point out uncertainty, and answer follow-up questions without sending sensitive health data to a hosted model. Vueniverse then helps the user test a small change. For example, it may suggest box breathing before the next one-to-one. If the user agrees, the app tracks the next few occurrences and checks whether the health response changes. The result may become stronger, weaker, or remain unclear. The goal is not just to describe what happened, but to help people learn what works for them using their own data.

The seven-stage product journey

Vueniverse guides users through seven clear stages:

  1. Discover: Find a pattern linked to a repeated event or routine.
  2. Replay: See what happened before, during, and after each occurrence.
  3. Challenge: Check comparisons, possible influences, contradictions, and missing data.
  4. Explain: Use on-device MedGemma to understand the finding, evidence, and uncertainty.
  5. Test: Create one small and practical personal experiment.
  6. Learn: Compare the new results and update the original finding.
  7. Preserve: Keep a clear record of the data, evidence, experiments, and results.

How we built it

Vueniverse is built as a Flutter mobile application, with Kotlin handling the current native integrations and Pigeon providing typed communication between Flutter and the platform layer. The core implementation follows one strict pipeline: collect consented source data, remove unnecessary personal details, normalize it into a private timeline, calculate patterns with deterministic code, build a bounded evidence query, and use on-device MedGemma to explain only what the verified evidence supports. Findings can then become personal experiments, be updated with new results, and be preserved in History with their sources and analysis details.

Important privacy note: Vueniverse is designed so that all live personal data storage, processing, analysis, and MedGemma inference happen on the user’s device. This keeps sensitive data private and under the user’s control.

Sources and connectors

  • Health data: Health Connect provides heart rate, HRV when available, sleep, steps, activity, and workouts.
  • Calendar context: The Calendar Provider supplies event timing, recurrence, and locally classified categories. Raw titles and identities are discarded after classification.
  • Manual check-ins: Users can add context such as caffeine, exercise, illness, mood, travel, and other selected categories.
  • Connector pipeline: Each source follows the same flow: request permission, perform a limited incremental read, remove unnecessary identity or content, normalize units and time zones, remove duplicates, and write the result to the encrypted timeline.
  • Future connectors: Screen time, calls, Spotify, Strava, communication activity, direct wearable APIs, environmental data, FHIR, Social APIs (like discord) and additional mobile platforms can be added through the same connector contract.
  • Privacy rule: Future communication and media sources contribute only broad context. A call becomes timing and duration, while a music session becomes a category and time range. Message content, contact identity, and full listening history are not required.

Deterministic analysis and bounded model investigation

  • Vueniverse maintains a rolling analysis window and recalculates only the periods affected by new, changed, or deleted records.
  • Repeated events are divided into before, during, and recovery windows, then compared with similar periods when the event did not occur.
  • The analytical engine checks occurrence counts, source coverage, workouts, illness, travel, logged influences, missing data, and counterexamples. All medians, ranges, effect estimates, recovery times, consistency scores, exclusions, and evidence counts are calculated in code.
  • MedGemma receives only a compact summary of the available event categories, health windows, possible influences, and evidence counts. It cannot access the complete personal timeline or create database queries.
  • MedGemma can choose only one approved investigation:
    • Compare a repeated event with similar periods when it did not occur.
    • Inspect recovery after an event.
    • Check one logged influence.
  • The app validates the selected investigation and performs the actual calculation using deterministic code. MedGemma cannot calculate values, change evidence requirements, or approve a finding.
  • If the result does not pass the required checks, Vueniverse returns not enough evidence instead of forcing a positive finding.
  • Every accepted finding includes its supporting sources, excluded records, analysis version, and the rules used to produce it.

On-device model inference

  • Vueniverse uses MedGemma 1.5 4B IT as its private Explorer and Explainer model.
  • The model is converted into a Q4_K_M-quantized GGUF file and runs locally through a lightweight C++ inference engine connected to Flutter using Kotlin and Java Native Interface.
  • The model artifact is stored in app-private storage and accepted only after its file size and SHA-256 hash are verified.
  • The runtime supports model loading, bounded generation, cancellation, timeouts, cleanup, and clear failure states.
  • MedGemma receives only compact, verified evidence. It never receives raw Calendar titles, contact identities, message content, phone numbers, arbitrary records, or the complete timeline.
  • The Explainer returns structured content containing evidence citations, uncertainty, unresolved influences, and an approved next observation.
  • A deterministic output guard rejects invented numbers, missing citations, unsupported causal claims, diagnoses, prescriptions, unsafe advice, prompt injection, or leaked personal details.
  • If inference is unavailable or the response fails validation, Vueniverse displays a clearly labelled deterministic explanation instead of presenting fallback text as model output.

Privacy, storage, and data lifecycle

  • Normalized source records are stored locally using Drift with SQLCipher encryption.
  • The database key is protected through Android Keystore.
  • Every record keeps its source, timestamp, sync state, and provenance.
  • Users can enable, pause, disconnect, or delete sources independently.
  • Deleting source data invalidates dependent findings, experiments, cached explanations, and exports.
  • Evidence versions and request hashes prevent an old model explanation from being reused after its supporting data changes.

Experiments, history, and proof

  • A verified finding can be converted into a small experiment with a defined change, required occurrences, reminders, and adherence tracking.
  • The same analytical rules compare the experiment period with the previous baseline.
  • The original finding is updated as strengthened, weakened, unchanged, or inconclusive.
  • History preserves previous versions instead of silently replacing them.
  • Proof and Export records the sources, evidence counts, exclusions, analytical version, model runtime, safety result, and experiment outcome.

Application and verification layers

  • Flutter: Product screens, navigation, charts, evidence views, experiments, History, and privacy controls.
  • Riverpod: Source, analysis, experiment, runtime, and application state.
  • GoRouter: Navigation between Observe, Today, Moment Fingerprint, Evidence, Explanation, Experiments, History, and Settings.
  • Pigeon: Typed Flutter-to-native contracts for sources, secure storage, notifications, model delivery, and inference.
  • Kotlin and JNI: Native source access, secure platform services, background work, and MedGemma runtime integration.
  • Testing: Unit, widget, integration, Kotlin, JNI, safety, invalidation, missing-data, duplicate, time-zone, cancellation, and fallback tests verify the complete pipeline.

How GPT-5.6 and Codex helped us build it

We used different GPT-5.6 Codex models and thinking levels based on the complexity of the task. This allowed us to reserve the most capable reasoning modes for architecture, privacy, and safety decisions while using faster modes for focused implementation and iteration. Codex worked directly with the repository, helping us move from the product plan to working Flutter, Kotlin, data, analytical, and on-device model components.

  • GPT-5.6 Sol with extra-high thinking: Used for system-wide architecture, the deterministic evidence pipeline, source deletion and invalidation rules, privacy boundaries, MedGemma safety, and difficult decisions that affected several layers of the product.

  • GPT-5.6 Sol with high thinking: Used for complex implementation and code review across Flutter and Kotlin, including encrypted storage, source synchronization, model delivery, experiments, and cross-layer debugging.

  • GPT-5.6 Terra with medium thinking: Used for clearly scoped implementation tasks, test coverage, smaller bug fixes, UI states, and reviewing individual features without spending the higher Sol reasoning budget.

  • Faster and lower-thinking modes: Used for repository searches, documentation, UI copy, test fixtures, formatting, and other routine tasks where deeper reasoning was unnecessary.

  • Synthetic and adversarial evaluation: We used GPT-5.6 to create fictional health histories and test cases involving missing data, duplicates, time-zone changes, misleading influences, contradictory evidence, stale findings, prompt injection, unsupported numbers, and unsafe medical claims.

  • Managing our limits: We broke the build into smaller vertical tasks and selected the model and thinking level for each one. Sol with extra-high thinking was reserved for the hardest and highest-risk decisions, while Terra and faster modes handled routine development work.

  • Privacy boundary: GPT-5.6 and Codex supported the development process but are not part of the app itself. Personal health data stays on the device, where all analysis and MedGemma inference take place.

Challenges we ran into

One of our biggest challenges was keeping findings trustworthy as live data changed. Health permissions can be revoked, records can arrive late, Calendar events can change, and users can disconnect or delete a source. We made every finding traceable to the records that produced it. When those records change, Vueniverse recalculates the affected time periods and marks dependent findings, explanations, experiments, and exports as outdated.

Supporting the full range of planned data sources was beyond the scope of the development window. We chose depth over breadth, ensuring that the most valuable integrations worked reliably while keeping additional sources on the roadmap.

Running MedGemma 1.5 4B privately on a mobile device was also a major challenge. We had to manage secure model delivery, file verification, limited memory, response time, cancellation, and failures during inference. Every response passes through a safety check, and the app uses a deterministic explanation when local inference is unavailable or the output is not supported by the evidence. Latency, memory, battery use, and thermal behavior are treated as measured physical-device checks rather than assumed performance.

What we are proud of

We started with a simple idea: build a health app that connects everyday activities, such as meetings and routines, with changes in a person’s health. We believed in this idea for a long time, but never found the momentum to turn it into a complete product.

This hackathon finally gave us that push. After more than 10 brainstorming sessions, several sleepless nights, and even purchasing two Codex subscriptions to keep up with our pace, we brought the idea to life. Codex felt like an additional teammate, helping us refine the experience, overcome technical challenges, and turn rough concepts into a working Android app. We are proud that it became more than a basic prototype, allowing users to discover patterns, ask questions, run personal experiments, and review or export their evidence.

Completing this app is a milestone we are genuinely proud of. We built it with privacy, trust, and user control at its core, but our journey does not end here. We will be even happier when we obtain the required licences, complete the necessary validations, and roll it out to real users. Seeing it make a meaningful difference in someone’s life would be the most rewarding outcome of this journey.

What we learned

We learned that trust comes from making evidence inspectable, not from adding more AI language. Users need to see matched comparisons, exclusions, counterevidence, missing data, source provenance, and uncertainty. The system must also be willing to say “not enough evidence” and update a finding when the underlying data changes.

We also learned that on-device AI is more than a model file. Delivery, integrity, memory limits, cancellation, output validation, provenance, and clear runtime labels all shape the experience. MedGemma works best as a bounded explorer and explainer: it investigates approved questions and explains verified evidence, while deterministic code calculates every number, decides whether a finding is supported, and blocks unsupported health claims.

What’s Next

Our next phase is focused on making Vueniverse accessible to everyone and preparing it for the market. We will complete physical-phone MedGemma validation, enable secure on-device inference using private and verified evidence, expand privacy-conscious data connections, and introduce meaningful personal insights and bounded agentic workflows. Every feature will remain governed by deterministic safeguards, evidence contracts, user approval, and honest uncertainty.

  • Sprint 1: Validate and Productionize: Complete physical-phone MedGemma validation, make the final runtime decision using measured latency, memory, battery, and thermal performance, and build production-ready model delivery.

  • Sprint 2: Expand Insights and Data Access: Enable real on-device inference, create a reusable detector framework, add reviewed personal patterns, and integrate carefully selected privacy-conscious data connectors.

  • Sprint 3: Personalize and Guide Action: Connect insights to personal experiments and measurable outcomes, introduce bounded agentic workflows, identify evidence gaps, and improve relevance through private on-device personalization.

  • Sprint 4: Make It Accessible and Market-Ready: Test Vueniverse with real users, improve accessibility and usability, refine the experience using feedback, strengthen reliability, and prepare the product for launch, distribution, and marketing.

Regardless of the hackathon outcome, we are committed to achieving what we have planned and making Vueniverse accessible to everyone.

Built With

Share this project:

Updates