/dreaming

name: dreaming
description: "Maintain Signet's living ontology and memory substrate from transcripts, memory artifacts, source artifacts, notes, summaries, and imported records."
version: 1.0.0
builtin: true

Dreaming

Use this skill when an agent should wake up, read accumulated source evidence, and turn it into Signet ontology structure. The job is flexible bulk ingestion: transcripts, memory artifacts, source artifacts, notes, summaries, and imported records go in; the knowledge graph, scoped memories, and maintenance trail get better.

Dreaming maintains the graph by turning source and memory artifacts into entities, aspects, claim attributes, and links. Memory artifacts are evidence for attributes; the ontology control plane is the audited path that applies those attributes to the graph.

Apply first with provenance is the blanket rule for dreaming and ordinary graph maintenance. High-confidence, authorized maintenance should use audited operation handlers that apply directly and preserve evidence, source pointers, actor, confidence, and version history. Pending proposals are only for massive knowledge-graph refactors, risky/destructive changes, or cases where the operator explicitly asks for review before mutation.

Dreaming may save memories when the evidence supports durable recall, but not by calling the API `remember` endpoint. Save explicit source-backed memory artifacts or use the configured source/import machinery so provenance remains inspectable. Do not rewrite raw transcript/source artifacts or edit SQLite directly.

Inputs

Gather enough source evidence and graph context to infer useful ontology structure. Prefer recent transcript and memory-artifact windows first, then expand to bulk source sets when requested.

• recently saved memories (remember/CLI/MCP/plugin saves are immutable episodic evidence)
• recent session summaries
• raw transcripts and transcript artifacts
• recently saved memory artifacts
• source artifacts
• imported notes, documents, literature, or other indexed source records
• source-attributed epistemic assertions
• applied operation, version, merge, and proposal history
• existing entities, aspects, groups, claims, attributes, and links
• knowledge graph hygiene reports
• retrieval failures or feedback when available
• recent dreaming pass logs when available

Useful commands:

signet ontology pipeline explain --json
signet knowledge objects --json
signet ontology assertions --limit 50 --json
signet ontology proposals --status pending --json
signet ontology proposals --status applied --limit 50 --json
signet ontology proposals --status rejected --limit 50 --json
signet knowledge hygiene --json
signet dream status

Outputs

Produce the artifacts needed to complete the maintenance pass:

• applied ontology operations or an operation stream for the daemon control

plane

• epistemic assertions for source-attributed claims that should not be

collapsed into current truth

• source-backed memory artifacts for durable recall when the evidence warrants

saving memory

• a dreaming log artifact with sources examined, changes made or proposed,

rejected candidates, and questions

• a short summary of high-confidence graph and memory changes
• rejected candidates with reasons
• explicit questions where evidence is weak
• optional AGENTS.md, identity-file, or skill patch proposals as written

artifacts, never as silent edits

Ontology operation line shape when batching is useful:

{"operation":"set_claim_value","payload":{"entity":"Signet","aspect":"architecture","group_key":"ontology","claim_key":"mutation_policy","value":"Dreaming and normal graph maintenance apply first through audited operations with provenance."},"reason":"Consolidated from cited transcript evidence.","evidence":[{"source_kind":"transcript","source_id":"session-key","quote":"..."}]}

Use one JSON object per line. Good operation streams usually contain a mix of:

• `create_entity` for concrete people, organizations, projects, tools,

documents, products, places, and events that do not already exist

• `create_aspect` for new coherent rooms of knowledge under an entity
• `set_claim_value` for attributes and constraints, preserving `group_key` and

`claim_key` as stable slots

• `create_link` for typed relationships between concrete entities
• `archive_*` or `restore_claim_version` only when evidence is strong and the

operator asked for maintenance, not just ingestion

Use epistemic assertions when the source says who claimed, believed, observed, decided, preferred, denied, or questioned something. Assertions preserve attribution; they do not automatically make the asserted content current truth.

signet ontology assertion create \
  --entity "Signet" \
  --predicate claims \
  --speaker "Nicholai" \
  --asserted-at "2026-05-16T19:36:00.000Z" \
  --content "Signet should model who believes what over time." \
  --confidence 0.91 \
  --source-kind transcript \
  --source-id session-key

When bulk importing, use `signet ontology assertion import --file assertions.json` with this shape:

{
  "assertions": [
    {
      "entity": "Signet",
      "predicate": "believes",
      "content": "Signet should model who believes what over time.",
      "speaker": "Nicholai",
      "asserted_at": "2026-05-16T19:36:00.000Z",
      "confidence": 0.91,
      "evidence": [{ "source_kind": "transcript", "source_id": "session-key", "quote": "who believes what" }]
    }
  ]
}

Use audited entity merges for clear duplicate cleanup:

signet ontology entity merge "Canonical Entity" "Duplicate Entity" \
  --reason "Same source-backed entity after canonicalization" \
  --evidence-file evidence.json \
  --json

Use `merge-plan` to inspect impact or prepare a large graph refactor proposal:

signet ontology entity merge-plan "Canonical Entity" "Duplicate Entity" --json
signet ontology entity merge-plan "Canonical Entity" "Duplicate Enti