dreaming

# 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:

```bash
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:

```json
{"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.

```bash
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:

```json
{
  "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:

```bash
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:

```bash
signet ontology entity merge-plan "Canonical Entity" "Duplicate Entity" --json
signet ontology entity merge-plan "Canonical Entity" "Duplicate Entity" --propose --json
```

For large ingests, split work into coherent batches. Prefer fewer,
high-confidence changes with direct evidence quotes over broad speculative
coverage.

Episodic memories may carry a structu