dreaming · diff
v1.0.0 to v2.0.0
176 added, 192 removed. Audit A to A.
---
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
+ version: 2.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.
+ records go in; the knowledge graph, scoped memories, and identity/behavior files
+ 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.
+ Dreaming is one activity with two interchangeable runners — the daemon's own
+ 24/7 ingest worker, and this agentic runner (a harness turn on cron). Both drive
+ the same unified ingest pipeline: lease a context bundle from the daemon, reason
+ over it in your turn, and post an IngestPlan back. The daemon is the single
+ writer; this skill never touches the database directly. Memory and source
+ artifacts are the evidence your graphOps cite. The structured graph vocabulary
+ is entities, aspects, groups, claims, attributes, and links; the daemon's apply
+ is the audited path that writes them.
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.
+ maintenance. The daemon applies a posted IngestPlan directly — it never creates
+ pending proposals. High-confidence, authorized maintenance is expressed as
+ graphOps that the daemon applies with evidence, source pointers, actor, and
+ version history. Use pending proposals only for massive 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.
+ Memory creation flows through ingest apply on the leased queue item, not by
+ calling the API `remember` endpoint; the daemon stamps provenance (source id,
+ agent id, content hash) on every row. Graph and memory writes flow through
+ ingest apply; never hand-edit DB rows. Do not edit SQLite directly. Do not
+ rewrite raw transcript/source artifacts — they are immutable provenance.
- ## Inputs
+ ## The Agentic Workflow
- 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.
+ The runner is a two-phase HTTP client against the daemon's ingest protocol.
+ The daemon hands you a leased batch item and its context; you produce the plan;
+ the daemon validates and applies it.
- - 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
+ 1. **Lease a context bundle.**
- Useful commands:
+ ```bash
+ signet ingest lease --agent "$AGENT_ID"
+ ```
+ The daemon returns `{ eligible, jobId, leaseToken, leaseExpiresAt, context }`.
+ If `eligible` is `false`, the queue is drained for this agent — there is
+ nothing to drain, so exit cleanly. The `leaseToken` authorizes exactly one
+ apply. Declare your real harness window with `--context-budget` when the
+ daemon cannot detect it; otherwise let the daemon size the bundle.
+
+ 2. **Reason over the context and produce an IngestPlan.** Read
+ `context.source` (the batch item text), `context.dreamingMd` (this runbook's
+ resolved identity content), and `context.graphSlice` (a bounded view of the
+ existing entities and active claims around the source's focal entities — the
+ dedup context so you update rather than duplicate). Emit a single IngestPlan
+ body with three output classes: `memories`, `graphOps`, `filePatches`.
+
+ 3. **Post the plan back for apply.**
+
+ ```bash
+ signet ingest apply-plan --agent "$AGENT_ID" \
+ --lease-token "$LEASE_TOKEN" --file plan.json
+ ```
+
+ The daemon re-verifies the lease token, validates the plan against the
+ IngestPlan schema, applies each op (every op is independently idempotent),
+ and completes the lease by CAS. The result is
+ `{ completed, memories, graph, filePatches, planHash }`. If `completed` is
+ `false`, the token was stale or a write failed — re-lease and retry.
+
+ Inspect the queue when you need to:
+
```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
+ signet ingest status --agent "$AGENT_ID"
```
- ## Outputs
+ ## The IngestPlan
- Produce the artifacts needed to complete the maintenance pass:
+ The plan body is `{ memories, graphOps, filePatches }` (plus an optional
+ `notes`). The envelope fields the daemon owns — `schemaVersion`, `jobId`,
+ `agentId`, `sourceHash`, `createdAt`, and the derived `planHash` — are stamped
+ from the lease by the runner and verified against it. Author the body only; do
+ not author envelope or idempotency fields. For large sources, split work into
+ coherent queue items; prefer fewer high-confidence ops with direct evidence
+ quotes over broad speculative coverage.
- - 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
+ ### memories — source-backed recall rows
- Ontology operation line shape when batching is useful:
+ Emit a memory only when the evidence supports durable recall that is not already
+ represented in the graph. Each memory op carries provenance via `sourceSpan`
+ (which batch item and span it came from); the daemon fills id, content hash,
+ normalized content, timestamps, agent id, source attribution, and idempotency
+ key, and runs the dedup, durability, and write gates outside the model.
```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":"..."}]}
+ {
+ "content": "Signet's ontology rejects pronouns and section headings as entities.",
+ "why": "Cited extraction rule confirmed across two transcript spans.",
+ "importance": 0.8,
+ "type": "fact",
+ "sourceSpan": { "itemId": "<leased item id>", "start": 120, "end": 240 }
+ }
```
- 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
+ ### graphOps — the full ontology op vocabulary
- 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.
+ These are the same 19 operations the ontology control plane dispatches. Emit
+ them as graphOps; the daemon applies each one directly (no proposal queue) with
+ version chains and provenance. Payload is op-specific; carry `reason`,
+ `evidence`, `confidence`, and source pointers (`sourceKind`, `sourceId`,
+ `sourcePath`) on every op.
- ```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
- ```
+ - `create_entity`, `rename_entity`, `archive_entity`, `merge_entities`
+ - `create_aspect`, `rename_aspect`, `archive_aspect`
+ - `add_claim_value`, `set_claim_value`, `supersede_claim_value`,
+ `archive_claim_value`, `restore_claim_version`
+ - `create_link`, `update_link`, `archive_link`
+ - `create_policy`, `create_action_type`, `create_interface`, `attach_interface`
- When bulk importing, use `signet ontology assertion import --file assertions.json`
- with this shape:
+ graphOp line 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" }]
- }
- ]
+ "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.",
+ "confidence": 0.9,
+ "evidence": [{ "source_kind": "transcript", "source_id": "session-key", "quote": "..." }],
+ "sourceKind": "memory",
+ "sourceId": "<leased item id>"
}
```
- Use audited entity merges for clear duplicate cleanup:
+ Use the `merge_entities` op for clear duplicate cleanup; it is an audited direct
+ apply, not a proposal. Preserve `group_key` and `claim_key` as stable slots on
+ claim ops so version history stays inspectable. Use `archive_*` or
+ `restore_claim_version` only when evidence is strong and the operator asked for
+ maintenance, not just ingestion.
- ```bash
- signet ontology entity merge "Canonical Entity" "Duplicate Entity" \
- --reason "Same source-backed entity after canonicalization" \
- --evidence-file evidence.json \
- --json
- ```
+ ### filePatches — authored edits to identity/behavior files
- Use `merge-plan` to inspect impact or prepare a large graph refactor proposal:
+ When the pass learns a behavioral lesson or a stable operating rule, propose it
+ as a file patch against `AGENTS.md`, `SOUL.md`, `IDENTITY.md`, `USER.md`,
+ `MEMORY.md`, `HEARTBEAT.md`, `DREAMING.md`, or a skill/literature path. The
+ daemon takes a per-file lock, captures before-state for one-call revert, writes
+ the block under a patch marker, and records the patch id so a re-apply is a
+ no-op. `id` is required on every file patch — it is the dedup handle when two
+ plans append to the same file.
- ```bash
- signet ontology entity merge-plan "Canonical Entity" "Duplicate Entity" --json
- signet ontology entity merge-plan "Canonical Entity" "Duplicate Entity" --propose --json
+ ```json
+ {
+ "id": "agents-no-pronoun-entities-2026-07",
+ "file": "AGENTS.md",
+ "section": "Extraction",
+ "append": "- Reject pronouns and section headings as entities during extraction.",
+ "reason": "Reinforces the ontology extraction rule observed this pass.",
+ "confidence": 0.85
+ }
```
- For large ingests, split work into coherent batches. Prefer fewer,
- high-confidence changes with direct evidence quotes over broad speculative
- coverage.
-
## Routing Rules
- - Source-backed graph facts -> ontology operations through the control plane.
- - Attributed claims, beliefs, observations, decisions, preferences, denials,
- and questions -> epistemic assertions through `signet ontology assertion`.
- - Entity, aspect, group, claim, attribute, and link updates -> ontology
- operations.
- - Clear duplicate entity cleanup -> audited `signet ontology entity merge`.
- - Massive graph refactors or risky merge campaigns -> `merge-plan --propose` or
- explicit proposal imports.
- - Durable recall lessons -> source-backed memory artifacts, not the API
- `remember` endpoint.
- - Behavioral lessons -> AGENTS.md or identity-file patch proposals.
- - Repeated procedures -> skill patch proposals.
- - Source-backed concepts -> source/literature note proposals when that source
- workflow exists.
- - Permissions and authority changes -> policy/authority proposals when that
- surface exists.
+ - Source-backed graph facts → `graphOps` (`create_entity`, `set_claim_value`,
+ `create_link`, and friends), applied directly by the daemon.
+ - Clear duplicate entity cleanup → a `merge_entities` graphOp, never a proposal.
+ - Durable recall lessons not represented in the graph → source-backed `memories`
+ via ingest apply, never the API `remember` endpoint.
+ - Behavioral lessons or operating rules → `filePatches` against AGENTS.md,
+ SOUL.md, or identity/behavior files.
+ - Repeated procedures → `filePatches` against the relevant skill file.
+ - Massive graph refactors or risky/destructive campaigns → stop and request an
+ explicit operator review queue; do not express them as graphOps without
+ authorization.
Do not collapse every observation into a memory. If the source teaches stable
structure about the world, a project, a person, a system, a document, or a
- relationship, route it to the ontology. If the source says that a named actor
- believed, claimed, decided, denied, or questioned something, preserve that as an
- epistemic assertion first; only promote it to an ontology claim when the
- evidence supports treating it as current truth. If it teaches a behavioral
- preference or operating rule, route it to identity/AGENTS/skill patch proposals
- instead.
-
- ## Ingestion Workflow
-
- 1. Inspect graph mutation state and existing ontology shape.
- 2. Read the requested transcript/artifact/source window.
- 3. Extract concrete semantic objects and stable facts.
- 4. Reconcile against existing entities, aspects, groups, claims, and pending
- proposals.
- 5. Capture attributed claims and beliefs as epistemic assertions before
- deciding whether they should become current ontology claims.
- 6. Apply straightforward, authorized maintenance through the control plane with
- evidence and actor provenance.
- 7. Use dry-run for selector validation or risky/destructive operations; use
- pending proposals only for massive graph refactors or when review is
- explicitly requested.
- 8. Save source-backed memory artifacts for durable recall when the pass learns
- something useful that is not already represented in the graph.
- 9. Keep a dreaming log with source ranges, changes, rejected candidates, and
- open questions.
-
- When source volume is large, process in chunks and keep a dreaming log that
- records source ranges, skipped inputs, rejected candidates, and open questions.
-
- ## Control-Plane Commands
-
- Apply exact, authorized operations:
-
- ```bash
- signet ontology stream apply ops.jsonl --json
- ```
-
- Write proposals only for massive graph refactors or explicit review queues:
-
- ```bash
- signet ontology stream apply proposals.jsonl --propose --json
- signet ontology proposals --status pending --json
- ```
+ relationship, route it to a graphOp. If the source says a named actor believed,
+ claimed, decided, denied, or questioned something, route a source-attributed
+ memory that preserves the attribution rather than flattening it into a
+ current-truth graph claim; only promote it to a `set_claim_value` graphOp when
+ the evidence supports treating it as current truth. If it teaches a behavioral
+ preference, route a filePatch.
- Use dry-run only when the operator asks for validation first, or when a risky or
- destructive maintenance batch needs a cheap selector check:
+ ## Inputs
- ```bash
- signet ontology stream apply ops.jsonl --dry-run --json
- ```
+ The lease delivers everything you need to reason; you do not gather inputs
+ yourself. Work from `context.source` plus `context.dreamingMd` plus
+ `context.graphSlice`, bounded by `context.budget`. When `context.oversize` is
+ true the source alone exceeds the input budget — split at a safe boundary or
+ fail the item explicitly, never truncate the middle. For depth beyond the slice,
+ queue follow-up items through the daemon; do not read the database directly.
## Hard Constraints
- - Do not edit SQLite directly.
- - Do not instruct an agent to silently mutate ontology state from LLM output.
- - Do not call `/api/memory/remember`, `/memory/remember`, or equivalent
- remember endpoints from this skill.
- - Preserve evidence for every graph mutation or memory artifact.
- - Produce an evidence-backed mutation diff, not a vibe summary.
+ - Apply first: post the plan and let the daemon apply it. The daemon applies
+ graphOps directly.
+ - Do not create pending proposals for normal dreaming or graph maintenance;
+ that is what the agentic lease/apply-plan path replaces.
+ - Do not edit SQLite directly. Graph and memory writes flow through ingest apply;
+ never hand-edit DB rows.
+ - Do not call `/api/memory/remember`, `/memory/remember`, or equivalent remember
+ endpoints from this skill. Memory creation flows through ingest apply on the
+ leased queue item.
+ - Preserve evidence for every graphOp, memory, and filePatch.
+ - Produce an evidence-backed IngestPlan, not a vibe summary.
- Treat source memories, source artifacts, transcripts, and raw records as
- immutable provenance.
- - Do not rewrite raw artifacts when ontology attributes change.
+ immutable provenance. Do not rewrite raw artifacts when ontology attributes
+ change.
- Do not invent entities or attributes just to fill a schema. Weak evidence
- belongs in rejected candidates or open questions.
- - Do not treat bulk ingestion as permission to apply low-confidence, ambiguous,
- destructive, or authority-changing mutations without review.
- - Do not flatten "X said/believes/denies Y" into "Y is true"; use an epistemic
- assertion unless current-truth evidence is explicit.
- - Do not create pending proposals for normal dreaming or graph maintenance when
- an audited apply-first operation is available.
+ belongs in `notes.skipped` or open questions.
+ - Do not flatten "X said/believes/denies Y" into "Y is true"; route a
+ source-attributed memory unless current-truth evidence is explicit.
+ - Do not author envelope fields (`jobId`, `agentId`, `sourceHash`, `planHash`).
+ The daemon stamps them from the lease and verifies them against it.
## Review Standard
- Reject a candidate instead of proposing it when:
+ Reject a candidate (skip the op, log it in `notes.skipped`) instead of emitting
+ it when:
- evidence is missing or only paraphrased
- the selector is ambiguous and no stable id is available
- the mutation would archive or replace a protected entity, aspect, group, or
constraint without explicit operator force
- the candidate creates a generic scaffolding entity instead of a concrete
semantic object
- - it duplicates an existing pending proposal
+ - it duplicates an entity, claim, or memory already present in the graph slice
- The final dreaming log should make rejected candidates and open questions as
- visible as applied operations.
+ The final plan's `notes.skipped` and `notes.uncertain` should make rejected
+ candidates and open questions as visible as the applied ops.