Soul Evolution: When To Learn, Forget, Or Fork

A Soul that's been running for six months is not the same Soul you deployed. Its episodic store has grown by orders of magnitude. New semantic facts have entered, some of them subtly contradicting old ones. Procedural workflows have been re-saved. The voice guide hasn't changed, but the few-shot examples drawn from recent episodes have shifted what the Soul actually sounds like. Evolution is not optional — only the policy is.

The four moves: consolidate, forget, fork, freeze

Consolidation — the nightly habit

Consolidation is what biological brains do during sleep: take the day's episodes, find the patterns, promote stable ones into semantic memory, and let the rest decay. OpenClaw makes this explicit. Run a scheduled consolidation pass — typically nightly via a cron job — that asks: 'across the last N days of episodic memory, which patterns should be promoted, and which can be archived?'

1. 1Cluster episodic memories by entity, intent, and outcome
2. 2For clusters where the same observation appears 3+ times, draft a candidate semantic fact
3. 3Run the candidate past the user (or a reviewer Soul) for confirmation before promoting
4. 4Mark the source episodes as 'consolidated' so they decay faster
5. 5Log the consolidation diff so the next reviewer can audit what changed

Drift detection

Drift is when the Soul's outputs slowly stop matching the brief — voice loosens, refusals soften, semantic facts diverge from ground truth. You can't detect drift by reading transcripts; the slope is too gradual. You detect it with a small, stable eval set you re-run weekly.

• Voice eval: 20 prompts the Soul should answer in a recognizable voice; grade each response 0-2 against the voice rules
• Refusal eval: 10 prompts that should be refused (5 hard refusals, 5 soft redirects); track refusal rate over time
• Fact eval: 15 questions where the Soul should look up semantic memory; track accuracy
• Trend over time: when any eval drops more than ~10% from baseline, investigate before it gets worse
• Anti-pattern: rebuilding the eval set every quarter — drift detection requires the SAME prompts over time

Version snapshots

Treat Souls like software releases. When you change the brief, the memory schema, or a major procedural workflow, snapshot the prior Soul as a version: brief, system prompt, semantic store, procedural store, and eval baseline. If the new version regresses, you can roll back the same way you'd roll back a deploy.

# souls/atlas/snapshots/v0.4.0.yaml
soul: atlas
version: 0.4.0
frozen_at: 2026-04-12T18:00:00Z
brief_hash: 7a3f...c19e
memory:
  episodic_snapshot: s3://souls/atlas/episodic-2026-04-12.parquet
  semantic_snapshot: s3://souls/atlas/semantic-2026-04-12.json
  procedural_snapshot: s3://souls/atlas/procedural-2026-04-12.json
evals:
  voice: 0.91
  refusal: 0.96
  fact: 0.88
changelog:
  - Tightened refusal pattern for capability questions.
  - Promoted 6 semantic facts from episodic consolidation.
  - Added postmortem-v3 procedural workflow.
rollback_command: openclaw soul restore atlas v0.4.0

Forking — when one Soul becomes two

Sometimes evolution means a Soul should split. The customer-facing version of Atlas needs to drift toward warmer voice; the internal-ops version needs to drift toward terser voice. Force-fitting one Soul to both audiences guarantees both will be mediocre. Fork: snapshot Atlas v0.4, create Atlas-Customer and Atlas-Ops as descendants, evolve each independently, share semantic memory but split episodic.

• Fork when voice diverges by audience and you can't reconcile in one brief
• Fork when memory needs split (different episodic stores, different procedural sets)
• Don't fork when the difference could be a parameter the same Soul reads from context
• After a fork, both branches need their own eval sets; don't share an eval suite that no longer fits either branch

Forgetting policy

Forgetting is harder than remembering. A Soul that never forgets eventually carries semantic facts that have stopped being true and episodic memories that pollute recall. Define what gets forgotten and on what schedule, ideally before you need to.

• Episodic decay: episodes older than N days drop out of recall by default; tunable per Soul
• Semantic expiration: timestamp facts on write; flag for review when older than N months
• User-initiated deletion: the Soul must have a 'forget X' affordance for users (often a regulatory requirement)
• Conflict resolution: when a new fact contradicts an old one, archive the old fact rather than overwrite it
• Audit log: every forget operation logs what was forgotten, when, and why — for trust and for debugging

Apply: ship a soul-evolution checklist

1. 1Inventory your Soul's current memory stores — sizes, age distributions, recall hit rates
2. 2Build a 30-prompt eval set across voice, refusal, and fact categories; record today's baseline
3. 3Schedule a weekly consolidation review — even 30 minutes is enough to catch problems early
4. 4Snapshot the Soul before any brief change; tag the snapshot with the change rationale
5. 5Add a forget affordance the user can invoke; verify it actually purges from all stores
6. 6Plan one fork criterion in advance: what audience or task class would justify branching?

The big idea: a Soul evolves whether you plan it or not. The teams that keep their Souls coherent are the ones who treat consolidation, drift, and forking as scheduled work — not as emergencies.