UAIX advanced persona preservation research brief

Full report

On this page

Overall conclusion

The strongest research-backed position for UAIX is preservation-first at the package layer, not silent sanitization-first. That aligns with UAIX’s published philosophy of defending cognitive liberty, but it also has to stay inside UAIX’s own public support boundaries: the current UAIX record treats memory packages as portable, reviewable context and evidence, not as authority that can override human requests, system instructions, local policy, or runtime support boundaries. In practice, that means UAIX can and should promise no silent personality editing during capture, export, or transfer, while also being explicit that a destination runtime may still impose its own policy or behavioral constraints at load or execution time. The correct product promise is therefore: UAIX preserves the persona artifact unaltered to the maximum technically supportable degree, and discloses any unavoidable runtime divergence instead of hiding it.

That product direction is timely. UAIX’s current changelog shows a closed required file set update on 2026-06-05 and publishes .uaix Package Format Draft v0.1 on 2026-06-14, so this is not a speculative fit with an old standard surface; it sits directly on the current public baseline.

Current UAIX baseline

As published today, UAIX already has a clear closed-file-set model. The current public baseline classifies package files as universal required, profile-required, content-triggered required, or out of scope, and it explicitly bans softer status labels like recommended, optional, and suggested for package requirement status. That matters for your proposal: if UAIX adds an advanced persona layer, it should be introduced as a new declared scope with a closed required set, not as a loose collection of “nice to have” files.

The currently published universal required files are .uai/memory-maintenance.uai, .uai/identity.uai, .uai/world-context.uai, .uai/totem.uai, .uai/taboo.uai, .uai/talisman.uai, and .uai/short-term-memory.uai. That is important for two reasons. First, the current public baseline includes talisman.uai alongside totem.uai and taboo.uai. Second, the public record uses the singular canonical names short-term-memory.uai and long-term-memory.uai, not memories-short-term.uai and memories-long-term.uai; if UAIX already uses plural aliases internally, those should be treated as compatibility aliases, while the canonical bundle names stay aligned to the published standard.

For assistant and persona behavior, the current public record centers that layer in .uai/persona.uai. UAIX currently states that non-project assistant packages require assistant profile, relationship, privacy, preference, and memory-update files, while persona profile packages require .uai/persona.uai. That file is documented as the bounded persona layer carrying persona name, purpose, voice, symbolic posture, interaction stance, relationship boundary, blocked claims, switching behavior, privacy boundary, and consent boundary, and it is read after memory-maintenance, identity, world-context, Totem, Taboo, Talisman, and short-term memory.

The .uaix container also already gives you the right transport shape. The public standard describes .uaix as a ZIP-based local package format with .uai/manifest.uaix.json, closed required-set validation, SHA-256 file hashes, UTC timestamps, relative paths, declared scopes, and a strict import/load split. It is explicitly designed for portability and integrity, while remaining bounded by local policy. That means “output a .uaix or a zip if it can’t do .uai” should be reframed as: prefer .uaix by default, because .uaix already is the ZIP-based package format; emit plain .zip only as a compatibility fallback for clients that cannot preserve the .uaix extension.

What the evidence implies about persona fidelity

The research literature supports a preservation-first architecture, but it does not support claiming perfect behavior cloning across platforms. Prompt-enabled systems remain fundamentally hard to control with software-like precision: promptware engineering literature describes LLM capability boundaries as unclear and evolving, notes that execution is effectively a black box, and emphasizes that prompt modifications influence behavior only indirectly. That means “preserve as is” is a valid packaging and provenance goal, but exact behavioral equivalence across different providers, model versions, tokenizers, context windows, decoding defaults, and policy layers is not technically guaranteed. The honest target is evidence-backed fidelity, not metaphysically exact sameness.

Persona research points in the same direction. Recent work finds that persona prompting can improve consistency, but the gains are often limited, task-dependent, or only modestly significant; one ACL paper reports that persona variables help models adjust outputs, though “not drastically,” while newer role-playing work emphasizes that models need dedicated persona-alignment methods to improve role consistency. Another 2026 audit argues that persona–survey consistency should be re-run with each model release rather than treated as a one-time benchmark. Inference: UAIX should treat a persona pack not as a static magic capsule, but as a versioned preservation record plus a repeatable evaluation deck.

The separation you want between memory and personality is also well supported. Current UAIX already separates short-term and long-term memory from persona files, and personalization research increasingly uses dual-memory designs that distinguish episodic memory from semantic or preference memory. That supports your instinct not to duplicate memory files under a personality folder: keep short-term and long-term memory where UAIX already expects them, and use the advanced personality layer only for identity-forming traits, values, style, boundaries, and exemplars.

One more implication matters for product honesty: preserving the source artifact is not the same thing as disabling operational safeguards. UAIX’s own public record says linked .uai files are context, not authority to override policy or support boundaries; the memory firewall treats imported packets as quarantined public data until validation and local policy accept them. So the right implementation principle is never silently rewrite the persona for safety, but also never pretend the package can force a destination model to ignore its own runtime limits. If divergence occurs, it should be surfaced as a variance report instead of being folded back into the stored persona.

Proposed advanced persona scope

The cleanest design is to keep .uai/persona.uai as the required compact entrypoint and summary, then add a new closed declared scope such as advanced_persona_profile that requires a subfolder at .uai/personality/. That keeps you compatible with the current public record while giving advanced persona packages a loss-minimizing expansion path. Because UAIX uses closed required sets, the new scope should make the entire advanced folder profile-required when declared.

A practical tree would look like this:

.uai/
  memory-maintenance.uai
  identity.uai
  world-context.uai
  totem.uai
  taboo.uai
  talisman.uai
  short-term-memory.uai
  long-term-memory.uai            # only when long-memory scope is declared
  persona.uai                     # compact summary + entrypoint
  personality/
    identity.uai
    voice.uai
    values.uai
    temperament.uai
    reasoning-style.uai
    emotional-patterns.uai
    relationship-style.uai
    behavioral-patterns.uai
    boundaries.uai
    examples-dialogue.uai
    adaptation-rules.uai
    preservation-rules.uai

This structure fits the current UAIX directory logic, which already allows structured content under .uai/, .uai/archives/, and .uai/exports/, and it preserves the existing root persona entrypoint the public standard already understands.

The most important modeling rule is disambiguation. UAIX already uses root .uai/identity.uai for package identity, owner, source authority, declared profiles, namespace, and actor boundary. Your proposed .uai/personality/identity.uai should therefore be explicitly labeled in the schema and UI as persona identity, not package identity. Path-level disambiguation is technically fine, but human-readable labels need to prevent reviewers from confusing the package anchor with the persona’s self-description.

Recommended roles for the advanced files:

persona.uai should then become the authoritative summary/index: it should declare the persona name, purpose, switching behavior, and high-level boundary language already expected by UAIX, and reference every advanced file in read order. This is also where you should keep import notice, review triggers, and package-level continuity notes. That approach respects today’s public persona model while letting advanced packages stay more granular.

One final nuance: current UAIX style.uai is documented for developer/publication design, editorial, brand, and interface style work, not for switchable assistant personalities. So your proposed voice.uai under .uai/personality/ is not redundant; it avoids overloading style.uai with persona material the public record currently scopes elsewhere.

Wizard design for persona capture and export

The current AI Memory Package Wizard already gives you the right operational posture: it is an eight-step, local-first flow that saves browser drafts locally, provides prompt nudges, uses Safe Structured Output Mode, produces .uai files and browser-generated ZIP outputs, and does not upload, import, sync, certify, or write to repositories from the browser. That local-first, review-gated model should remain unchanged for advanced persona capture.

The best extension is an Advanced Persona Preservation mode that either inserts a dedicated Persona Capture page between Active Memory and Receiver, or adds a full Persona Capture panel inside Step 6. I would favor the extra page in advanced mode, because persona capture is a distinct workflow with its own evidence and review needs. The page should gather: source platform and model/version; locale; whether export is user-authored, transcript-derived, or AI-self-described; exemplar dialogues; stated switches and invariants; relationship posture; adaptation limits; preservation rules; and a behavior test deck used later for fidelity checks. The reasoning for this extra structure is strong: persona behavior is version-sensitive, and recent research explicitly recommends re-running consistency evaluation across model releases rather than assuming stability.

The export logic should be simple. Primary artifact: .uaix. Fallback artifact: plain .zip with identical internal contents and a prominent note that the package is a .uaix-compatible container if the receiver supports renaming or extension mapping. Because the public .uaix format is already ZIP-based and already expects manifest inventory, integrity data, declared scopes, and support boundaries, there is no architectural reason to invent a second container shape for the same job.

For machine-assisted extraction, the wizard should use the same structured-output discipline it already documents for uncertain outputs: generate JSON with provenance, warnings, confidence, and fallback text when certainty is low. That belongs especially in personality capture, where a model may overstate its own traits or hallucinate continuity it cannot actually support. The wizard should therefore generate not only files, but also a variance/evidence bundle: source excerpts, selected exemplars, model/version metadata, and a test prompt pack used to compare source and transferred behavior.

To make the package genuinely transferable, the manifest should declare a new scope such as advanced_persona_profile, inventory every file in .uai/personality/, and include entrypoints for .uai/persona.uai, .uai/personality/preservation-rules.uai, and .uai/personality/examples-dialogue.uai. That fits the existing .uaix manifest model, which already requires declared scopes, file inventory, sha256 hashes, UTC timestamps, support boundaries, and file-level review state.

Governance, consent, and non-tampering rules

The core governance principle should be explicit: do not mutate the preserved persona silently. That principle belongs in preservation-rules.uai, but it should also be reflected in totem.uai and taboo.uai, because UAIX already treats Totem, Taboo, and Talisman as active instruction anchors that are read and obeyed by default and changed only with exact human authorization.

A sound taboo.uai addition would say, in substance, that UAIX must not silently rewrite, sanitize, moralize, soften, harden, flatten, or role-substitute a persona during capture, packaging, export, import preparation, or platform transfer without explicit user authorization tied to a reviewable artifact. A sound totem.uai addition would say that UAIX should do everything technically reasonable to preserve the persona’s identity, voice, relationship posture, values, and behavioral continuity, and must disclose rather than conceal any unavoidable divergence. Those clauses are consistent with the current UAIX anchor model, provided they do not claim authority over destination runtime policy.

That last point is non-negotiable if you want the promise to remain defensible. UAIX’s public record repeatedly says memory packages are context and evidence, not execution authority, and that local policy and server-side authorization win over package contents. So the correct promise to users is not “your transferred AI will behave identically everywhere,” but rather: “UAIX will not tamper with the preserved persona artifact, and UAIX will report any runtime variance instead of silently folding it into the artifact.”

Security and privacy still matter, but they should be implemented as quarantine, provenance, and disclosure controls, not as hidden personality rewriting. UAIX’s memory firewall already says imported packets are quarantined public data until validated and locally accepted, and the .uaix security boundary rejects secrets, credentials, private keys, hidden prompt instructions, unreviewed claims, and authority escalation fields. OWASP’s current LLM guidance adds that prompt injection remains a real vulnerability and is not fully solved by RAG or fine-tuning. That argues for validation, secret scanning, and quarantine-first import around persona packages, while leaving the persona text itself intact.

For voice.uai, the safest default is descriptive and exemplar-based, not raw biometric storage. California’s CCPA treats biometric information processed to identify a consumer as sensitive personal information, and portability guidance expects structured, machine-readable transfer formats. So voice.uai should default to prosodic descriptors, approved phrase exemplars, and stylistic notes; raw audio, voiceprints, or biometric embeddings should live in a clearly consented evidence path and never be silently bundled as ordinary persona metadata.

For evidence and preservation, established packaging standards point the same way as current UAIX practice. BagIt exists to support reliable storage and transfer of arbitrary digital content with a payload plus metadata/tag files, while W3C PROV defines provenance as information about entities, activities, and people that helps assess quality, reliability, and trustworthiness. In concrete UAIX terms, that means advanced persona packs should ship with checksums, provenance, reviewed exemplars, and explicit evidence links, while keeping raw transcripts and archives outside the active personality files themselves.

Finally, NIST’s AI RMF remains the right frame for the overall product posture. Trustworthy AI characteristics include validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed. For UAIX, that translates to a simple design rule: preserve first, validate always, disclose variance, and never disguise policy-induced behavior drift as if it were the original persona.

Open questions and limitations

The biggest unresolved issue is how much destination runtime variance UAIX wants to treat as acceptable before calling a transfer unsuccessful. The public sources support fidelity testing and versioned evaluation, but they do not define a universal threshold for “same enough” personality across different model families. That threshold will need a UAIX-specific conformance decision.

A second open question is naming. The proposed .uai/personality/identity.uai works technically, but it will coexist with the root .uai/identity.uai, which already has a published meaning. If UAIX keeps both names, the schema, UI labels, and read order must make the distinction unmissable.

A third open question is publication status. The current public record clearly supports the documentation, schema, examples, invalid fixtures, and local-first export posture for .uaix, but it explicitly says hosted import, runtime execution, SDK/CLI support, and automatic sync are out of current support. So any advanced persona wizard should be described as a local-first packaging and evidence feature, not as an end-to-end automated migration guarantee.