Non-Project Memory Packages for Assistants and Social Companions

Full report

On this page

Executive Summary

UAIX already provides a serious foundation for portable, reviewable AI memory, but its public tooling is still optimized for project-centered work rather than everyday assistant or companion use. The AI Memory Package Wizard is an eight-step, local-first builder that can generate .uai files, archives, manifests, JSON-LD graphs, llms.txt outputs, a package model JSON, and a browser-generated ZIP, while explicitly avoiding hosted import, repository writes, automatic sync, SDK/CLI behavior, certification, or endorsement claims. Its bundle taxonomy covers Project AI Memory, Project Handoff, Agent Session Memory, Onboarding Memory, Decision Memory, External Handoff Memory, Incident/Audit Memory, and LLM Wiki Export Memory, but there is no published preset specifically for personal assistant, office assistant, or companion-chatbot memory.

That gap matters because the wizard’s current assumptions are visibly project-oriented. Its required baseline includes .uai/coding-standards.uai, and its wizard steps ask about deployment strategy, code review, framework standards, workspace targeting, WordPress/Visual Studio environments, and system discovery prompts. Those are sensible for project memory, but they are a weak fit for non-project assistants whose durable context is more likely to be identity, preferences, routine tasks, contacts, calendar entries, conversation summaries, and trust/consent boundaries.

Across the broader ecosystem, there is still no single dominant open “assistant memory package” standard. Instead, the landscape is fragmented into two layers. Closed assistant products such as ChatGPT, Claude, and Gemini have memory features, export controls, and some import flows, but they generally do not publish a durable, vendor-neutral public schema for full personal memory portability. Open standards do exist for the major data domains that assistants need: ActivityStreams and ActivityPub for social objects and actors, Matrix for conversational event timelines, vCard and JSContact for contacts, iCalendar and JSCalendar for calendars and tasks, and CardDAV/CalDAV/JMAP for synchronization and sharing.

The most durable path is therefore not to replace UAIX, but to complement it with a non-project memory package profile that keeps UAIX’s strongest ideas—local-first review, explicit manifests, hot-vs-cold memory separation, trust-boundary awareness, and provenance—while adopting a canonical JSON core that can export cleanly into domain standards. The recommended design is a JSON Schema 2020-12 canonical package, with optional JSON-LD 1.1 semantic projection, plus adapters for JSContact/vCard, JSCalendar/iCalendar, and a conversation/event export compatible with Matrix-like or ActivityStreams-like objects.

My practical recommendation is to add three new UAIX-compatible profiles: office-assistant-memory, companion-memory, and personal-kb-memory. Each should preserve UAIX manifest conventions and front-door review behavior, but swap project-specific modules for user-centric modules such as persona, preferences, routines, conversation memory, calendar, contacts, tasks, and consent metadata. This report lays out a proposed schema, templates, workflows, interoperability rules, security posture, roadmap, and example code for doing exactly that.

UAIX Wizard Review

UAIX’s public AI Memory surface is already unusually rigorous compared with most AI-product memory features. On the AI Memory page, UAIX describes AI Memory as compact operating memory that a future actor should load before acting, explicitly distinguishing it from a general knowledge base and advising that long research, old progress detail, and deep rationale should live in a colder wiki-style layer instead of the active packet. The public wizard then turns those supported starter configurations into a local-first package-planning flow with validation, draft restore, prompt nudges, structured-output safety, generated startup files, export artifacts, and ZIP packaging.

What the wizard already does well

The published UAIX data model

The core public UAIX data model is more structured than the wizard UI alone suggests. UAIX states that supported starter bundles are presets over one canonical file-template registry, and the public AI Memory page shows a generated manifest containing fields such as bundle_id, name, description, intended_use_case, lifecycle, trust_boundary_notes, included_files, file_set_rule, declared_package_profiles, universal_required_files, profile_required_file_sets, and required_files_effective. For the Project AI Memory starter, the universal required files are .uai/identity.uai, .uai/world-context.uai, .uai/totem.uai, .uai/taboo.uai, .uai/short-term-memory.uai, and .uai/coding-standards.uai.

That manifest model is important because it can be reused almost unchanged for non-project profiles. In other words, the biggest architectural gap is not the absence of a package model; it is the absence of profile-specific non-project semantics on top of that model. UAIX’s own taxonomy already says new configurations should exist when they have a different lifecycle, trust boundary, or consumption pattern. Personal assistant memory and companion memory meet that criterion cleanly.

Where the fit breaks for non-project use

The public limitations are explicit. The wizard does not claim hosted import, automatic repository writes, automatic LLM Wiki sync, SDKs, CLIs, certification, endorsement, or broad package-manager behavior as current support. The roadmap reinforces that “managed AI Memory packages,” hosted imports, sync, and developer tooling remain future or planned work rather than present public support.

For non-project use cases, the deeper issue is content fit. The wizard’s Basics, Collaboration, Operations, and Governance steps ask about owner/review team, audience, sensitivity, target environment, framework standards, deployment strategy, code review, release gates, workspace routing, and system discovery. That is excellent for a delivery project, but awkward for an office assistant managing a person’s preferences, calendar, tasks, and contacts—or for a social/companion bot that needs persona, relational boundaries, and selective episodic memory instead of coding standards and deployment evidence. Officially, every launch-baseline package still includes .uai/coding-standards.uai, and the receiver is prompted to inspect source trees, manifests, CI config, and deployment docs. That is the central reason a complementary non-project package layer is needed.

Existing Formats Across Assistant and Social Ecosystems

The current ecosystem splits into closed assistant memory systems and open interoperable data standards. The former are better at end-user personalization; the latter are better at portability, versioning, and long-term interchange. For a practical implementation, the right answer is a composite design rather than trying to force one ecosystem’s format onto all others.

The major analytical takeaway is that assistant platforms are converging on user-visible memory controls, but not on a common memory package, while open standards already solve most of the domain-specific modeling problem. That strongly argues for a canonical package that can emit multiple interoperable views rather than tying the design to any single vendor product.

Proposed Non-Project Memory Package Schema

The proposed model below treats non-project memory as a reviewable, versioned, portable packet with clear separation between hot memory, cold references, and derived artifacts. It deliberately mirrors UAIX’s emphasis on compact active memory, trust boundaries, and promotion of reviewed truth, while adopting JSON-native standards where they are now mature enough to support interoperability. JSON Schema Draft 2020-12 is the right validation layer; JSON-LD 1.1 is the right optional semantic layer; JSContact and JSCalendar should be the preferred structured exports for contacts and calendar data, with vCard and iCalendar as compatibility views.

erDiagram
    MEMORY_PACKAGE ||--|| IDENTITY : has
    MEMORY_PACKAGE ||--o| PERSONA : may_define
    MEMORY_PACKAGE ||--o{ PREFERENCE : stores
    MEMORY_PACKAGE ||--o{ MEMORY_ITEM : stores
    MEMORY_PACKAGE ||--o{ CONVERSATION_MESSAGE : stores
    MEMORY_PACKAGE ||--o{ CONTACT : stores
    MEMORY_PACKAGE ||--o{ CALENDAR_ITEM : stores
    MEMORY_PACKAGE ||--o{ TASK_ITEM : stores
    MEMORY_PACKAGE ||--o{ CONSENT_RECORD : governs
    MEMORY_PACKAGE ||--o{ ACL_ENTRY : restricts
    MEMORY_PACKAGE ||--o{ PROVENANCE_RECORD : traces
    MEMORY_PACKAGE ||--o{ ATTACHMENT_REF : references

    MEMORY_PACKAGE {
      string package_id PK
      string schema_version
      string profile_id
      string locale
      datetime created_at
      datetime updated_at
      string persistence_policy
      string encryption_state
    }

    IDENTITY {
      string subject_id PK
      string display_name
      string entity_type
      string timezone
      string preferred_language
    }

    PERSONA {
      string persona_id PK
      string style
      string tone
      string boundaries
      string relationship_mode
    }

    PREFERENCE {
      string preference_id PK
      string category
      string key
      string value
      string confidence
      string persistence_tier
    }

    MEMORY_ITEM {
      string memory_id PK
      string kind
      string summary
      string detail_ref
      string persistence_tier
      datetime last_used_at
    }

    CONVERSATION_MESSAGE {
      string message_id PK
      string thread_id
      string role
      string content_ref
      datetime occurred_at
      string sensitivity
    }

    CONTACT {
      string contact_id PK
      string name
      string jscontact_ref
      string vcard_ref
      string relationship
    }

    CALENDAR_ITEM {
      string event_id PK
      string title
      datetime start_at
      datetime end_at
      string jscalendar_ref
      string ical_ref
    }

    TASK_ITEM {
      string task_id PK
      string title
      string status
      datetime due_at
      string source
    }

    CONSENT_RECORD {
      string consent_id PK
      string purpose
      string status
      datetime granted_at
      datetime expires_at
    }

    ACL_ENTRY {
      string acl_id PK
      string principal
      string role
      string scope
      string permission
    }

    PROVENANCE_RECORD {
      string provenance_id PK
      string source_type
      string source_ref
      string checksum
      string reviewer
      datetime captured_at
    }

    ATTACHMENT_REF {
      string attachment_id PK
      string uri
      string media_type
      string checksum
      string sensitivity
    }

Required and optional fields

The cleanest way to design the schema is to distinguish between universal required fields and profile-required modules. That mirrors UAIX’s own manifest philosophy and prevents “one giant always-on schema” from becoming a dumping ground.

A few design choices are especially important.

First, ephemeral and persistent data should be separate modules, not a boolean on every field. Existing assistants already expose this distinction in different ways: ChatGPT offers Temporary Chat, Claude offers incognito chats, and Gemini offers Temporary Chat plus activity and memory controls. A serious portable package should make that separation first-class rather than implicit.

Second, provenance must be attached to memory, not just to exports. UAIX explicitly tells agents to treat old chat, generated summaries, wiki material, and dropped files as background until reviewed and promoted, and its structured-output guidance already points toward fields such as concept_id, confidence, warnings, provenance, and fallback text. That pattern is directly portable into non-project memory.

Third, the hot layer must stay compact. UAIX’s guidance to keep active memory “hot and small,” combined with Matrix’s 64 KiB event limit and the realities of multi-platform importing, argues for a strict design discipline: the assistant should load reviewed summaries and current operating state first, while full chat history and bulky artifacts remain referenced, chunked, or archived. That is a design recommendation rather than a published UAIX quota, but it follows the strongest available evidence.

JSON Schema examples

The canonical schema should be JSON Schema Draft 2020-12 with an optional JSON-LD context. Below is a concise but implementation-ready starting point for the package envelope and the manifest. JSON Schema 2020-12 is the current version cited by the official JSON Schema site, and JSON-LD 1.1 is the W3C recommendation for linked-data semantics in JSON.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.org/schemas/non-project-memory-package.schema.json",
  "title": "NonProjectMemoryPackage",
  "type": "object",
  "required": [
    "schema_version",
    "package_id",
    "profile_id",
    "created_at",
    "updated_at",
    "subject",
    "context_policy",
    "trust_boundary",
    "consent",
    "acl",
    "provenance",
    "active_summary",
    "merge_policy"
  ],
  "properties": {
    "@context": {
      "type": [
        "string",
        "array",
        "object"
      ]
    },
    "schema_version": {
      "type": "string",
      "pattern": "^\\d+\\.\\d+\\.\\d+$"
    },
    "package_id": {
      "type": "string",
      "format": "uuid"
    },
    "profile_id": {
      "type": "string",
      "enum": [
        "office-assistant-memory",
        "companion-memory",
        "personal-kb-memory"
      ]
    },
    "created_at": {
      "type": "string",
      "format": "date-time"
    },
    "updated_at": {
      "type": "string",
      "format": "date-time"
    },
    "subject": {
      "type": "object",
      "required": [
        "subject_id",
        "display_name",
        "timezone",
        "preferred_language"
      ],
      "properties": {
        "subject_id": { "type": "string" },
        "display_name": { "type": "string" },
        "entity_type": { "type": "string", "enum": ["person", "team", "household", "bot"] },
        "timezone": { "type": "string" },
        "preferred_language": { "type": "string" }
      },
      "additionalProperties": false
    },
    "persona": {
      "type": "object",
      "properties": {
        "style": { "type": "string" },
        "tone": { "type": "string" },
        "boundaries": { "type": "array", "items": { "type": "string" } },
        "relationship_mode": { "type": "string" }
      },
      "additionalProperties": false
    },
    "preferences": {
      "type": "array",
      "items": {
        "$ref": "#/$defs/preference"
      }
    },
    "conversation": {
      "type": "object",
      "properties": {
        "summaries": {
          "type": "array",
          "items": { "$ref": "#/$defs/memoryItem" }
        },
        "messages": {
          "type": "array",
          "items": { "$ref": "#/$defs/message" }
        }
      },
      "additionalProperties": false
    },
    "contacts": {
      "type": "array",
      "items": { "$ref": "#/$defs/contact" }
    },
    "calendar": {
      "type": "array",
      "items": { "$ref": "#/$defs/calendarItem" }
    },
    "tasks": {
      "type": "array",
      "items": { "$ref": "#/$defs/taskItem" }
    },
    "ephemeral_state": {
      "type": "object"
    },
    "context_policy": {
      "type": "object",
      "required": ["hot_memory_budget", "default_persistence_tier"],
      "properties": {
        "hot_memory_budget": { "type": "integer", "minimum": 1 },
        "default_persistence_tier": {
          "type": "string",
          "enum": ["ephemeral", "persistent", "derived"]
        }
      },
      "additionalProperties": false
    },
    "trust_boundary": {
      "type": "object",
      "required": ["classification", "sharing_rule"],
      "properties": {
        "classification": { "type": "string" },
        "sharing_rule": { "type": "string" }
      },
      "additionalProperties": false
    },
    "consent": {
      "type": "array",
      "items": { "$ref": "#/$defs/consentRecord" }
    },
    "acl": {
      "type": "array",
      "items": { "$ref": "#/$defs/aclEntry" }
    },
    "provenance": {
      "type": "array",
      "items": { "$ref": "#/$defs/provenanceRecord" }
    },
    "active_summary": {
      "$ref": "#/$defs/memoryItem"
    },
    "merge_policy": {
      "type": "object"
    }
  },
  "$defs": {
    "preference": {
      "type": "object",
      "required": ["category", "key", "value", "persistence_tier"],
      "properties": {
        "category": { "type": "string" },
        "key": { "type": "string" },
        "value": {},
        "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
        "persistence_tier": {
          "type": "string",
          "enum": ["ephemeral", "persistent", "derived"]
        }
      },
      "additionalProperties": false
    },
    "memoryItem": {
      "type": "object",
      "required": ["memory_id", "kind", "summary", "persistence_tier"],
      "properties": {
        "memory_id": { "type": "string" },
        "kind": { "type": "string" },
        "summary": { "type": "string" },
        "detail_ref": { "type": "string" },
        "persistence_tier": {
          "type": "string",
          "enum": ["ephemeral", "persistent", "derived"]
        },
        "last_used_at": {
          "type": "string",
          "format": "date-time"
        }
      },
      "additionalProperties": false
    },
    "message": {
      "type": "object",
      "required": ["message_id", "thread_id", "role", "occurred_at"],
      "properties": {
        "message_id": { "type": "string" },
        "thread_id": { "type": "string" },
        "role": {
          "type": "string",
          "enum": ["system", "user", "assistant", "tool"]
        },
        "content_ref": { "type": "string" },
        "occurred_at": {
          "type": "string",
          "format": "date-time"
        },
        "sensitivity": { "type": "string" }
      },
      "additionalProperties": false
    },
    "contact": {
      "type": "object",
      "required": ["contact_id", "name"],
      "properties": {
        "contact_id": { "type": "string" },
        "name": { "type": "string" },
        "jscontact_ref": { "type": "string" },
        "vcard_ref": { "type": "string" },
        "relationship": { "type": "string" }
      },
      "additionalProperties": false
    },
    "calendarItem": {
      "type": "object",
      "required": ["event_id", "title", "start_at"],
      "properties": {
        "event_id": { "type": "string" },
        "title": { "type": "string" },
        "start_at": { "type": "string", "format": "date-time" },
        "end_at": { "type": "string", "format": "date-time" },
        "jscalendar_ref": { "type": "string" },
        "ical_ref": { "type": "string" }
      },
      "additionalProperties": false
    },
    "taskItem": {
      "type": "object",
      "required": ["task_id", "title", "status"],
      "properties": {
        "task_id": { "type": "string" },
        "title": { "type": "string" },
        "status": { "type": "string" },
        "due_at": { "type": "string", "format": "date-time" },
        "source": { "type": "string" }
      },
      "additionalProperties": false
    },
    "consentRecord": {
      "type": "object",
      "required": ["consent_id", "purpose", "status"],
      "properties": {
        "consent_id": { "type": "string" },
        "purpose": { "type": "string" },
        "status": {
          "type": "string",
          "enum": ["granted", "denied", "withdrawn", "expired"]
        },
        "granted_at": { "type": "string", "format": "date-time" },
        "expires_at": { "type": "string", "format": "date-time" }
      },
      "additionalProperties": false
    },
    "aclEntry": {
      "type": "object",
      "required": ["principal", "role", "permission"],
      "properties": {
        "principal": { "type": "string" },
        "role": { "type": "string" },
        "scope": { "type": "string" },
        "permission": { "type": "string" }
      },
      "additionalProperties": false
    },
    "provenanceRecord": {
      "type": "object",
      "required": ["source_type", "source_ref", "captured_at"],
      "properties": {
        "source_type": { "type": "string" },
        "source_ref": { "type": "string" },
        "checksum": { "type": "string" },
        "reviewer": { "type": "string" },
        "captured_at": { "type": "string", "format": "date-time" },
        "confidence": { "type": "number", "minimum": 0, "maximum": 1 }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.org/schemas/non-project-memory-manifest.schema.json",
  "title": "NonProjectMemoryManifest",
  "type": "object",
  "required": [
    "bundle_id",
    "name",
    "profile_id",
    "schema_version",
    "included_files",
    "checksums"
  ],
  "properties": {
    "bundle_id": { "type": "string" },
    "name": { "type": "string" },
    "profile_id": { "type": "string" },
    "schema_version": { "type": "string" },
    "included_files": {
      "type": "array",
      "items": { "type": "string" }
    },
    "checksums": {
      "type": "object",
      "additionalProperties": { "type": "string" }
    },
    "exports": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "json",
          "jsonld",
          "uaix",
          "jscontact",
          "vcard",
          "jscalendar",
          "icalendar",
          "activitystreams",
          "matrix-events",
          "zip"
        ]
      }
    }
  },
  "additionalProperties": false
}

Template Packages and Example Payloads

The table below defines the three most useful starting profiles. I interpret the user’s “social/cheatbot friend” phrasing as a social/companion chatbot profile, because the surrounding context is clearly about friend-like non-project AI interactions rather than academic cheating or social-media boosting.

Representative minimal payloads for those templates can be very small when the hot layer is kept compact.

{
  "schema_version": "0.1.0",
  "profile_id": "office-assistant-memory",
  "subject": {
    "subject_id": "user:mike",
    "display_name": "Mike",
    "entity_type": "person",
    "timezone": "America/Chicago",
    "preferred_language": "en-US"
  },
  "preferences": [
    { "category": "communication", "key": "meeting_brief_style", "value": "concise", "persistence_tier": "persistent" }
  ],
  "calendar": [
    { "event_id": "evt-001", "title": "Weekly staff sync", "start_at": "2026-06-08T15:00:00Z", "jscalendar_ref": "exports/calendar/staff-sync.json" }
  ],
  "tasks": [
    { "task_id": "tsk-001", "title": "Draft quarterly summary", "status": "open", "due_at": "2026-06-10T21:00:00Z", "source": "manual" }
  ]
}

{
  "schema_version": "0.1.0",
  "profile_id": "companion-memory",
  "subject": {
    "subject_id": "user:mike",
    "display_name": "Mike",
    "entity_type": "person",
    "timezone": "America/Chicago",
    "preferred_language": "en-US"
  },
  "persona": {
    "style": "warm and conversational",
    "tone": "non-judgmental",
    "boundaries": [
      "do not simulate legal, medical, or crisis expertise",
      "ask before revisiting painful topics"
    ],
    "relationship_mode": "supportive friend"
  },
  "conversation": {
    "summaries": [
      {
        "memory_id": "mem-01",
        "kind": "relationship-summary",
        "summary": "Prefers casual check-ins, humor, and direct responses; dislikes synthetic flattery.",
        "persistence_tier": "persistent"
      }
    ]
  }
}

{
  "schema_version": "0.1.0",
  "profile_id": "personal-kb-memory",
  "subject": {
    "subject_id": "user:mike",
    "display_name": "Mike",
    "entity_type": "person",
    "timezone": "America/Chicago",
    "preferred_language": "en-US"
  },
  "knowledge_items": [
    {
      "memory_id": "kb-001",
      "kind": "reference-note",
      "summary": "Preferred C# coding conventions and display-attribute requirements for code generation.",
      "detail_ref": "attachments/notes/csharp-preferences.md",
      "persistence_tier": "persistent"
    }
  ],
  "provenance": [
    {
      "source_type": "user-profile",
      "source_ref": "conversation-settings",
      "captured_at": "2026-06-07T00:00:00Z",
      "confidence": 1.0
    }
  ]
}

Import, Export, and Product Integration Design

The import/export layer should be designed as a reviewed merge system, not as a blind loader. That is consistent with UAIX’s own guidance that agents should read manifests first, report contradictions or oversize memory, and treat old chats or generated summaries as background until reviewed and promoted. It is also consistent with the way current assistant products expose memory controls rather than promising seamless universal package interchange.

flowchart TD
    A[Select source package or export ZIP] --> B[Detect format]
    B --> C{Known format?}
    C -- No --> D[Quarantine as attachment only]
    C -- Yes --> E[Validate schema and checksums]
    E --> F{Passes validation?}
    F -- No --> G[Show errors and block auto-merge]
    F -- Yes --> H[Normalize to canonical JSON model]
    H --> I[Classify modules: contacts, calendar, tasks, chats, persona, KB]
    I --> J[Apply sensitivity and consent rules]
    J --> K{Needs human review?}
    K -- Yes --> L[Review queue with diff and redaction tools]
    K -- No --> M[Run module-specific merge policy]
    L --> M
    M --> N[Write active summary]
    M --> O[Write cold references and attachments]
    N --> P[Generate exports: UAIX overlay, JSON-LD, JSContact, JSCalendar, ZIP]
    O --> P
    P --> Q[Record audit event and new manifest]

Import and merge behavior

The user-facing experience should expose four explicit modes on load: Preview, Merge, Replace module, and Attach only. Preview should always be first. This follows UAIX’s review-first spirit and is especially important for personal or relational data, where imported content may be stale, contradictory, or beyond the user’s intended trust boundary.

A workable merge policy is module-specific rather than global.

UI and UX recommendations

The UI should make hidden memory behavior visible. In practice, that means five things.

The first is a hot-memory dashboard: what will be loaded first, why it exists, when it was last reviewed, and what is persistent versus ephemeral. This is the closest portable analogue to ChatGPT’s memory summary and Claude’s memory summary view, but it should also show provenance and trust state.

The second is a memory mode switch: persistent, session-only, or temporary/incognito. Existing assistant products already train users to expect such modes, so a portable package should preserve them rather than flattening everything into one retention bucket.

The third is a diff-first merge screen with module-level approvals, especially for persona, sensitive preferences, imported memories, and anything tagged with high sensitivity or external provenance.

The fourth is a source and consent panel that answers three questions for every imported module: where it came from, whether it can be used for personalization, and whether it may be exported or used for model training. This becomes critically important because vendor behavior differs; for example, Gemini’s published import flow says imported and continued chats are saved in activity and used to improve Google services, including generative-AI model training, whereas OpenAI and Anthropic expose different user controls and commercial-data terms.

The fifth is a validation and readiness panel that mirrors UAIX’s strength: file counts, checksum status, unresolved conflicts, missing consent, stale summaries, and oversize hot-memory warnings.

Proposed API surface

UAIX’s current published REST surface is catalog/discovery/validator/OpenAPI-oriented rather than package-import-oriented, and the roadmap explicitly holds managed packages and hosted imports outside current public support. The endpoints below are therefore a proposal for complementary implementation, not a claim about today’s UAIX API.

A connector-aware implementation should also support vendor-specific import adapters. Google’s published Gemini import flow is the clearest current public precedent: it explicitly supports importing memory by prompt-copy/paste and importing chat-history ZIPs from ChatGPT and Claude, with a 5 GB per ZIP limit and up to five ZIP uploads per day.

Compatibility, Security, and Compliance

Compatibility and interoperability guidelines

The safest compatibility path is to treat the proposed non-project format as a new profile layer over UAIX’s existing package shell, not as a fork.

That means the package should keep a UAIX-style manifest, clear included-file lists, checksums, and front-door review order; preserve identity, world-context, short-term-memory, and values/boundaries semantics; and add a profile-specific payload such as memory.json or non-project-memory.json under the export layer. This reuses the strongest parts of UAIX—reviewability, lifecycle discipline, and manifested trust boundaries—while avoiding hard dependence on project-only modules for every use case.

The most delicate compatibility issue is .uai/coding-standards.uai. Public UAIX docs currently require it for every launch-baseline memory or handoff package, and the surrounding guidance is codebase-oriented. For immediate backward compatibility, the least disruptive approach is to keep the file path but allow a standards_kind value such as interaction, assistant, or non-code, so the file can express operational rules, privacy constraints, escalation rules, and tool-usage norms rather than software-coding norms. Medium term, UAIX would benefit from introducing a more general alias like .uai/interaction-standards.uai, while preserving the original path as a compatibility shim.

A practical mapping strategy looks like this:

This also aligns well with how open protocols divide responsibility. ActivityPub is a transport protocol over ActivityStreams; CardDAV and CalDAV are management and sharing layers over contact and calendar data; JMAP is a sync protocol over JSON objects. The package should therefore remain the canonical content object, while server-backed protocols remain export or sync adapters.

Security, privacy, and compliance recommendations

Security and privacy should be designed around the assumption that personal-memory packages are often more sensitive than ordinary project packets. UAIX itself warns against including secrets, credentials, raw personal data without an approved process, and executable payloads that a future agent might run without human approval. It also tells users to choose bundles by trust boundary, not by name alone, and to redact before external sharing. That guidance is even more important for office-assistant and companion use cases.

The table below summarizes the control baseline I recommend.

On compliance specifically, GDPR and CCPA/CPRA pull the design in the same general direction even though their legal mechanics differ. The shared architectural implications are straightforward: collect less, keep it for less time, make access/export/deletion practical, classify sensitive data, preserve auditability, and separate user-controlled memory from silent repurposing. The California Attorney General’s CCPA page lists rights to know, delete, opt out, non-discrimination, correct, and limit sensitive-information use; the European Commission’s GDPR pages list access, rectification, erasure, portability, objection, and automated-decisioning rights, while GDPR’s principles include data minimisation and storage limitation.

Roadmap, Risks, and Reference Code

A staged implementation is better than a “big bang” because the hardest part is not the JSON structure itself. The hardest part is the combination of compatibility, merge semantics, trust/consent UX, and policy-safe importers. The roadmap below assumes no specific stack and is deliberately expressed as indicative effort bands rather than staffing commitments.

gantt
    title Proposed implementation timeline
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Foundation
    Schema freeze and manifest design         :a1, 2026-06-09, 21d
    Validator and test fixtures              :a2, after a1, 14d

    section Interoperability
    UAIX overlay and file mapping            :b1, after a1, 21d
    JSContact and vCard adapters             :b2, after a1, 14d
    JSCalendar and iCalendar adapters        :b3, after a1, 14d
    Vendor importers for ChatGPT Claude Gemini exports :b4, after a2, 21d

    section Product UX
    Diff review and conflict-resolution UI   :c1, after b1, 21d
    Consent and ACL management               :c2, after c1, 14d
    Audit trail and retention workflows      :c3, after c1, 14d

    section Hardening
    Encryption and key-management integration :d1, after c2, 21d
    Pilot with office assistant profile      :d2, after d1, 14d
    Companion and personal-KB rollout        :d3, after d2, 21d

Milestones, effort, and risk profile

Sample C# code for serialization, deserialization, and migration

The stack is unspecified, so the sample below is intentionally narrow and portable: System.Text.Json, JsonNode, and a small set of model classes. The date/time fields are DateTimeOffset and should be written in UTC when persisted.

using System.ComponentModel.DataAnnotations;
using System.Text.Json;
using System.Text.Json.Nodes;

/// <summary>
/// Represents the canonical non-project memory package envelope.
/// </summary>
public sealed class MemoryPackage
{
    [Display(Name = "Schema Version")]
    public string SchemaVersion { get; init; } = "0.1.0";

    [Display(Name = "Package")]
    public Guid PackageId { get; init; }

    [Display(Name = "Profile")]
    public string ProfileId { get; init; } = string.Empty;

    [Display(Name = "Created At")]
    public DateTimeOffset CreatedAt { get; init; }

    [Display(Name = "Updated At")]
    public DateTimeOffset UpdatedAt { get; init; }

    [Display(Name = "Subject")]
    public SubjectIdentity Subject { get; init; } = new();

    [Display(Name = "Persona")]
    public PersonaDefinition? Persona { get; init; }

    [Display(Name = "Preferences")]
    public List<PreferenceItem> Preferences { get; init; } = new();

    [Display(Name = "Active Summary")]
    public MemorySummary ActiveSummary { get; init; } = new();

    [Display(Name = "Training Use")]
    public string TrainingUse { get; init; } = "denied";
}

/// <summary>
/// Represents the subject the memory belongs to.
/// </summary>
public sealed class SubjectIdentity
{
    [Display(Name = "Subject")]
    public string SubjectId { get; init; } = string.Empty;

    [Display(Name = "Display Name")]
    public string DisplayName { get; init; } = string.Empty;

    [Display(Name = "Entity Type")]
    public string EntityType { get; init; } = "person";

    [Display(Name = "Timezone")]
    public string Timezone { get; init; } = "UTC";

    [Display(Name = "Preferred Language")]
    public string PreferredLanguage { get; init; } = "en-US";
}

/// <summary>
/// Represents assistant persona settings.
/// </summary>
public sealed class PersonaDefinition
{
    [Display(Name = "Style")]
    public string Style { get; init; } = string.Empty;

    [Display(Name = "Tone")]
    public string Tone { get; init; } = string.Empty;

    [Display(Name = "Relationship Mode")]
    public string RelationshipMode { get; init; } = string.Empty;

    [Display(Name = "Boundaries")]
    public List<string> Boundaries { get; init; } = new();
}

/// <summary>
/// Represents a remembered preference.
/// </summary>
public sealed class PreferenceItem
{
    [Display(Name = "Category")]
    public string Category { get; init; } = string.Empty;

    [Display(Name = "Key")]
    public string Key { get; init; } = string.Empty;

    [Display(Name = "Value")]
    public JsonNode? Value { get; init; }

    [Display(Name = "Persistence Tier")]
    public string PersistenceTier { get; init; } = "persistent";

    [Display(Name = "Confidence")]
    public decimal? Confidence { get; init; }
}

/// <summary>
/// Represents the reviewed hot-memory summary.
/// </summary>
public sealed class MemorySummary
{
    [Display(Name = "Memory")]
    public string MemoryId { get; init; } = string.Empty;

    [Display(Name = "Kind")]
    public string Kind { get; init; } = string.Empty;

    [Display(Name = "Summary")]
    public string Summary { get; init; } = string.Empty;
}

/// <summary>
/// Handles canonical serialization for memory packages.
/// </summary>
public static class MemoryPackageSerializer
{
    private static readonly JsonSerializerOptions SerializerOptions = new()
    {
        PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower,
        WriteIndented = true
    };

    /// <summary>
    /// Serializes a memory package to a JSON string.
    /// </summary>
    /// <param name="package">The package to serialize.</param>
    /// <returns>A formatted JSON document.</returns>
    public static string Serialize(MemoryPackage package)
    {
        ArgumentNullException.ThrowIfNull(package);

        return JsonSerializer.Serialize(package, SerializerOptions);
    }

    /// <summary>
    /// Deserializes a memory package from JSON.
    /// </summary>
    /// <param name="json">The JSON document to deserialize.</param>
    /// <returns>The deserialized package.</returns>
    /// <exception cref="InvalidOperationException">Thrown when deserialization fails.</exception>
    public static MemoryPackage Deserialize(string json)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(json);

        var result = JsonSerializer.Deserialize<MemoryPackage>(json, SerializerOptions);
        return result ?? throw new InvalidOperationException("Failed to deserialize memory package.");
    }

    /// <summary>
    /// Normalizes timestamps to UTC before persistence or export.
    /// </summary>
    /// <param name="package">The package to normalize.</param>
    /// <returns>A copy with UTC timestamps.</returns>
    public static MemoryPackage NormalizeUtc(MemoryPackage package)
    {
        ArgumentNullException.ThrowIfNull(package);

        return new MemoryPackage
        {
            SchemaVersion = package.SchemaVersion,
            PackageId = package.PackageId,
            ProfileId = package.ProfileId,
            CreatedAt = package.CreatedAt.ToUniversalTime(),
            UpdatedAt = package.UpdatedAt.ToUniversalTime(),
            Subject = package.Subject,
            Persona = package.Persona,
            Preferences = package.Preferences,
            ActiveSummary = package.ActiveSummary,
            TrainingUse = package.TrainingUse
        };
    }
}

using System.Text.Json.Nodes;

/// <summary>
/// Performs in-place JSON migrations between schema versions.
/// </summary>
public static class MemoryPackageMigrator
{
    /// <summary>
    /// Migrates a package from schema version 0.1.0 to 0.2.0.
    ///
    /// Migration rules:
    /// - Renames training_use to downstream_training_use.
    /// - Splits persona.relationship_mode into persona.relationship.role.
    /// - Adds merge_policy when absent.
    /// </summary>
    /// <param name="source">The source package as a mutable JSON object.</param>
    /// <returns>The migrated JSON object.</returns>
    /// <exception cref="InvalidOperationException">Thrown when the source document is invalid.</exception>
    public static JsonObject Migrate_0_1_0_To_0_2_0(JsonObject source)
    {
        ArgumentNullException.ThrowIfNull(source);

        var schemaVersion = source["schema_version"]?.GetValue<string>();
        if (!string.Equals(schemaVersion, "0.1.0", StringComparison.Ordinal))
        {
            throw new InvalidOperationException("This migrator only accepts schema version 0.1.0.");
        }

        // Rename training_use -> downstream_training_use.
        if (source.TryGetPropertyValue("training_use", out var trainingUseNode))
        {
            source["downstream_training_use"] = trainingUseNode?.DeepClone();
            source.Remove("training_use");
        }

        // Transform persona.relationship_mode -> persona.relationship.role.
        if (source["persona"] is JsonObject persona &&
            persona.TryGetPropertyValue("relationship_mode", out var relationshipModeNode))
        {
            persona["relationship"] = new JsonObject
            {
                ["role"] = relationshipModeNode?.DeepClone()
            };

            persona.Remove("relationship_mode");
        }

        // Add a default merge policy if absent.
        if (source["merge_policy"] is null)
        {
            source["merge_policy"] = new JsonObject
            {
                ["preferences"] = "three_way_merge",
                ["conversation_messages"] = "append_only",
                ["persona"] = "manual_review",
                ["consent"] = "stricter_wins",
                ["acl"] = "stricter_wins"
            };
        }

        source["schema_version"] = "0.2.0";
        source["updated_at"] = DateTimeOffset.UtcNow.ToString("O");

        return source;
    }
}

Open questions and limitations

A few important items remain genuinely open.

UAIX does not currently publish a dedicated non-project personal-assistant or companion-memory preset, and its public wizard does not currently claim hosted import, managed packages, SDKs, CLIs, or automatic sync. Those are design opportunities, not current features.

Public vendor docs for ChatGPT, Claude, and Gemini expose real memory controls and export/import surfaces, but they do not collectively amount to a stable vendor-neutral memory package specification. Some capabilities are plan-bound, geography-bound, or explicitly experimental, and policy behavior differs by platform.

Finally, the privacy and compliance guidance in this report is architectural rather than legal advice. Any production rollout that stores sensitive personal data, relationship data, or employee/workplace metadata should still be reviewed against the applicable controller/processor model, retention obligations, and regional law before launch.