DreamTrace

Capture it before it fades. DreamTrace turns a just-woken voice memory into a provenance-aware, editable dream record—without presenting AI invention as remembered truth.

Comment

Inspiration

Dream memories are unusually fragile: a vivid place, feeling, or face can disappear in the time it takes to unlock a phone and find the right page. Most journaling tools also ask a newly awake person to do the hardest work first—type clearly, organize events, and decide what the dream meant.

DreamTrace begins with the fastest natural action: speaking whatever is still there. Its central design question is not “How much can AI add?” but “How can AI help organize a memory without quietly changing it?”

What it does

DreamTrace is a mobile-first Progressive Web App for recording a dream immediately after waking.

The dreamer can record, pause, resume, and stop a short voice memory, or use typed text or an audio upload. Gemini transcribes the recording, then DreamTrace lets the user correct the transcript before any structure is created. The app asks no more than two adaptive questions, and “I don’t remember” is treated as a complete, valid answer.

The final editable record contains:

  • an AI-organized title and concise summary;
  • a sequence of scenes;
  • people, places, objects, and recurring motifs;
  • an emotional arc;
  • unresolved fragments;
  • the untouched original transcript;
  • a Gemini-generated artistic storyboard;
  • an optional, non-diagnostic reflection; and
  • an optional user-directed Gemini Omni cutscene.

DreamTrace visibly separates four kinds of information: what the user directly remembered, what remains uncertain, what AI only organized, and what AI optionally reflects on. Generated images are labeled as artistic visualizations, not recovered memories. Generated video is labeled as an artistic cutscene, not recovered footage.

How we built it

The application uses TypeScript, React, Next.js-compatible Vinext, and a Cloudflare Worker deployment. The browser handles recording and keeps canonical records in local storage. Generated image and video bytes are stored separately in IndexedDB so they can never silently become part of the remembered dream record.

All provider calls and credentials stay server-side. A provider-neutral dream domain sits in front of Google Cloud and the Google Gen AI SDK:

  • gemini-3.6-flash handles short-audio speech recognition and recovery-question generation;
  • gemini-3-flash-preview creates the schema-constrained dream structure;
  • gemini-3.1-flash-lite-image creates fast 1K storyboards;
  • gemini-3.1-flash-image is the optional detailed 2K mode; and
  • gemini-omni-flash-preview creates an explicitly requested cutscene.

Zod validates every request and every model response. In the Cloudflare runtime, DreamTrace signs a service-account assertion with Web Crypto, exchanges it for a short-lived Google OAuth token, and never exposes the key or token to the client.

The complete cached demonstration—including three Gemini storyboard images—works without credentials and remains available offline after the PWA shell is cached.

Challenges we faced

The hardest challenge was preserving epistemic boundaries all the way through the product. A disclaimer at the end was not enough. Provenance had to be encoded into prompts, schemas, validation rules, editing behavior, exports, labels, error recovery, images, and video.

The second challenge was making one Google-backed architecture work across local Node development and a Cloudflare Worker. Local Application Default Credentials rely on the Google Cloud CLI; the deployed Worker cannot. The final adapter supports both while keeping the domain and public API provider-neutral.

Preview media APIs introduced a third challenge: variable latency, quota limits, and malformed responses. DreamTrace keeps all user input through timeouts and quota errors, rejects invalid output instead of improvising a result, and makes image/video media optional and disposable.

What we learned

We learned that trustworthy AI product design is mostly about boundaries. Asking fewer, better questions is more useful than extending a story. Uncertainty becomes reassuring when it is visible and editable instead of treated as a model failure. We also learned that a cached, truthful demonstration is essential for a product that depends on preview quotas: judges should be able to understand the complete experience even when a provider is unavailable.

Accomplishments we are proud of

  • A complete recording-to-record flow optimized for a 390px screen.
  • One multimodal Gemini path for transcription and recovery questions, avoiding a separate speech service.
  • A typed, Swift-reusable DreamRecord contract with runtime validation.
  • No credentials or provider SDK calls in browser code.
  • Clean recovery for microphone denial, invalid audio, empty transcripts, timeouts, quota failures, malformed model output, and offline use.
  • A real generated storyboard and optional directed cutscene that remain visibly separate from remembered content.
  • Local persistence, editing, deletion, Markdown/JSON export, PWA installation, and a credential-free cached demonstration.
  • A comprehensive local test gate across unit, rendered integration, mobile E2E, desktop E2E, and a deliberate live Google smoke path.

What’s next

The next step is a native Swift capture client that reuses the same versioned JSON contracts and server boundaries. After that: encrypted opt-in sync, private recurring-motif exploration across only the user’s own records, and richer cutscene refinement once the preview API stabilizes. Clinical interpretation, automatic memory completion, social feeds, and unattended video generation are intentionally out of scope.

Built With

Share this project:

Updates