Dream

Dream is Lore's scheduled memory maintenance. Every night it reviews the memory graph, applies a few careful fixes, and writes a diary entry that you can review and roll back.

What a run doesCopy Anchor Link

A run starts by collecting the boot memories (the baseline that agents load at session start), the last day of recall and memory activity, a path-quality summary, a structural audit, a memory hygiene audit, and the five most recent completed diary entries. An agent then works through five phases with the memory tools:

1. Diagnose reads recall queries, the hygiene audit, the structural audit, and the memory tree. It can replay real recall queries to see what the current tree would surface. It makes no changes.
2. Plan lists candidate changes in three groups — structure, merge, and glossary — plus the categories it skipped and why. When the hygiene audit finds something actionable, the plan includes a candidate for it or explains why it is left alone. It makes no changes.
3. Preflight checks each proposed write with the same validation that normal memory writes get.
4. Apply makes the changes, structure first. A run is capped at two content changes (create, content update, delete, or restructuring move) and twelve hygiene-only operations (glossary trims and moves out of a non-canonical domain). At most one oversized node is split per run.
5. Audit records what changed and why. Lore then writes a diary entry with a summary and a narrative.

Dream works on the tree, not on today's prompts. Agents already write memories with full context while they work, so Dream does not extract new memories from the day's queries.

Dream looks for these problems:

• memories stranded in a domain outside project://, core://, and preferences://, to move into their canonical home
• parent nodes that are only a placeholder, to fill with a real abstraction distilled from their children
• memories longer than 4,000 characters, to condense into a current-state summary plus a history section
• clear duplicates or near-duplicates to merge, replaying the affected queries before and after
• glossaries with more than 30 keywords, to trim duplicates, near-synonyms, and generic words
• keywords shared by eight or more nodes that belong on a shared parent instead
• date-suffixed paths and project concepts misplaced under core://projects

Dream reads recall queries from the past day. It doesn't read full conversations, and it never writes recall logs. Replay is read-only.

Dream applies its changes itself. The priority and disclosure checks that apply to your writes also apply to Dream's writes. Each change is recorded in the node's history and listed in the diary entry with its review mark.

Glossary trimmingCopy Anchor Link

A glossary keyword is a recall entry point, not a tag. Each keyword is embedded on its own and feeds semantic recall, and its text also feeds exact, contains, and BM25 matching. A keyword list that grows without limit pulls the memory into prompts it has nothing to do with. Dream therefore only trims: it removes duplicates, near-synonyms, and generic words from glossaries above 30 keywords.

Identifier-like keywords — hashes, version numbers, host:port addresses, paths, all-caps tokens, and hyphenated tokens with digits — are different. They match only when someone types that identifier, so Dream keeps them and never adds new ones. Adding any other keyword requires replay evidence that a real query failed to surface the node.

Schedule and settingsCopy Anchor Link

Dream is on by default and runs every day at 03:00. It needs an LLM: a View LLM on a self-hosted server, or the runtime LLM profile on Loremem Cloud. On a self-hosted server, a run without a View LLM skips the agent loop, so it makes no changes.

On a self-hosted server, these are under Settings → Dream schedule, labeled Scheduled dreaming, Dream cron, Auto-approve Dream changes, and Excluded Dream sessions. On Loremem Cloud, use Settings → Dream.

A few details to know:

• On a self-hosted server, the cron expression runs in the server's time zone. Docker Compose reads TZ from .env and defaults to Asia/Shanghai if you don't set it, so set TZ to your own zone.
• On a self-hosted server, Lore checks the schedule once a minute. If the server isn't running at the scheduled minute, that day's run doesn't happen. An invalid cron expression never runs.
• Loremem Cloud runs schedules on the service clock.

Run Dream manuallyCopy Anchor Link

Run Dream by hand while you tune Lore, or after you import a batch of memories.

1. Open Dream and select Run Dream Now. On Loremem Cloud, select Run Dream.
2. Wait for the run to finish. Its status changes from Running to Completed or Error.
3. Read the diary entry, then review the changes.

A self-hosted server doesn't start a second run while one is still running.

Review changesCopy Anchor Link

Each change in a run has a review mark:

Select Approve or Dismiss to set a change's mark. Review marks only record your decision. Approving or dismissing a change doesn't undo it. The memory keeps the change until you roll it back or edit it.

To correct a change on a self-hosted server, select Edit to open the node and fix it by hand. On Loremem Cloud, open the node from the Memory page.

Judge a changeCopy Anchor Link

Check each change against this list before you approve it. Reject or rewrite any change that fails a check.

This memory fails the trigger check. Its disclosure names two situations, so the memory can surface when either one comes up:

URI:        project://checkout_api/webhooks
Priority:   1
Disclosure: When changing refund webhooks or payment webhooks in checkout-api
Glossary:   refund webhook, payment webhook, idempotency key
Content:    Refund webhooks are idempotent by event.id. Tests must replay the same event twice and assert a single refund row.

Split it into one memory for refund webhooks and one for payment webhooks.

Undo a runCopy Anchor Link

Rollback reverses the changes from the most recent run.

• Only the most recent run can be rolled back. Older runs can't be rolled back as a whole.
• Rollback reverses every change in that run, including changes you approved and the glossary keywords Dream removed or moved.
• Each affected node returns to its state before the run. Any edits you made to those nodes after the run are overwritten, so check them first.
• On a self-hosted server, open the latest run on Dream, select Rollback, and confirm. On Loremem Cloud, open the latest run and select Rollback latest.

To undo one change instead, roll back the node from its history:

• On a self-hosted server, open the node's history, select Rollback on the create or update event you want, and confirm. Only create and update events can be rolled back this way.
• On Loremem Cloud, the node's history shows each change as a diff. Edit the node to restore the earlier text.

Use Dream safelyCopy Anchor Link

1. Verify a backup before you turn on scheduled runs. Test a restore in a separate environment first. See Backups and restore.
2. Run Dream by hand a few times, and review every change, before you rely on the schedule.
3. Pause scheduled Dream while you import many memories, or while your embedding or LLM endpoints are unstable.
4. Keep auto-approve off until you trust the changes Dream makes.
5. After each run, try two or three realistic recall queries to confirm that the memories you care about still surface.