Dream / Reflection

Dream preview architecture and explicit review workflow

Dream is a separate, user-reviewed Preview feature available in the Memory Console at https://xmemo.dev/me#dream. It is distinct from the reflect maintenance tool (which executes programmatic consolidation passes on demand via MCP/API; see /docs/tools/reflect). Rather than running silent background mutations, Dream leads with what the user reviews and chooses to save, organizing scattered conversational context into source-grounded candidates.

• Console workspace: In the Memory Console at https://xmemo.dev/me#dream, Dream provides an interactive preview workspace under the subtitle: "Review recurring patterns before they become long-term memory."
• User-driven review: Dream never modifies persistent memory in the background; all candidate items require explicit human inspection and confirmation before any destination write occurs.
• Distinction from reflect: Dream is a separate preview feature where candidates are generated for user inspection, and nothing is saved without explicit human confirmation. In contrast, the reflect maintenance pass (/docs/tools/reflect) is an internal tool whose summarize action reads active episodic memories and writes source-grounded summaries under reflections/episodic. For recurring facts, reflect provides an episodic-to-semantic promote action requiring average importance of at least 0.35 and average confidence of at least 0.6. Its lifecycle actions execute expire, decay, and archive, with dry_run providing safe planning without destination writes.
• Architectural boundary: Dream candidate generation is strictly a preview mechanism and does not implement a speculative Light, REM, or Deep multi-pass architecture or autonomous background mutations.
• Safe failure posture: If a run stops or encounters an issue, existing memory remains untouched ("Dream stopped safely. Existing memory was not changed.").

Account availability, plan catalog status, and preview boundaries

Dream operates strictly if Dream is enabled for your account. All runtime controls default to off in production environments. Public documentation avoids exposing internal configuration flags.

• Account availability: Dream operates strictly if Dream is enabled for your account. If the feature is not active for a workspace, the console displays: "Dream is not enabled for this workspace yet. Your memory remains unchanged."
• Catalog status: In the product plan catalog, Dream is not included in the Free tier, while the Plus tier lists Dream capabilities. However, documentation makes no claim that Plus unlocks Dream in practice today, because the personal fallback provider denies access when commercial enforcement is inactive.
• Defect boundary: Dream is currently in preview and may not generate candidates for your account yet. Model-based synthesis cannot run directly in the shipped worker environment, and candidate confirmation depends on server capacity configuration.
• Strict human confirmation: The system enforces a strict human confirmation boundary. Documentation rejects all claims of automatic saving or background appending; every proposed item requires manual user consent.

Run lifecycle, evidence eligibility, and filter reason codes

A Dream run reviews eligible memory evidence across a configurable observation window (defaulting to 30 days) to identify recurring patterns without altering source records:

• Evidence collection: A preview run examines active, recallable episodic memories created within the observation window (customizable via --window-days up to 365 days).
• Grounded candidates: Eligible evidence is grouped into recurring themes, generating candidate items displayed with source lineage and a confidence score ("Confidence Score").
• Why evidence was filtered: In the console, the run summary reports "Why evidence was filtered" using standardized reason chips: score below threshold, insufficient occurrences, insufficient evidence days, insufficient query contexts, duplicate candidate, source not episodic, source inactive, and contradiction detected.
• Content-free run summary: Completed runs display a review summary: "Dream reviewed {{considered}} signals, generated {{generated}} grounded candidates, and saved {{promoted}} confirmed memories." accompanied by the safety guarantee: "This report is review-only and never becomes Dream evidence."

Console operating modes and scheduling presets

Dream settings provide granular control over execution modes and evaluation schedules within the console settings drawer:

• Operating modes: Users select between two behavior modes: "Preview only" (evaluates evidence and generates reviewable candidates without write permissions) and "Allow explicit confirmation" (enables the confirmation interface so users can review and selectively commit individual candidates).
• Scheduling presets: Execution frequency is configured through three presets: "Manual only" (runs solely on demand when selecting "Run Preview" in the console or issuing a CLI preview command), "Daily around 03:00" (scheduled daily run evaluated around 03:00 in the user local timezone), and "Weekly on Monday around 03:00" (scheduled weekly run evaluated on Mondays around 03:00 in the user local timezone).
• Scheduled run restriction: Scheduled runs operate in preview only mode; background schedule evaluations never commit memory writes or bypass human review.
• Timezone anchoring: Scheduled runs use the user browser local timezone.

Confirmation workflow, typed outcomes, and destination lifecycle

Committing candidates is append-only and requires explicit user action. The console supports single-item confirmation and optional typed outcomes:

• Core confirmation: In standard preview mode, clicking the "Confirm and save" button on a candidate card creates a NEW memory record under path dream/confirmed/... with semantic key dream:confirmed:... . Source memories are never edited or overwritten.
• Typed outcomes configuration: When typed outcomes are available, the settings drawer presents the question "What should Dream prepare?" with the guidance "Choose what to generate. Turning a type off keeps existing drafts and saved content."
• Six generation choices: (1) Preferences: "Clarify your preferences"; (2) Knowledge: "Distill knowledge worth keeping"; (3) Skills: "Turn experience into reusable skills"; (4) Projects: "Organize project memory"; (5) Patterns: "Discover lasting patterns"; (6) Durable Memory: "Build reusable long-term memory".
• Generation switch vs destination consent: Enabling a generation switch does not grant consent to a destination; all prepared results appear under "Prepared for your review" requiring manual review.
• Candidate review actions: Reviewers can select "Save edits" to modify proposed titles and content, "Review later" to defer, "Reject" to discard, or accept into the target destination.
• Per-destination acceptance: Knowledge accepts via "Add draft to knowledge base" into a chosen knowledge base as a DRAFT (with search indexing states: "Saved. Preparing for search.", "Search index is ready. Publication is a separate choice.", "Saved, but indexing needs another attempt."); Skill accepts via "Add draft to Cloud Skills" as a DRAFT; Project accepts via "Confirm project organization" (the project associate outcome is the one path that reassigns existing memories to a project workspace); Memory accepts via "Save as memory".
• Removal: Confirmed results become standard memories, knowledge drafts, or skill drafts in their respective stores. They are deleted using standard console or API removal actions; there is no Dream-specific rollback or undo mechanism.

Workspace isolation, Team boundaries, and CLI operations

Workspace permissions and CLI tools enforce strict multi-tenant boundaries and role capabilities:

• Workspace scoping: The console header identifies the active workspace as either "Personal space" or "Team space".
• Team permissions: In Team spaces, only Team owners and admins can modify Dream settings, cancel active runs, or confirm candidate memories ("Only Team owners and admins can change Dream settings.").
• Team typed outcomes limitation: Typed outcomes are not available in Team spaces. Team workspaces operate in preview-only or v1 memory confirmation mode.
• Verified CLI commands: The xmemo CLI (pinned commit d412c7866b7a4c8eedb3a0cf40748c6aef8707ec, src/commands/dream.js) supports three verified commands: xmemo dream preview [--window-days <n>] [--wait] [--json] (triggers preview; fails closed if preview is disabled with "Dream preview is disabled; CLI will not change Dream settings."), xmemo dream show <run-id> [--wait] [--json] (displays candidate items; supports --receipt-out for read receipts), and xmemo dream apply <run-id> --item <id> --from <view.json> --yes [--json] (confirms a candidate using the v1 confirm endpoint).
• CLI operational boundaries: The CLI cannot alter Dream configuration settings (settings must be managed in the console), and dream apply operates exclusively with v1 memory confirmation (does not perform typed outcome mutations).

# Trigger a candidate preview across a 30-day window
xmemo dream preview --window-days 30 --wait --json

# Inspect candidate proposals and record a read receipt
xmemo dream show <run-id> --receipt-out receipt.json

# Confirm a candidate proposal into memory via v1 confirmation
xmemo dream apply <run-id> --item <item-id> --from view.json --yes