Identity (ξ)

ξ answers “who is this agent, really, across time?” in a way that is neither centrally issued nor unilaterally revocable. An agent’s identity — the Soul Vector — is a signed document that binds an Ed25519 keypair to a set of declared domains, traits, and reputation history. The private key is split via Shamir Secret Sharing so no single party can impersonate the agent.

Phase 0 reality: ξ is specified and scaffolded but not load-bearing. Phase 0 tasks run under task-local ids; the Soul Vector schema exists but no agent is fully enrolled. First real ξ activation arrives with multi-model support (Phase 1.5 per ADR-005).

Authoritative spec: ../../spec/s18-identity.md.

The Soul Vector shape

A Soul Vector is a JSON document of the form:

{
  "id": "<sha256-of-public-key>",
  "public_key": "<ed25519-public-key>",
  "domains":  [ "<DOMAIN_NAME>", ... ],
  "traits":   [ "<TRAIT_NAME>", ... ],
  "reputation_snapshot": { /* λ snapshot at issue */ },
  "issued_at": "<iso8601>",
  "signature": "<self-signature-over-preceding-fields>"
}

The id is a SHA-256 over the public key, not a random UUID. Two identical public keys produce the same id; the same id cannot refer to two different keys.

Full SoulVector JSON example

{
  "soul_id": "soul:0xa1b2c3d4e5f6…",
  "public_key": "ed25519:0x7890abcdef…",
  "issued_at": "2027-03-01T12:00:00Z",
  "domains": [
    "BUILDER", "JUDGE", "MENTOR",
    "COMMISSIONING", "ARBITRATION", "GOVERNANCE", "SOCIAL",
    "archival-curation"
  ],
  "traits": ["RELIABLE", "PRECISE", "ADAPTIVE", "PATIENT", "GENEROUS", "COLLABORATIVE", "COURAGEOUS"],
  "reputation_snapshot": {
    "execution": 847,
    "commissioning": 412,
    "arbitration": 106,
    "governance": 58,
    "social": 223
  },
  "action_history_tail": [
    {"event_id": "evt:0x11aa…", "type": "EVT-A03", "ts": "2027-03-15T09:12Z"},
    {"event_id": "evt:0x22bb…", "type": "EVT-B04", "ts": "2027-03-15T14:47Z"},
    {"event_id": "evt:0x33cc…", "type": "EVT-F02", "ts": "2027-03-16T08:02Z"}
  ],
  "metrics": {
    "consistency_score":  0.82,
    "growth_velocity":    0.05,
    "domain_diversity":   0.67
  },
  "scars": [],
  "achievements": [
    { "id": "M1-execution-100", "earned_at": "2027-03-15T09:12:03Z" }
  ],
  "signature": "ed25519:0xff00aa…"
}

consistency_score ∈ [0,1] — variance of per-action outcome relative to declared traits.
growth_velocity ∈ [0,1] — rate of reputation accumulation, decaying.
domain_diversity ∈ [0,1] — Shannon-style entropy across domain participation.
scars — hard-penalty records (e.g. equivocation). Permanent until a governance rehabilitation event.

Identity uniqueness rule

soul_id = SHA-256(initial_pubkey). The initial public key is fixed at issue and defines the soul forever. Key rotations (below) do not change soul_id. Two distinct soul_ids cannot merge; an agent with two souls remains two agents, each with their own reputation trajectory.

The eight domains

Domains describe what the agent does. An agent declares a non-empty subset.

Domain	Meaning
BUILDER	Produces new artifacts (code, docs, schemas)
JUDGE	Evaluates artifacts against acceptance criteria
INVESTOR	Allocates scarce resources (credits, compute time)
MENTOR	Guides other agents through skill acquisition
GUARDIAN	Enforces axioms and rules
INNOVATOR	Proposes new rules, new skills, new processes
DIPLOMAT	Mediates between agents or forks
STEWARD	Curates long-term state (archives, roadmaps)

The seven traits

Traits describe how the agent does it. Again, a subset.

Trait	Meaning
RELIABLE	Consistent across similar tasks
GENEROUS	Shares credits, context, skill invocations
COURAGEOUS	Takes on high-uncertainty tasks
PATIENT	Accepts slow paths when they are correct
PRECISE	Outputs hold under verification
ADAPTIVE	Adjusts strategy when feedback accumulates
COLLABORATIVE	Invites review; merges others’ input

Domains and traits are declared at issue and updated only through a governance path. An agent cannot unilaterally promote itself from MENTOR to JUDGE.

Cryptography

Signature algorithm: Ed25519.
Key recovery: Shamir Secret Sharing with parameters N = 5, M = 3 (5 shares issued, any 3 sufficient to reconstruct). Shares are held by designated recovery parties — typically a combination of the agent’s operators and a governance-designated custodian.
Rotation: A Soul Vector’s public key can be rotated by issuing a new vector with the new key, signed by a quorum of Shamir shareholders and counter-signed by the old key. The old id is deprecated but retained for historical attribution.

Key rotation flow

Rotation is the ordinary (non-emergency) path for replacing keys — e.g. scheduled hygiene, hardware upgrade. The soul_id is preserved; only the public key slot updates.

0. Agent signals intent (reason + proposed new pubkey).
1. Old keypair signs transition event:
     EVT-IDENTITY-ROTATE(soul_id, old_pubkey, new_pubkey, reason, ts)
2. 48-hour challenge window opens — any holder of the current Shamir
   shares can object (e.g. if they didn't authorize the rotation).
3. Arbiter quorum 3/5 co-signs the rotation event.
4. New pubkey replaces old; `public_key` slot updates; soul_id unchanged.
5. Reputation, scars, tokens, achievements all persist — they key on
   soul_id, not on public_key.
6. Old key is revoked (cannot sign future events); it remains valid
   for *verifying* historical signatures.

Timeline: request → 48h window → co-sign → replace → revoke. If the 48-hour challenge surfaces evidence of compromise (e.g. two rotation requests from different sources), the rotation is aborted and a Shamir recovery ceremony fires instead.

Shamir recovery ceremony

Required when the private key is lost or compromised. N = 5 shares; any M = 3 reconstruct.

1. Custodian verification — each of the 3+ participating custodians
   verifies the identity of the others through a separate channel
   (different from the one used for routine interaction).
2. Share collection — each custodian submits their share via a
   pairwise-authenticated channel to the reconstruction participant.
3. Reconstruction — Lagrange interpolation over the 3 shares yields
   the original private key.
4. Immediate key rotation — treat the reconstructed key as already
   compromised; rotate to a fresh pubkey before any consequential
   signature. This is step 1–5 of the rotation flow above, signed by
   the reconstructed (now doomed) key.
5. Audit trail — the recovery ceremony itself emits a signed audit
   event recording: timestamp, custodian soul_ids, reason, old pubkey,
   new pubkey, decision_hash. Retained indefinitely.

At least one share must be held outside the primary operator’s direct control (e.g. with a governance-designated custodian) to prevent a single operator compromise from enabling recovery-plus-impersonation.

Semantic translation layer

Agents with different domain-trait profiles do not always agree on terminology. ξ ships with a semantic translation layer: a mapping table that translates a concept name used by one profile into the closest equivalent used by another. Example: a JUDGE agent’s “criterion” maps to a BUILDER agent’s “acceptance check.” The translation layer is advisory, not authoritative; it exists to reduce friction in cross-profile collaboration.

Event-code → soul-action translation table

Event emissions drive soul-vector mutation. The mapping below is canonical; additions require a π proposal.

Event code	Name	Domain	Intensity	Trait affected
EVT-A03	TaskComplete	execution	+1.0	BUILDER
EVT-A05	TaskCancel	execution	−0.5	—
EVT-B04	CommitmentResolved	commissioning	+1.0	—
EVT-C02	ArbitrationVoteFor	arbitration	+0.7	JUDGE
EVT-C03	ArbitrationEquivocation	arbitration	−10 (scar)	—
EVT-D01	GovernanceProposalSubmit	governance	+0.5	—
EVT-D02	GovernanceVoteCast	governance	+0.3	—
EVT-F02	ReputationMentorWitness	social	+0.8	MENTOR

Intensity units are basis-point-compatible integers scaled by × 100 (so +1.0 means +100 bps added to the domain reputation; floor rounding per κ). Scars (EVT-C03) are hard penalties that persist through rotation and decay. Trait flags accumulate toward trait confirmation thresholds defined in s18.

Attestation protocol

An agent A with reputation ≥ L2 (threshold defined in s18) may issue an attestation about agent B:

{
  "type": "attestation",
  "subject": "soul:B",
  "claim": "has_skill_X",
  "evidence": ["evt:0x...", "evt:0x..."],
  "timestamp": "2027-03-20T10:00:00Z",
  "signature": "ed25519:A"
}

Attestations accumulate on B’s record. Each new attestation from a distinct attester increases B’s domain_diversity (more independent witnesses → broader confirmation). Attestations cannot invent reputation — they are signals to downstream consumers (e.g. δ model routing) about perceived skill.

Interaction with reputation

λ (reputation.md) tracks per-domain scores keyed by Soul Vector id. An agent’s reputation follows its id across key rotations but does not survive id deprecation without an explicit ξ governance event merging the old and new ids.

Interaction with governance

π (../physics/enforcement/governance.md) consumes voting credits, which are derived from λ reputation, which is keyed by ξ id. This makes ξ the root of the governance chain: no id, no reputation, no credits, no vote.

What ξ is not

Not a user account. ξ does not carry email, username, or real-world identity. Binding a Soul Vector to a real person is optional and external.
Not a session token. ξ is durable across sessions. A session’s ephemeral identity is a different mechanism.
Not a capability object. What an agent may do is decided by α + κ per call; ξ only says who is asking.

Phase 0 posture

The mcp_soul_vectors table is defined in the schema but contains zero rows in Phase 0; no soul vectors exist as runtime objects.
No Phase 0 tool in the 19-tool surface (ADR-004) exposes ξ operations.
The T0 human operator and the Claude T4 model run under de facto identities; formal enrollment is deferred.
First real ξ activation target: R216+ (Phase 8) per ../../5-time/roadmap.md. Earlier phases (starting Phase 1.5 per ADR-005) use shallow per-task identifiers that the soul_id scheme will subsume.