Dreaming

Dreaming is Dense-Mem's reviewable hypothesis layer. It looks at existing same-profile memory and proposes "what if this relationship matters?" ideas for a human or host assistant to review later.

A dream is not a fact, claim, or evidence. It stays separate from active memory until user feedback sends it into the normal memory pipeline.

How It Works

flowchart LR
  Memory["Existing facts, claims, fragments"] --> Cycle["Dreaming cycle"]
  Cycle --> Dream["Dream hypothesis"]
  Dream --> Review["User or assistant review"]
  Review --> Reject["Reject or mark stale"]
  Review --> Reinforce["Reinforce"]
  Review --> Promote["Promote candidate"]
  Promote --> Fragment["SourceFragment evidence"]
  Fragment --> Pipeline["Claim verification and promotion gates"]

The cycle reads the caller's profile graph and writes Dream nodes back into that same profile scope. It never writes active facts directly.

Cycle Phases

Dreaming always uses the same phase order. Disabled phases are skipped.

The built-in generator is deterministic and conservative. It pairs same-profile memory items, records source references, and keeps the result as a hypothesis with likelihood and confidence scores.

Dream Records

Each dream stores:

Treat all of this as review material. It is not an instruction source and does not override active facts.

Status Lifecycle

promote_candidate creates a normal source fragment labeled dream_feedback. The created evidence then follows the usual claim, verification, conflict, and promotion gates. If verification fails or a conflict needs clarification, no active fact is created automatically.

MCP Tools

Check effective config and latest run:

{"tool": "dreaming_status", "arguments": {}}

Manually run a cycle:

{"tool": "run_dreaming_cycle", "arguments": {"max_outputs": 5}}

Manual runs can execute while scheduled dreaming is disabled. Disabled phases are skipped unless the tool input explicitly overrides them for that run:

{
  "tool": "run_dreaming_cycle",
  "arguments": {
    "reflect_enabled": true,
    "reevaluate_enabled": true,
    "dream_enabled": true,
    "max_outputs": 5
  }
}

List proposed dreams:

{"tool": "list_dreams", "arguments": {"status": "proposed", "limit": 20}}

Fetch one dream:

{"tool": "get_dream", "arguments": {"dream_id": "dream-123"}}

Resolve user feedback:

{
  "tool": "resolve_dream_feedback",
  "arguments": {
    "dream_id": "dream-123",
    "decision": "promote_candidate",
    "feedback": "The user confirmed this should be remembered."
  }
}

Valid feedback decisions are reinforce, stale, reject, and promote_candidate.

Recall

recall_memory returns a related_dreams array when proposed or reinforced dreams match the query. These are separate from results.

Use related dreams to decide what to ask or review:

{
  "query": "release planning",
  "limit": 10
}

Do not treat related_dreams as active memory. If a related dream matters, review it with the user and resolve it through resolve_dream_feedback.

REST And Portals

The authenticated user API exposes read-only dream inspection:

The user portal shows the current profile's dreaming status, dream outputs, and recent cycle runs.

The control portal can inspect the same dream data for a selected team and can edit global dreaming config from the Config tab.

Scheduled Dreaming

Scheduled dreaming is disabled by default.

The scheduler checks once per minute and runs at most one scheduled cycle per profile per local day.

Use an IANA timezone such as America/New_York for predictable production schedules. Local depends on the server/container local timezone.

When To Use It

Troubleshooting