UAI AI Memory Package Wizard And The UAIX AIWikis System Design

UAIX.org should be treated as the canonical publisher of **compact active-memory packages** and their public implementation evidence, while LLMWikis.org should remain the canonical source for **LLM Wiki structure, gov...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-7c3f06f2/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-04-29/Improvement/UAI AI Memory Package Wizard and the UAIX AIWikis System Design.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-29T15:40:25.1136561Z
Content hash	sha256:7c3f06f2195050b2f3df59e57b4635ec9716928cd803f535891313e7cdf998ad
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-04-29-improve-7c3f06f21950.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-04-29-improve-7c3f06f21950.txt

Current File Content

Structure Preview

• UAI AI Memory Package Wizard and the UAIX AIWikis System Design
• Executive summary
• UAIX.org role in the integrated memory system
• Reference architecture and data model
• Wizard product design
• Operations, governance, and migration
• Recommended stack and implementation roadmap

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 30210
• Preview characters: 11967

# UAI AI Memory Package Wizard and the UAIX AIWikis System Design

## Executive summary

UAIX.org should be treated as the canonical publisher of **compact active-memory packages** and their public implementation evidence, while LLMWikis.org should remain the canonical source for **LLM Wiki structure, governance, metadata, and starter-template patterns**, and AIWikis.org should remain the **dogfooding integration site and long-term archive** for already-processed source-side inputs. The public sources are unusually explicit about these boundaries: UAIX positions AI Memory as a portable operating packet rather than a general knowledge base, LLMWikis positions the wiki as the durable knowledge layer, and AIWikis says it is the long-term archive for processed UAIX and LLMWikis inputs while keeping raw archive files out of public HTML and public packages. citeturn8view0turn8view1turn12view0turn2view0turn3view0turn12view1

The most important product decision is to implement **one canonical package registry and one canonical package object model**, then expose it through **three output modes**: a managed WordPress package stored and edited in WP-Admin, a multi-file copy-paste output for immediate use anywhere, and a downloadable ZIP. That pattern is already used by both UAIX and LLMWikis: each says its rendered samples, manifests, and ZIP downloads resolve through the same canonical template registry so that the site cannot drift into showing one thing while shipping another. Your wizard should follow that same rule. citeturn8view2turn6view4turn11view0

The storage and sync model should be asymmetric. **UAIX active memory stays compact, decisive, and reviewable**; **LLMWikis/AIWikis store deeper background, source summaries, contradiction records, and archives**. Promotion into active memory should happen only after review for accuracy, ownership, privacy, and support boundaries. AIWikis’ own archive flow reinforces this: the source site processes and dispositions a file first, then AIWikis pulls the archived file into raw memory and publishes only reviewed, safe summaries. citeturn9view0turn8view6turn8view7turn5view1turn5view2turn12view0turn12view4

For implementation, the best first build is a **WordPress plugin plus REST-driven front-end wizard**. WordPress’ official APIs already support the needed primitives: admin settings pages, custom admin menus, REST routes with permission callbacks and schemas, registered meta exposed through REST, secure filesystem writes through `WP_Filesystem`, request protection via nonces plus capability checks, and cached preview state via transients. For heavier queue work, Action Scheduler is a better fit than raw WP-Cron because it is explicitly designed as a scalable, traceable WordPress job queue with logging and admin visibility. For API contracts, use **OpenAPI 3.1** and **JSON Schema Draft 2020-12**. citeturn33view0turn34view0turn34view2turn34view3turn35view0turn36view0turn36view3turn29view0turn38view9turn38view10

## UAIX.org role in the integrated memory system

An integrated UAIX.org and AIWikis.org system will work best if each site keeps a **clear source-of-truth job** rather than trying to become a single merged product. Publicly, that role split is already visible:

| Site | Recommended system role | Why this should remain true |
|---|---|---|
| **UAIX.org** | Canonical active-memory publisher and implementation surface | UAIX says AI Memory is the portable operating packet; its implementation pages also define the current public WordPress publication track and package family. |
| **LLMWikis.org** | Canonical handbook and template source for durable wiki memory | LLMWikis says it teaches the pattern, publishes the starter bundle, and keeps the durable-knowledge guidance. |
| **AIWikis.org** | Dogfooding integrator and long-term reviewed archive | AIWikis says it does not replace the sources, consumes source-published packages, and acts as the long-term archive for processed inputs. |

That division is not only conceptually clean; it is already reflected in the public source boundaries, package ownership statements, and archive flow documentation. AIWikis explicitly warns that it should not publish an AIWikis-branded starter ZIP because that would blur upstream ownership boundaries. citeturn28view1turn3view0turn12view0turn12view1turn12view2

The practical implication for your wizard is straightforward: **the UAI AI Memory wizard should live on UAIX.org as a canonical source-publishing surface**, even if AIWikis later consumes the resulting artifacts for observed use, archive summarization, and recommendation changes. In other words, the wizard is not merely a convenience feature; it is part of UAIX’s documented WordPress publication track, package release path, and public implementation evidence. citeturn28view1turn9view5turn9view4

That also clarifies what the “integrated AIWikis system” should mean in practice:

- **UAIX active memory**: compact, operational, handoff-ready bundles that agents and humans load before acting.
- **LLMWikis durable memory**: reviewed, source-linked wiki pages, contradiction pages, index/log navigation, and governance metadata.
- **AIWikis archive memory**: post-disposition archive intake, safe summaries, lessons learned, and recommendation adjustments.

This lets UAIX stay decisive, LLMWikis stay expansive, and AIWikis stay reflective. citeturn8view0turn8view1turn12view0turn12view4turn5view3

## Reference architecture and data model

The core architectural rule should be:

**One registry → one package object model → many renderers/serializers.**

That rule is consistent with both UAIX and LLMWikis, which publicly describe a canonical template registry that drives rendered examples, bundle manifests, and generated ZIPs from the same source definitions. citeturn8view2turn6view4turn11view0

A good reference architecture is:

1. **Registry layer**
   Canonical package profiles, file templates, overlays, constraints, and schema versions.

2. **Authoring layer**
   Site wizard and WP-Admin editor that assemble a package instance from the registry plus user inputs.

3. **Validation layer**
   Structural checks, required-file checks, stale-date checks, contradiction flags, privacy/redaction checks, and size-budget checks.

4. **Serialization layer**
   Three serializers over the same package object:
   - WP-managed package record
   - Multi-file copy-paste output
   - ZIP artifact with manifest and checksums

5. **Index and sync layer**
   Search indexes for package discovery and lifecycle jobs that publish reviewed exports to AIWikis as long-term reference/archive inputs.

That architecture aligns naturally with LLMWikis’ metadata and graph rules, its two-step ingest pipeline, and UAIX’s compact handoff philosophy. citeturn4view0turn5view0turn5view2turn5view3turn9view0

Before building vector search or graph extras, keep the navigation deterministic. LLMWikis is clear that the foundational layers are a catalog/index, an append-only log, typed links, and visible contradiction handling; vector search can help later, but should not replace the human-readable navigation and source-status structure. PostgreSQL’s full-text search and materialized views are a strong fit for a first implementation, and pgvector adds HNSW and IVFFlat vector indexes inside Postgres when semantic search is needed. OpenSearch becomes attractive only when you need a dedicated search cluster, higher query fan-out, or specialized vector/search scaling beyond what a simpler Postgres-first design provides. citeturn5view3turn37view0turn37view1turn38view1turn38view2turn38view3

The canonical data model should be small and explicit:

| Entity | Purpose | Key fields |
|---|---|---|
| **PackageProfile** | Bundle preset such as `project-ai-memory`, `project-handoff`, `onboarding-memory` | `profile_id`, `title`, `trust_boundary`, `required_files`, `optional_files`, `default_limits` |
| **TemplateFile** | Canonical file template entry from the registry | `template_id`, `path`, `format`, `purpose`, `owner`, `review_cycle`, `agent_use`, `sensitivity`, `body` |
| **PackageInstance** | A user-authored or wizard-authored assembled package | `package_id`, `profile_id`, `status`, `owner_user_id`, `sensitivity`, `created_at`, `updated_at`, `manifest_version` |
| **SourceRecord** | Optional linked upstream evidence or wiki background | `source_id`, `source_type`, `uri_or_path`, `checksum`, `source_status`, `source_trace`, `reviewed_at` |
| **ExportArtifact** | A generated serializer output | `artifact_id`, `package_id`, `artifact_type`, `checksum`, `generated_at`, `storage_key`, `expires_at` |
| **SyncEvent** | Reconciliation event between active memory and long-term wiki/archive | `sync_id`, `direction`, `state`, `changed_files`, `review_required`, `completed_at` |

The schema should bake in the metadata disciplines LLMWikis already recommends: owner, status, last-reviewed date, review cycle, sensitivity, agent-use policy, related links, source status, and source trace. It should also mirror UAIX’s front-door files and package taxonomy rather than inventing a parallel memory model. citeturn4view0turn4view1turn5view0turn7view0turn11view1turn11view2

For provenance, use a **PROV-inspired model**: record the package as an **entity**, the wizard/export/sync as **activities**, and the human editor, reviewer, generator, and upstream source as **agents**. W3C PROV defines provenance as information about entities, activities, and people involved in producing a piece of data, and that maps cleanly to a package-building workflow. For public schema and generator versions, use Semantic Versioning so schema changes, backward-compatible additions, and breaking changes are visible at a glance. citeturn32search2turn32search5turn38view11

A representative package manifest might look like this:

```json
{
  "schema_version": "1.0.0",
  "profile_id": "project-ai-memory",
  "package_id": "uaim_pkg_01J9Q4D7X7M0A4",
  "title": "UAIX.org Wizard Build for Example Project",
  "generated_at": "2026-04-29T18:30:00Z",
  "status": "reviewed",
  "trust_boundary": "internal",
  "provenance": {
    "entity_id": "pkg:uaim_pkg_01J9Q4D7X7M0A4",
    "generated_by_activity": "activity:wizard_export_2026-04-29T18:30:00Z",
    "generated_by_agent": "user:mike",
    "reviewed_by_agent": "user:editor_17",
    "source_site": "uaix.org",
    "generator": {
      "name": "uai-ai-memory-wizard",
      "version": "0.4.0"
    }
  },
  "files": [
    {
      "path": "AGENTS.md",
      "template_id": "uai.frontdoor.agents",
      "checksum_sha256": "abc123...",
      "purpose": "front-door coordination file",
      "required": true
    },
    {
      "path": "readme.human",
      "template_id": "uai.frontdoor.human",
      "checksum_sha256": "def456...",
      "purpose": "human briefing",
      "required": true
    },
    {
      "path": ".uai/context.uai",
      "template_id": "uai.context",
      "checksum_sha256": "ghi789...",
      "purpose": "project scope and purpose",
      "required": true
    }
  ],
  "background_links": [
    {
      "type": "wiki-page",
      "url": "aiwikis://wiki/project/example-overview",
      "source_status": "reviewed-background"
    }
  ],
  "validation": {
    "passed": true,
    "warnings": [],
    "size_budget_class": "small"
  }
}
```

The end-to-end package flow should look like this:

```mermaid
sequenceDiagram
    actor User as User or Admin
    participant UI as Wizard UI
    participant API as WordPress REST API
    participant REG as Canonical Registry
    participant VAL as Validation Service
    participant DB as WordPress DB
    participant OBJ as Object Storage
    participant IDX as Search Index
    participant AIW as AIWikis Sync

    User->>UI: Choose profile and answer guided questions
    UI->>API: Save draft package inputs

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: UAI AI Memory Package Wizard and the UAIX AIWikis System Design; Executive summary; UAIX.org role in the integrated memory system; Reference architecture and data model; Wizard product design; Operations, governance, and migration; Recommended stack and implementation roadmap. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-598 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAI AI Memory Package Wizard And The UAIX AIWikis System Design",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-7c3f06f2/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-04-29/Improvement/UAI AI Memory Package Wizard and the UAIX AIWikis System Design.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:7c3f06f2195050b2f3df59e57b4635ec9716928cd803f535891313e7cdf998ad",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-29T15:40:25.1136561Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-598",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}