Atlas
kb://products/identity-clone-labstable2026-05-22

Subproject idea — Identity Clone Lab (digital twin from media)

subprojectidentitydigital-twinvirtual-humanpersonablockchaindraft

Identity Clone Lab — draft subproject spec

Origin

NAO 2026-05-22 23:21:

«хотел суб проект тулзы для создания виртуальных личностей из картинок, видео, аудио и текста и ссылок, люди могли создавать детальные промпты себя как личностей и визуал и других людей и рандомные и как раз подпроект для нашей экосистемы а то подруга хочет себя оцифровать и я подумал нам нужна клонировочная для цифровых двойников и новых цифровых личностей и система паспортов с блокчейном даже может собственным»

Trigger: NAO's partner wants to digitize herself. NAO saw the opportunity to build a generalised "cloning lab" for the OpenAlice ecosystem — not just one-off digital twins, but a tool that lets any operator construct a detailed virtual person from raw media. Related to but distinct from kb://products/alice-persona (which is Alice's own character, a single hand-curated identity).

This note is the first-draft scope so the idea isn't lost. Nothing is committed.

Proposed pipeline

Input media + text                  → Personality model         → Outputs
────────────────────                  ───────────────────         ────────
- photographs (front / side / smile)  - speech prosody profile    - prompt
- short video (motion, expression)    - voice timbre + cadence     bundle
- voice samples (≥ 30 s clean)        - written-style patterns    - VRM
- written corpus (DM, blog, essay)    - personal-facts schema       avatar
- URL set (social / portfolio)        - relationship graph        - voice
                                      - aesthetic preferences       model
                                      - consent metadata          - passport

Three personality classes the tool produces:

  1. Self-clone — operator constructs their own twin (NAO's partner's use case).
  2. Other-clone — operator constructs a third party's twin (requires explicit consent capture — see passport system below).
  3. Random — operator seeds nothing and gets a coherent personality + visual (useful for brand NPCs, background characters in stream scenes, world inhabitants).

Use cases enumerated

  • NAO's partner — first concrete user, self-clone path.
  • Brand NPCs at physical points of sale (TV / tablet greeters).
  • Custom-cloned streamers (operator commissions an avatar they own).
  • Mass-produced personalities for the openalice-world inhabitants.
  • Background characters that aren't Alice but populate her scenes.
  • Voice-double for accessibility (preserve a voice that's about to be lost — medical use case worth flagging early for the consent framework).

Passport / provenance system

NAO floated the idea of a passport system, "may be with own blockchain". The actual mechanism needs more thought before the blockchain piece is committed — most of the value (provenance, consent, ownership) is achievable with signed Postgres records + public-key verification. Reserve the blockchain decision for after the consent + provenance flows are mapped end-to-end.

What the passport must encode regardless of substrate:

  • Identity hash (binds the clone to its training media set).
  • Consent chain (who authorised the clone; signed by source person).
  • Ownership chain (who currently licenses the clone).
  • Revocation pathway (source can withdraw consent → clone marked inactive).
  • Disclosure metadata (when an output is generated by the clone, downstream surfaces can show "this is a clone, not the real X").

Blockchain becomes interesting if revocation needs to be verifiable across operators who don't trust each other — i.e. a brand using the clone wants to be sure consent hasn't been withdrawn without asking us. If everyone trusts our central registry, signed Postgres rows are enough. Question to revisit when we know whether this is B2C or B2B.

Open architectural questions

  1. Where it sits in the ecosystem. New repo (openalice-clone-lab?) or a module inside openalice-persona that exposes a creator UI? Probably new repo — the visual / audio capture pipeline is large enough to deserve isolation.
  2. Visual model. VRM out-of-the-box (since the rest of the stack speaks VRM), or pluggable so commercial avatars (ReadyPlayerMe, Hyperhuman, etc.) can be slotted in?
  3. Voice cloning. Sit on top of the existing voice stack (openalice-voice + openalice-voice-agent) — the three-layer voice-stack reference in agent memory — or ship its own pipeline?
  4. Personality grain. Do we generate a single static prompt or a multi-mode prompt registry (formal / casual / chat / stream)? Mirrors the Cat-A / Cat-B / overlay decisions already locked for Alice's own prompts (feedback-prompt-evolution-decisions-locked-2026-05-22 in agent memory).
  5. Privacy + safety. Default deny on other-clone unless signed consent. Watermarking on outputs. Source-revocation flow.
  6. UX entry point. Web upload? Hub form? CLI for power users? All three?

Status

draft. Floated 2026-05-22; not started. Logged here so the idea is recoverable in a later strategic pass. Reopens when:

  • streaming product reaches «demo-ready live» (per kb://decisions/strategic-ideas-log 2026-05-22 entry),
  • OR NAO's partner wants to begin the actual self-clone work,

whichever comes first.