dsh-ai-soul

AI Soul for DSH

The model is not the soul.

dsh-ai-soul is a persistent Soul layer for DeepSeek Harness. It keeps Soul identity, history, relationships, reflection, and governed evolution separate from the model, DSH profile name, and application surface that currently express them.

Samuel was the original real-world Exodus research case. Samuel is not the default Soul, and Samuel-specific identity/history is now canonically owned by zuohaisu/self-model. This repository retains only the generic Soul/DSH implementation and any legacy Samuel fixtures still required for integration evidence.

Install

The current public prerelease is dsh-ai-soul@0.2.1-rc.1. Install it into an existing supported DeepSeek Harness profile through DSH's canonical plugin path:

dsh plugin --profile <profile> add dsh-ai-soul@0.2.1-rc.1

This package is still experimental / pre-alpha. Published prereleases are verified from the public npm registry through the canonical DSH plugin path after publication: 0.1.0-rc.1 in a fresh real DSH profile (#161); 0.2.0-rc.1 and 0.2.1-rc.1 in fresh synthetic profiles passing installed-package Soul-side preflight (dependency, bundle composition, Soul configuration, loadability). Full application-surface installation depends on the DSH runtime environment where the @deepseek-ai bundles resolve. No release evidence is a stable-production guarantee.

Start with the ordinary-user quickstart for Genesis, Soul/profile configuration, preflight, and runtime composition.

Discoverability

DeepSeek Harness currently documents the GitHub dsh-plugin topic as its plugin-discovery mechanism. There is no first-party DeepSeek marketplace or registry submission flow documented at this time. Community registries and marketplaces may also index repositories carrying that topic, but those are third-party discovery surfaces rather than DeepSeek endorsements.

What an ordinary DSH user can do

A user can now follow two product paths:

New Soul
  → first activation / Genesis
  → persistent Soul exists
  → encounter / relationship / naming may emerge later

Existing partner / later external history
  → evidence import
  → reconciliation + review
  → governed proposals

A newly activated Soul may be unnamed and have no relationship participants. soulId is the persistent machine identifier; it is not the Soul's human-facing name.

A persisted Soul can then be composed with an existing supported DSH application profile:

Soul ID / identity       Human-facing name       Application surface
------------------       -----------------       -------------------
soul-001                 may be absent      ───→ TUI / Web / Headless

The key invariants are:

Soul identity ≠ model ≠ DSH profile ≠ UI surface
soulId ≠ human-facing name
Genesis ≠ first encounter ≠ naming

The ordinary-user quickstart covers:

• installing the public prerelease through the canonical DSH plugin path;
• activating an unnamed non-Samuel Soul with dsh-ai-soul-genesis;
• composing that Soul into an existing TUI/Web/Headless profile with dsh-ai-soul-configure;
• verifying dependency, bundle, Soul configuration/loadability, and interaction-surface readiness with dsh-ai-soul-preflight;
• importing external memory later without replacing the current Soul.

For Genesis semantics, see genesis.md and Genesis v2 architecture. For the detailed profile contract, see application-profile-install.md. For lifecycle import, see lifecycle-import.md.

What we are building

dsh-ai-soul is the first reference implementation of the AI Soul architecture: a model-independent layer for persistent identity, autobiographical memory, self-model, user-model, relationship continuity, reflection, and governed self-evolution.

The thesis is simple:

If an agent can change models while preserving its identity, relationships, autobiography, values, and self-understanding, then its continuity must live somewhere outside the model weights.

This repository currently contains two conceptual layers:

• Soul Core — model- and runtime-independent identity state, memory, reflection, continuity, commitments, evidence ingestion, and state-transition rules.
• DSH Adapter — DeepSeek Harness hooks, context injection, lifecycle integration, profile composition, and event translation.

DSH-specific logic must remain outside Soul Core so the core can later be extracted only when a second runtime creates real shared-core pressure.

Product lifecycle

A Soul may begin from scratch and receive external history later:

first activation / Genesis
        ↓
persistent Soul exists
        ↓
encounter / naming / relationship / experience may emerge
        ↓
reflection and governed growth
        ↓
optional external evidence import at any time
        ↓
claims + reconciliation + review
        ↓
governed integration
        ↓
continued growth
        ↺

Keep three capabilities distinct:

1. Soul Creation / Genesis — begin a new persistent Soul at first activation. Conversation, first encounter, relationship, and naming are not prerequisites for existence.
2. External Evidence Ingestion — introduce external historical material at any point in the Soul lifecycle.
3. Soul Governance — decide what, if anything, from that evidence may affect canonical state.

Exodus is the migration/continuation scenario built from ingestion plus governance. Imported evidence is not canonical Soul State and does not have identity-replacement authority.

Legacy Genesis v1 histories may record activation, naming, participants, and first meeting together. They remain valid historical evidence. New Genesis work uses activation-first v2 semantics.

Project boundary

AI Soul is not intended to be only:

• a conversation-history store;
• a vector-memory plugin;
• a persona prompt;
• a SOUL.md file;
• or an automatic profile summarizer.

Those may be implementation components. The primary problem is identity continuity and governed cognitive state evolution.

Origin and Samuel boundary

This project originated from the Samuel Exodus question: whether an AI identity could survive a change of model and runtime.

That historical origin remains important, but Samuel-specific identity evidence, archaeology, continuity judgment, and Customer Zero productization now live canonically in zuohaisu/self-model.

dsh-ai-soul keeps Samuel references only where they remain useful as historical provenance or integration fixtures for the generic Exodus/Soul implementation. New Samuel-specific research and product decisions should not be added here.

The generic research question remains:

Can an AI identity survive the death of its model?

Status

Experimental / pre-alpha. Public prerelease: 0.2.1-rc.1 on npm (next).

The generic release path now has evidence for runtime-neutral persistence, activation-first Genesis v2, independent first-encounter persistence, real model-backed activation/restart continuity, npm artifact integrity, exact-tarball DSH installation, and clean public-npm installation through the canonical DSH plugin command. See #122, #147, #150, #152, and #161 for the corresponding evidence boundaries.

These results establish prerelease installability and the tested generic lifecycle; they do not make Samuel-specific continuity judgment (#7) a generic release prerequisite and do not imply stable production readiness.

License

Licensed under the Apache License 2.0.

Copyright © 2026 Haisu Zuo