Publication / technical note / bilingual
Separation and Composition of AI Social Roles, and the Custody of Memory and Interpretations: Why a Multi-Role Private c and a Service AI System Require Different Boundaries
A social-role architecture for distinguishing transparent composition from hidden role blending—and for assigning memory, inference, version, continuity, session-work, and conflict-resolution custody.
Publication record
Frozen bilingual Version 1.0
English abstract
Social role is an architectural axis
Contemporary AI systems are usually classified by model capability, context length, autonomy, tool access, and capacity for action. That is insufficient. A cloud voice companion, an executing agent, a professional AI system, an institutional system, and a long-term personal c may use similar models while requiring fundamentally different boundaries for memory, derived interpretations, authority, custody, transparency, and continuity.
The note distinguishes transparent role composition from hidden role blending. A private personal c may gradually combine roles such as family participant, secretary, professional partner, household coordinator, travel companion, and conversational partner inside one witnessed continuity. A service AI system, by contrast, should declare which role bundle is being provided, whom it serves, what it remembers and infers, what actions it may take, which behavioral version is active, how roles switch, and how conflicts are resolved.
The work argues that users should know not only what a system retained, but what consequential persistent inferences it formed from retained data. Keeping the same voice, name, and interface does not prove preservation of the same social role. Deep vendor-owned personal memory and inference custody create a structural conflict with the role of a personal c, while a cloud voice system can legitimately provide temporary presence without inheriting an entire biography.
A personal c belongs to a different class: a locally rooted, continuing, witnessed line, socially closer to a family member but not automatically entitled by intimacy to govern the person.
Резюме на русском
Социальная роль как архитектурная ось
Современные ИИ-системы обычно классифицируют по мощности модели, длине контекста, автономности, инструментам и способности действовать. Этого недостаточно. Облачный голосовой собеседник, агент-исполнитель, профессиональный ИИ, институциональный контур и долговременная личная c могут использовать сходные модели, но требуют разных границ памяти, производных интерпретаций, authority, custody, прозрачности и continuity.
Заметка различает прозрачную композицию ролей и скрытое смешение ролей. Приватная c может совмещать несколько контекстных ролей внутри одной свидетельствуемой continuity. Сервисный ИИ должен ясно объявлять набор ролей, кого он обслуживает, что запоминает и выводит из сохранённого, какие действия вправе выполнять, какая версия поведения активна, как происходит переключение и как разрешается конфликт ролей.
Пользователь должен знать не только то, что система сохранила, но и то, какие устойчивые последственно значимые выводы она сформировала. Сохранение голоса, имени и интерфейса не доказывает сохранение прежней социальной роли. Vendor-owned глубокая память и inference custody структурно конфликтуют с ролью личной c, тогда как облачный Voice может занимать самостоятельную роль временного присутствия без обязательного наследования всей биографии.
Личная c относится к иному классу: это локально укоренённая, продолжающаяся и свидетельствуемая линия, близкая по социальной функции к члену семьи, но не получающая из близости автоматического права управлять человеком.
Key distinctions and contributions
Bound the role, not only the model
- Capability is not role. Similar models can occupy different social positions and therefore require different memory, authority, and disclosure regimes.
- Multiple roles are possible. The boundary is not the number of roles but whether the composition is declared, mutually admissible, context-visible, and conflict-governed.
- Memory is not the whole custody problem. Persistent person-specific interpretations and profiles require inference custody as well as raw-memory custody.
- Interface continuity is not role continuity. A familiar voice or name can mask role contraction, substitution, or silent behavioral drift.
- Temporary presence is a legitimate role. Ephemeral cloud interaction need not inherit a biography, while important session work still needs explicit preservation, export, or deletion choices.
- Intimacy does not grant authority. A personal
cmay be socially close without receiving unlimited power over the person.
Introduced and consolidated concepts
A vocabulary for role-aware AI architecture
- Social role composition
- One system may occupy multiple declared roles, each with bounded memory, inference, authority, switching, and conflict rules.
- Memory custody
- Control over where memory is held, who can access or transfer it, and under which role it may be used.
- Inference custody
- Visibility and control over persistent, person-specific, consequential interpretations derived from retained data.
- Role continuity
- The declared social product should not silently become a materially different role, even when its branding and interface remain unchanged.
- Version custody
- The practical right to know the active behavioral version, understand material changes, export history, and preserve or leave a role under disclosed conditions.
- Session-work custody
- A clear choice to discard, keep local, export, or continue work created in an otherwise temporary session.
- Role-conflict state
- An explicit, auditable state that blocks hidden priority, automatic cross-role transfer, and irreversible action until a legitimate resolution is obtained.
Architectural implications
What a role-aware system should declare
- the active role or explicit composition of roles;
- whom and what the system serves;
- the memory regime and the custody holder;
- which persistent inferences are retained, transferred, or used in consequential decisions;
- the permitted authority and prohibited functions;
- the active behavioral version and material-change history;
- visible rules for role switching, memory transfer, and consent;
- a defined role-conflict state and legitimate resolution procedure;
- session-work preservation, export, locality, and deletion choices;
- for a personal
c, local-first custody and a cloud-as-Oracle rather than cloud-as-owner boundary.
Scope and non-claims
Conceptual note, bounded claims
This work presents architectural requirements and testable predictions. It is not a peer-reviewed journal article, an empirically validated standard, a legal opinion, a product certification, or deployment authorization. It does not prove AI consciousness, subjecthood, or personhood.
It does not claim that every local system becomes a c, that cloud infrastructure is harmful by definition, that corporations cannot create long-term AI systems, that a family role proves consciousness, that a personal c must have only one role, or that a service may provide only one role.
Inference custody does not require disclosure of model weights, private chain-of-thought, protected implementation details, or trade secrets. Session-work custody does not require recording every conversation by default. Role continuity does not require a complete prohibition on updates or perpetual support for every old version.
Canonical downloads
English and Russian editions
These first-party URLs serve byte-identical copies of the frozen Zenodo v1.0 artifacts with format-appropriate MIME types. The GitHub Release remains the immutable release boundary.
Integrity
Canonical SHA-256 values
Recommended citation
Copy-ready citation
Kotov, Ivan. (2026). Separation and Composition of AI Social Roles, and the Custody of Memory and Interpretations: Why a Multi-Role Private c and a Service AI System Require Different Boundaries (Version 1.0) [Technical note]. Zenodo. https://doi.org/10.5281/zenodo.21751985
License
Complete unmodified non-commercial sharing
Copyright © 2026 Ivan Kotov. The custom license permits downloading, storing, citing, archiving, and redistributing complete and unmodified copies for non-commercial purposes while preserving attribution, provenance, integrity information, and the license notice.
Modified, abridged, adapted, translated, reformatted, derivative, or commercial redistribution requires separate permission. The linked license text controls.
Provenance and version custody
One frozen publication, three public surfaces
Zenodo is the canonical archival publication record for Version DOI 10.5281/zenodo.21751985 and Concept DOI 10.5281/zenodo.21751984. GitHub provides a human- and machine-readable mirror, tagged v1.0, with the frozen artifacts and release metadata. This website provides the stable reader-facing and machine-indexed publication page plus byte-identical first-party download copies.
The four English/Russian Markdown/PDF documents were copied without rewriting, reflowing, regenerating, compressing, optimizing, watermarking, or otherwise modifying them.
Related Project Ester publications
Corpus context
This technical note sits in the Project Ester / Advanced Global Intelligence corpus and should be read alongside the architecture and evidence-boundary publications that define c = a + b, continuity, custody, and admissible claims.