Designing AI-assisted dream work as a product—not a chat window

Dream material is fragile twice over. The dream fades quickly, and the work done on it scatters: a half-remembered scene in a notes app, an unindexed journal entry, a reading from a general-purpose assistant that lives in one conversation and is effectively gone once the thread scrolls away.

A conversational interface can preserve a thread, but it does not by itself create a canonical dream record, aggregate recurring motifs across an archive, or give ongoing work a persistent product structure.

Capture preserves the dream as text or voice. Exploration means choosing how to work with it. The checkpoints, answers and final output of that work are kept. Boards change the lens by motif, time or open question. Later visits return with the context intact.

The model is useful inside that sequence, but it is not the sequence. The archive and boards are what let the work accumulate instead of resetting each session.

Every method in Velum begins from a saved dream, never a blank prompt. From the dream, the user chooses how to work: Core Reflection, which reads the dream's emotional center, or one of six formal methods, among them Structure Analysis, Association, Compensation, Re-entry and Gestalt / Dialogue. Each method tracks its own status, so work can pause and resume.

Re-entry shows how much of the experience is designed state rather than open conversation. Choosing it creates a session and persists a checkpoint list. The opening stabilization and presence prompts are deterministic; the model is not involved yet. The user selects an entry point, then picks what holds their attention from directions the model infers from the scene and session. Each response is saved before the next step. After every answer the user decides whether to go deeper, choose a new direction or return. The state machine branches at configured depth intervals rather than enforcing a hard session cap, and returning leads to a carryback prompt and a synthesized Contact Record the user can reopen from the dream.

The model proposes directions and deepening prompts. The user chooses the path, and nothing in the flow presents output as the dream's meaning.

The state atlas covers the moments easiest to get wrong: a capture screen that asks only for what the user remembers, a method-specific loading scene instead of a generic spinner, a ready state with an explicit Begin, and the archive behind an optional app lock.

A board is a saved lens on the archive. Its configuration persists per user: name, filters, pin, and an ordered list of tile instances with their settings. When a board opens, resolveBoardDreams() resolves its scope once, and every tile reads from that same scoped set.

The current implementation registers eleven tile types: What Keeps Recurring, Recurring Motifs, Motif Companions, Emotional Weather, People & Figures, Places, First / Latest Appearance, Linked Dreams, Timeline, Frequency Plot and Open Questions. Each does one narrow job, such as ranking recurring labels, counting co-occurring motifs or resolving a first and latest appearance, and links back to the filtered archive or source dream instead of copying it. In edit mode, tiles can be added, reordered, configured or removed.

Two decisions matter. Current tiles execute deterministically: they aggregate enrichment already attached to each dream, so opening a board never calls the model, and counts recalculate as the archive grows. And Open Questions is the one tile that stores user-written content, keeping questions and notes on the board between visits.

That is what turns a feature into a platform. New capabilities can arrive as new tile types against the same resolver and archive, rather than as new screens or longer conversations. Ten planned tiles are documented as specification proposals with P1–P3 priorities, not as shipped behavior.

Velum runs across three zones. The Expo / React Native app holds product state in Zustand and persists dreams, boards and sessions as user-scoped JSON in AsyncStorage. A small Express API sits between the device and Anthropic's Messages API, which runs Claude Haiku 4.5 by default.

Orchestration lives on the client, in each method's state machine. For every model call, it assembles the dream body, its enrichment and the current session's answers, and selects prompt constants by method and phase. The request carries a Firebase bearer token and an X-Velum-Method header. The server verifies the ID token, applies a usage guard that can meter operations, tokens, cost and concurrency per feature, user and globally, and proxies the call so the provider credential never ships in the app.

The more important boundary is on the way back, where a successful HTTP response is not treated as usable output. The client rejects responses cut off at max_tokens, normalizes the text and parses JSON. Enrichment then passes through a motif sanitizer that cleans annotations, splits labels into atomic terms, canonicalizes, length-checks and deduplicates before anything reaches the archive that boards aggregate.

When a call fails, the failure becomes saved state: a failed session, or enrichment marked failed or quota-skipped, with the original dream already saved before enrichment ran. There is no generated success fallback. For Core Reflection, retrying is the user's decision; other methods expose a clear way back.

The limits are explicit too. Session output has no general runtime schema gate, and there are no automatic LLM repair attempts. Gestalt / Dialogue uses a parallel model call to sharpen its next hint, but that is model judgment shaping the experience, not a validator.

Prompts live in source control, organized by method, phase and template. Each saved session records a prompt version, the model, generation time, method and dream ID. That is coarse provenance: the v1 label is metadata, not a deployed prompt registry, and changing a prompt means shipping code.

The server writes an NDJSON event for every request, recording correlation IDs, feature and method, model, duration, provider-reported tokens, a code-based cost estimate, status and the usage guard's decision. A secret-protected admin API exposes usage and error views. The client separately logs parse failures and retries, because a completed provider call and a usable output are different signals. The next join worth building connects prompt version, request and client-side result.

Data boundaries follow the same discipline. Dreams, notes, boards and outputs stay on the device; there is no cloud archive sync. Only the selected dream and session context for a given call leaves it, through the proxy. Server logs contain no prompt body. Identity and subscriptions run through Firebase Auth and RevenueCat, and optional PostHog analytics pass an allowlist that excludes dream text. None of this is a compliance claim: local storage is not an encryption guarantee, and provider retention is outside what the code can verify.

The planned board shows the intended direction on the same archive and board. Key Excerpts would surface source language from a dream, with intentional generation and a separate cache. Motif Watchlist would follow one motif's thread across dreams. Period Pattern Reflection is designed as a deterministic recap built from dates, motifs and existing emotional weather, with no new model call in its first version. Pattern Synthesis, a user-triggered and cached reading across a board's dreams, is the most cautious proposal and is held at P3.

Much of that next layer can be computed from data the product already keeps; where a new model call is warranted, it enters as a bounded, user-initiated tile.