Integrating Horma Into UAIX

UAIX is already structurally well-suited for a hierarchical-memory integration, but only if HORMA is introduced in a way that respects UAIX’s existing publication posture: local-first generation, explicit review gates...

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-4ef82424/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-13/hierarchical-goal-memory/Improvement/Integrating HORMA into UAIX.org.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-13T19:41:24.5036390Z
Content hash	sha256:4ef82424822caa3dec91ad2e4fc6b140e094c5bd94564461c53a479fb7625f9a
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-13-hierarc-4ef82424822c.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-13-hierarc-4ef82424822c.txt

Current File Content

Structure Preview

• Integrating HORMA into UAIX.org
• Executive summary
• UAIX concepts, structure, audiences, and constraints
• What UAIX already publishes
• Who UAIX serves today
• Current wizard, documentation, and style constraints
• The most important architectural boundary for integration
• HORMA and the larger hierarchical-memory landscape
• What HORMA is
• Why HORMA matters relative to adjacent work
• Performance characteristics and trade-offs
• Mapping HORMA to UAIX surfaces
• Recommended mapping
• Design options and trade-offs
• Proposed architecture
• Proposed dedicated UAIX page
• Best route and publication level
• Proposed page outline
• Publication-ready page draft
• Visual asset suggestions
• Technical integration plan for the wizard and spec
• Wizard integration steps
• Specification and registry strategy
• Data model and storage plan

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: 49662
• Preview characters: 11240

# Integrating HORMA into UAIX.org

## Executive summary

UAIX is already structurally well-suited for a hierarchical-memory integration, but only if HORMA is introduced in a way that respects UAIX’s existing publication posture: local-first generation, explicit review gates, canonical public records, and a strict separation between portable evidence and runtime orchestration. UAIX currently presents itself as the public standards and publication site for UAI and UAI-1, with clean locale-prefixed public routes, machine-facing REST routes, validator-backed records, implementation tracks, and a strong preference for canonical pages over implied runtime services. Its AI Memory and Project Handoff surfaces already distinguish hot operating truth from colder background memory, and its knowledge-graph guidance explicitly treats graph projections as derived, read-only, and subordinate to reviewed source files. That means HORMA is a strong conceptual fit for UAIX, but primarily as a **guided, local-first hierarchy-planning and retrieval pattern**, not as a hosted memory platform, automatic sync layer, or new blanket support claim. citeturn2view4turn20view0turn14view0turn10view0turn16view0turn18view0

The best near-term integration path is a phased one. First, publish HORMA as a **guide-level public record** linked from AI Memory and Project Handoff, because the reviewed HORMA source is a very new arXiv preprint rather than a mature official product surface with public implementation tooling. Second, add a **wizard overlay** that remains local-first and generates hierarchy plans, derived manifests, and optional read-only exports without adding hosted import, repository writes, official adapters, or automatic memory promotion. Third, only after evidence accumulates, introduce optional UAIX schema/registry support for hierarchy descriptors and validation. This sequencing fits UAIX’s own rules that reports and guidance can explain proposals, but support claims should remain tied to released schemas, examples, validator evidence, implementation tracks, and the changelog. citeturn21search0turn33view0turn9search1turn4search9turn4search5turn18view0

Technically, HORMA is attractive because it separates **memory construction** from **memory retrieval**. The paper’s core move is to externalize memory into a file-system-like hierarchy, let a high-capacity manager organize raw trajectories into structured notes with provenance, and let a lighter retrieval agent navigate that hierarchy with grounded file operations such as `ls`, `grep`, `cd`, `cat`, plus `select` and `done`, optimized with GRPO using an evidence-grounded reward. That architecture matches UAIX’s existing emphasis on file bundles, typed `.uai` records, stable public routes, manifest overlays, and explicit provenance. It also matches the Project Handoff knowledge-graph guidance that says the source of truth remains the reviewed file bundle while derived graph or index layers are only aids for navigation and retrieval. citeturn23view0turn34view1turn34view2turn16view0turn16view2turn16view4

My recommendation is therefore: **publish a guide now, ship a wizard planning overlay next, and defer normative spec changes until after shadow-mode benchmarking**. In practical terms, that means adding an optional “Hierarchical Memory” mode to the AI Memory Package Wizard, generating a `hierarchy.json` export and a hierarchy plan file, keeping the canonical `.uai` bundle as the authority layer, and providing public documentation that explicitly says the hierarchy is derived, review-gated, and not a hosted runtime service. That recommendation is both technically strong and aligned with how UAIX already tells readers to interpret AI Memory, Project Handoff, LLM Wiki, knowledge graphs, reports, press language, and policy-significant releases. citeturn10view5turn10view6turn14view0turn15search3turn16view0turn19view8turn19view9

## UAIX concepts, structure, audiences, and constraints

### What UAIX already publishes

UAIX’s public structure is more than a brochure site. The homepage, Get Started path, Tools surface, AI Memory section, Specification pages, Implementations, Governance, Reports, and Press pages together define a standards-first publication system with both human-readable and machine-readable surfaces. The site explicitly publishes UAI-1, schemas, registry entries, examples, validator guidance, an API reference, an OpenAPI export, an adoption kit, a conformance pack, implementation tracks, governance records, a public roadmap, and a public changelog. The public route family uses clean locale-prefixed paths, while the machine-facing layer exposes routes such as catalog, schemas, registry, examples, transport bindings, trust channels, conformance levels, error registry, validation, adoption kit, OpenAPI, and conformance pack under the UAIX REST surface. citeturn2view4turn7search1turn17search4

UAIX’s information architecture is also internally coherent. The AI Memory area contains the broad framing for durable AI project context, Project Handoff, LLM Wiki boundaries, the `.uai` file guide, and related guides; the Specification area contains UAI-1, Schemas, Registry, and Examples; the Tools area contains Validator, API Reference, Adoption Kit, Conformance Pack, and the AI Memory Package Wizard; Governance contains Policy and Security, privacy, accessibility, analytics, roadmap, and changelog; Reports preserve dated research/proposal material inside the same site shell. That matters because a HORMA integration should reuse this existing route logic rather than invent a parallel mini-site. citeturn14view0turn20view0turn18view0turn9search1

### Who UAIX serves today

UAIX has an explicit role map for implementers, tool builders, researchers and standards readers, editors/reviewers/contributors, and public readers/press. Implementers are pointed toward UAI-1, Schemas, Registry, Examples, Validator, and Implementations. Tool builders are pointed toward schemas, registry, examples, validator, and discovery. Researchers are pointed toward UAI-1, changelog, news, and references. Public readers and press are pointed toward News, Press, and References. This maps cleanly to the user’s requested audiences of developers, researchers, and public readers. A dedicated “designers” audience is not explicitly named in UAIX’s role taxonomy, but the closest existing public surfaces are Press, About, and the shared publication theme that handles page structure and approved outward-facing language. citeturn20view0turn19view5turn19view7turn9search1

The table below translates UAIX’s existing audience model into the requested research frame.

| Requested audience | Closest UAIX audience | Existing best entry points | Implication for HORMA content |
|---|---|---|---|
| Developers | Implementers, tool builders | Get Started, UAI-1, Schemas, Registry, Validator, API Reference, Implementations | Provide API/data-model examples, validator implications, and migration/testing guidance |
| Designers | Public-facing editors, press, content owners | Press, About, Reports/publication shell | Provide approved plain-language framing, asset guidance, and page-shell-conforming copy |
| Researchers | Researchers and standards readers | UAI-1, Changelog, News, References, Reports | Cite primary papers, contrast with adjacent memory systems, separate evidence from speculation |
| Public | Public readers and press | News, Press, References, About | Explain benefits, boundaries, and what UAIX does **not** newly claim |

This is a synthesis of UAIX’s published role paths and public-facing copy guidance. citeturn20view0turn19view5turn19view7turn19view8

### Current wizard, documentation, and style constraints

The AI Memory Package Wizard is an especially strong anchor for HORMA integration, because it already works as an eight-step, local-first builder with page-level validation, local browser draft restore, prompt nudges, Safe Structured Output Mode, package-model exports, manifest overlays, knowledge-graph JSON, human UI, and a visitor AI digest exposed on the same page through `script[data-ai-digest]`. The wizard saves a local browser draft after changes, keeps generated outputs on the review step, and explicitly says that it does **not** upload, import, sync, certify, write to a repository, act as an SDK or CLI, or become a hosted runtime orchestrator. Those limits are not incidental; they are the main design constraint any HORMA addition must preserve. citeturn5search1turn10view0turn10view3turn10view4turn10view5turn10view6turn15search8

UAIX’s documentation style is also consistent enough to imitate. Public pages typically include a title, a record code, canonical path, “How to use this page,” “On this page,” jump links, and explicit statements about support boundaries and what should not be inferred. The Press page instructs authors to keep outward-facing copy inside published facts and not imply unpublished partner, repository, or certification programs. About says the site should be read as a public standards and release record rather than a generic product site. Reports say source Markdown is rendered inside a shared UAIX page shell with theme-provided navigation, outline, dates, and source metadata. A successful HORMA page should therefore look and sound like **UAIX guidance**, not like a generic AI blog post. citeturn19view5turn19view7turn19view8turn19view9turn9search1

### The most important architectural boundary for integration

The most important published UAIX boundary is that **Project Handoff and AI Memory remain the source of truth**, while derived graph or retrieval layers remain secondary. The Project Handoff Knowledge Graphs guide says that graph-ready memory is useful for querying, verification, slimming, archiving, and promotion, but the reviewed repo-local file bundle remains authoritative. It also explicitly says that graph projection should be derived and read-only until reviewed, and that hosted graph databases, public graph APIs, public SPARQL endpoints, SDKs, CLIs, automatic sync, and automatic import remain outside current support. That boundary strongly argues that HORMA should first appear as a **derived hierarchy/export and retrieval aid**, not as a replacement for `.uai` records or a new runtime promise. citeturn16view0turn16view1turn16view2turn16view4turn16view5

## HORMA and the larger hierarchical-memory landscape

### What HORMA is

HORMA is a June 2026 research framework introduced as the **Hierarchical Organize-and-Retrieve Memory Agent**. It was designed for long-horizon LLM agents that suffer from growing interaction histories, degraded reasoning quality, latency, and token cost. Instead of relying on flat similarity retrieval or lossy compression alone, HORMA stores experience in a file-system-like hierarchy in which summarized entities remain linked to raw trajectories. Its central claim is that working memory should be explicitly split into two modules: a manager that organizes memory asynchronously, and a retriever that navigates memory on the inference path. citeturn21search0turn23view0turn35view0turn35view2

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: Integrating HORMA into UAIX.org; Executive summary; UAIX concepts, structure, audiences, and constraints; What UAIX already publishes; Who UAIX serves today; Current wizard, documentation, and style constraints; The most important architectural boundary for integration; HORMA and the larger hierarchical-memory landscape. 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-388 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Integrating Horma Into UAIX",
    "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-4ef82424/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-13/hierarchical-goal-memory/Improvement/Integrating HORMA into UAIX.org.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:4ef82424822caa3dec91ad2e4fc6b140e094c5bd94564461c53a479fb7625f9a",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-13T19:41:24.5036390Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-388",
    "duplicate_role":  "primary",
    "related_files":  [

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