Integrating HORMA into UAIX.org

Full report

On this page

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.

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.

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.

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.

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.

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.

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.

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

This is a synthesis of UAIX’s published role paths and public-facing copy guidance.

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.

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.

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.

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.

Concretely, HORMA externalizes working memory into a persistent hierarchical workspace made of structured files and directories such as entity logs, event summaries, and state trackers. The manager archives raw interaction trajectories, synthesizes structured notes, and preserves temporal metadata and references to underlying raw trajectories. The retriever then accesses the hierarchy with grounded filesystem actions, including ls, grep, cd, cat, plus select and done, and is optimized with GRPO against an evidence-grounded retrieval reward based on overlap with task-relevant evidence. This is an unusually operational design, and it is one reason HORMA maps naturally onto UAIX’s file-centric AI Memory and Project Handoff model.

Why HORMA matters relative to adjacent work

HORMA sits inside a rapidly maturing memory-systems literature. MemGPT framed the basic problem as one of virtual context management inspired by hierarchical memory in operating systems. HiAgent showed that hierarchical working memory can be organized around subgoals, doubling success rate and reducing steps on long-horizon tasks. A-MEM moved toward agentic note creation, dynamic indexing, and linked memory inspired by Zettelkasten. Mem0 pushed a production-oriented long-term-memory architecture and reported large latency and token-cost savings. StructMem focused on preserving event-level relationships while keeping memory more efficient than graph-heavy alternatives. LightMem introduced a tiered, cognition-inspired memory with strong efficiency improvements, and HMT showed that a hierarchy can decouple high-level web-task logic from low-level site actions. HORMA’s main novelty, relative to this field, is its explicit combination of hierarchical structure, grounded navigation, provenance-preserving raw links, and RL-optimized retrieval.

The broader theoretical framing is also useful for UAIX. A recent theory paper argues that hierarchical memory systems can be understood with a three-operator pipeline: extraction, coarsening, and traversal. It distinguishes “self-sufficient” coarse nodes, which can often answer directly, from “referential” coarse nodes, which mainly route the retriever downward and therefore require top-down refinement. That distinction is helpful for UAIX because Project Handoff and .uai bundles are naturally referential: they should guide the next human or agent toward the right evidence, not silently replace it. HORMA, as described in the paper and appendix examples, is much closer to that referential/provenance-preserving model than to a pure compress-and-forget approach.

Performance characteristics and trade-offs

HORMA’s headline results are strong enough to justify attention but not strong enough, on their own, to justify immediate normative lock-in. In the paper’s own summary, HORMA improves task performance under constrained context budgets while using at most 22.17% of baseline token usage on long-conversation tasks. The paper further reports token usage at only 3.07%–22.17% of baselines on LoCoMo and 1.24%–16.19% on LongMemEval, while all HORMA variants and the structured embedding-retrieval variant stayed within roughly 1,000 tokens per query on the conversational benchmarks.

On ALFWorld, the paper’s table reports HORMA success rates of 56.7% under the smaller context limit and 73.9% under the larger context limit, both the best reported settings in that comparison. On the long-conversation benchmarks, the main HORMA configuration reports overall scores of 51.6 on LoCoMo and 55.9 on LongMemEval, versus truncation baselines of 32.2 and 34.1. The ablation table also shows that adding skill evolution to management and RL to retrieval materially helps, and that a lightweight Qwen 3.5 4B retriever trained with GRPO reached 58.0 on LongMemEval while improving LoCoMo from 32.6 to 42.2 in the paper’s analysis.

The trade-off is equally important. HORMA’s own analysis says memory construction is the bottleneck when organization quality is poor: a better retriever cannot fully compensate for a bad hierarchy. That matters a great deal for UAIX. A wizard overlay that generates sloppy or under-specified hierarchy nodes would create apparent sophistication without trustworthy retrieval benefits. In other words, the paper supports a staged UAIX plan: begin with conservative, reviewable hierarchy construction and transparent exports; only later attempt learned retrieval and stronger automation.

Mapping HORMA to UAIX surfaces

Recommended mapping

The best crosswalk between HORMA and UAIX is shown below. It assumes UAIX stays standards-first and avoids premature runtime claims.

This mapping follows UAIX’s documented distinction between AI Memory, Project Handoff, the local-first wizard, reports/guides, and graph projections that remain derived and review-gated.

Design options and trade-offs

Three realistic design directions emerge.

This option ranking is consistent with HORMA’s decoupled architecture, UAIX’s local-first wizard boundary, and the Project Handoff knowledge-graph rule that derived structures should be secondary to reviewed files.

Proposed architecture

The proposed integration below is intentionally conservative: the wizard creates hierarchy plans and exports locally; .uai files remain canonical; optional retrieval tooling consumes the hierarchy in read-only mode.

The design is grounded in HORMA’s manager/retriever split and UAIX’s existing file-centric AI Memory, wizard digest, manifest exports, and graph-ready-but-derived guidance.

flowchart LR
    A[UAIX AI Memory Package Wizard] --> B[Package Model JSON]
    A --> C[Generated .uai bundle]
    B --> D[Hierarchy Planner]
    C --> D
    D --> E[Hierarchy Export JSON]
    D --> F[Hierarchy Overlay for manifest]
    E --> G[Review UI Tree Preview]
    F --> G
    G --> H[Download ZIP]
    E --> I[Optional Read-Only Retriever]
    C --> J[Canonical Project Handoff Source]
    J --> I
    I --> K[Context Pack for next human or agent]

A complementary flow for retrieval keeps the hierarchy subordinate to reviewed evidence and avoids automatic write-back from retrieval results. That mirrors both HORMA’s evidence-based retrieval loop and UAIX’s claim/evidence-state discipline.

flowchart TD
    Q[Task or user question] --> R[Hierarchy Router]
    R --> S[Select candidate nodes]
    S --> T[Expand linked raw refs only if needed]
    T --> U[Assemble bounded context pack]
    U --> V[Primary agent response]
    V --> W{Accepted and reviewed?}
    W -- No --> X[Keep as transient result]
    W -- Yes --> Y[Promote to .uai files / docs / tests / changelog]

Proposed dedicated UAIX page

Best route and publication level

Because HORMA is currently backed here by a fresh primary research paper rather than a mature public implementation surface, the safest initial publication target is a guide, not a normative specification page and not a wizard-first feature announcement. I recommend the canonical route /en-us/guides/hierarchical-memory-horma/, with cross-links from AI Memory, Project Handoff, Project Handoff Knowledge Graphs, and the AI Memory Package Wizard. That route choice fits UAIX’s own distinction between practical guidance and hard support claims, and it keeps public language aligned with press guidance against overstating unpublished programs.

Proposed page outline

A UAIX-conforming public page should include the following sections in this order:

That outline mirrors the structure UAIX already uses on About, AI Memory, the Wizard, Policy and Security, and several guides.

Publication-ready page draft

The metadata block below is safe to paste into a UAIX publication workflow because it contains only proposed page metadata, not uncited factual claims.

title: "Hierarchical Memory with HORMA"
path: "/en-us/guides/hierarchical-memory-horma/"
surface: "Guides"
access: "Public and linkable"
use: "Canonical public record"

Hero summary

UAIX can describe the page in one sentence like this: Practical guide for using a HORMA-style hierarchical memory pattern with UAIX AI Memory and Project Handoff while keeping reviewed .uai files as the source of truth and treating hierarchy exports as derived retrieval aids. This phrasing is consistent with UAIX’s standards-publication tone, the AI Memory framing, and the Press page’s requirement to stay inside published facts.

How to use this page

Use this page when a team wants to organize durable AI project memory into a hierarchy that is easier to query, retrieve, and review than a flat note store, while still keeping the reviewed AI Memory and Project Handoff bundle as the authoritative handoff surface. Start here for the public pattern; use AI Memory, Project Handoff, the Wizard, and the Knowledge Graph guide for the concrete file bundle, export behavior, and review rules. This language deliberately mirrors existing UAIX “How to use this page” conventions.

What HORMA means here

HORMA is a recent research pattern for organizing agent experience into a file-system-like hierarchy of structured notes linked to underlying raw trajectories, and then retrieving context by navigating that hierarchy rather than only doing flat semantic search. In UAIX terms, the idea is not to replace the .uai bundle with an inferred graph or retrieval cache, but to generate a readable hierarchy that can route the next human or agent to the right current files, accepted evidence, and raw source references more efficiently.

Current support boundary

A UAIX HORMA page should say plainly that the current supported posture is documentation, local-first planning, and derived export guidance. It should also say that a hierarchy export is not a hosted importer, not automatic repository writing, not automatic sync, not a public graph API, not a validator certification, and not a runtime orchestrator. That is fully aligned with the Wizard’s current support boundary and the Project Handoff knowledge-graph boundary.

How it fits AI Memory and Project Handoff

AI Memory remains the broad framing for durable project context. Project Handoff remains the transfer-of-ownership pattern that turns AGENTS.md, .uai/readme.human, and typed .uai files into a predictable load path. A HORMA-style hierarchy should therefore be generated from reviewed AI Memory and Project Handoff material, not treated as a second source of truth. If a hierarchy helps a team find the right constraint, decision, owner, or cold-memory snapshot faster, it is doing its job. If it starts replacing reviewed files, hiding uncertainty, or promoting unreviewed summaries into operating truth, it has crossed the UAIX boundary.

Wizard fit

The AI Memory Package Wizard already generates package models, manifest overlays, knowledge-graph JSON, .uai files, exports, and browser-generated ZIP packages in a local-first review flow. A HORMA integration should extend that same pattern by adding a hierarchy plan and hierarchy export to the review step, together with a preview tree, provenance counts, and bounded retrieval recommendations. The same supported presets, human UI, and visitor AI digest should continue to resolve one canonical payload rather than split into separate human and machine products.

Privacy, provenance, and review

Every hierarchy node should retain a source pointer to the reviewed file, section, route, checksum, or release event that produced it. Sensitive or blocked material should not be promoted into broad retrieval summaries. If a graph or hierarchy projection is exported, it should remain read-only until reviewed, and accepted changes should be written back deliberately to the owning .uai files, docs, tests, machine artifacts, or release pages rather than to the projection cache itself. This is exactly the direction UAIX already publishes for graph-ready handoff memory and for trust-significant release discipline.

When to use it

Use hierarchical memory when flat retrieval starts missing temporal dependencies, when the same project needs routing by entity/date/topic/check/evidence state, when hot files are growing but still need a compact startup surface, or when the next human or agent needs a navigable map rather than one undifferentiated note stream. Do not use it as an excuse to widen support claims beyond published records or to replace reviewed public evidence with hidden retrieval logic.

Related UAIX records

The page should end by linking AI Memory, Project Handoff, Project Handoff Knowledge Graphs, AI Memory Package Wizard, .uai File Guide, Policy and Security, and Changelog. That mirrors existing UAIX page design and helps keep the guide tied to the rest of the public record.

Visual asset suggestions

UAIX’s Press and theme surfaces imply that visuals should be clean, factual, and non-marketing-heavy. For this page I would suggest the following original assets.

These suggestions are grounded in the Wizard’s human-and-AI dual surface, HORMA’s file-tree examples, and UAIX’s approved outward-facing asset discipline.

Technical integration plan for the wizard and spec

Wizard integration steps

The Wizard already has eight steps, with the most natural insertion points being Preset, Active Memory, and Review & Export. I recommend adding a new optional hierarchy mode inside Step 6 and a review/export preview in Step 8 rather than inserting an entirely new step. That preserves the current UX structure, keeps the default Base path compact, and avoids making hierarchical memory look like a baseline UAI requirement. The current wizard already says the base path stays compact and active-memory first, with File Handoff and LLM Wiki remaining optional configuration paths. HORMA should be treated like those: an explicit mode, not the default.

For the UI model, add these fields to the wizard’s local draft and AI digest payload: hierarchy_mode, hierarchy_axes, raw_trace_retention, node_granularity, promotion_policy, review_gate, max_context_tokens, and derived_export_formats. That proposal follows HORMA’s emphasis on structure, provenance, temporal organization, and bounded retrieval, while remaining compatible with UAIX’s existing package model, manifest overlay, knowledge-graph JSON, and browser draft restore behavior.

Specification and registry strategy

Do not change the UAI-1 base envelope first. Instead, create an optional UAIX profile family only after the docs and wizard overlay have stabilized. UAIX’s published reading order already expects new support claims to move through schemas, registry entries, examples, validator output, implementations, and changelog evidence, and the Schemas page explicitly says release-facing changes should flow into Implementations, the Changelog, and References and Contributors. A HORMA integration should respect that pipeline rather than making hierarchy normative too early.

A sensible later profile set would be:

These should be introduced only after there are stable examples, machine artifacts, and validator rules. Until then, keep hierarchy data in wizard exports and guidance documents. That sequencing is consistent with UAIX’s current support-claim discipline.

Data model and storage plan

UAIX’s current file-centric model strongly suggests a source-file canonical + derived export design. The recommended source of truth should remain AGENTS.md, .uai/readme.human, typed .uai files, and accepted project artifacts. Derived hierarchy material should be emitted alongside existing exports as something like .uai/exports/hierarchy.json and optionally .uai/exports/hierarchy-index.json, with any graph projection remaining read-only. This recommendation directly follows the AI Memory page’s export logic and the Project Handoff knowledge-graph guide’s source-of-truth rule.

A practical logical schema for the export layer is:

This is a recommended design derived from HORMA’s workspace and provenance model plus UAIX’s claim/evidence-state discipline.

Privacy, security, and governance controls

If HORMA-style hierarchy exports are added, they need stronger governance than a normal flat note export because hierarchy promotes discoverability. The main risks are privacy leakage through summarization, semantic drift through repeated abstraction, and accidental promotion of blocked or stale claims. Those risks are already recognized in the emerging memory-governance literature, and they line up almost exactly with UAIX’s own trust posture and graph-boundary rules. For UAIX specifically, three controls are essential: per-node sensitivity tags, mandatory provenance on every exported claim, and explicit review-state labels such as proposed, reviewed, current, stale, and blocked.

The site-level governance rule should be simple: if the hierarchy changes what the public trust surface claims, then the same change must appear in the relevant policy page, observable behavior, machine artifacts, and release trail before it is treated as current. That mirrors UAIX’s policy-hub rule for trust-significant changes and prevents silent memory behavior drift from becoming public posture.

Migration, testing, and benchmark plan

Migration should begin in shadow mode. Existing wizard presets and generated bundles should continue to work unchanged, while the new hierarchy mode generates derived exports and preview UI side-by-side with the current outputs. No existing .uai file should become optional or be replaced by hierarchy exports during the first release. This is important because AI Memory currently requires launch-baseline files such as memory-maintenance.uai, identity.uai, world-context.uai, totem.uai, taboo.uai, talisman.uai, and short-term-memory.uai, with additional files for code-bearing packages. HORMA should layer over those, not displace them.

Testing should include deterministic export tests, provenance completeness tests, sensitivity filtering tests, and bounded-retrieval regression tests. Performance testing should be framed in two tiers. The first tier is site/runtime safety: hierarchy generation must not materially slow the wizard’s review step or destabilize browser draft restore. The second tier is memory utility: measure whether hierarchical retrieval reduces average context assembled for the receiving human/agent while preserving or improving task success on representative UAIX handoff scenarios. HORMA’s paper suggests aspirational benchmarks: bounded context packs near 1,000 tokens for conversational retrieval, major token reductions versus flat baselines, and better long-horizon task performance when hierarchy quality is high.

A practical acceptance matrix would look like this:

The targets are recommendations; the constraint logic comes from UAIX and the performance motivation comes from HORMA’s benchmarked efficiency gains.

Developer-facing code examples

The first example shows how to keep a HORMA overlay compatible with UAIX’s existing visitor AI digest pattern on the Wizard page. The supporting fact is that UAIX already publishes machine-readable wizard guidance through script[data-ai-digest] on the same route as the human UI.

/**
 * Read the UAIX wizard AI digest from the current page.
 * Throws if the digest is missing or invalid.
 *
 * @param {ParentNode} root - DOM root to search.
 * @returns {object} Parsed digest payload.
 */
export function readWizardDigest(root = document) {
  const script = root.querySelector("script[data-ai-digest]");
  if (!script) {
    throw new Error("UAIX AI digest not found on this page.");
  }

  const text = script.textContent?.trim();
  if (!text) {
    throw new Error("UAIX AI digest is empty.");
  }

  return JSON.parse(text);
}

/**
 * Merge a local hierarchical-memory overlay into an existing wizard package model.
 * This stays local-first and does not write back to the repository.
 *
 * @param {object} packageModel - Existing UAIX package model JSON.
 * @param {object} hierarchyOptions - User-selected hierarchy settings.
 * @returns {object} New package model with a hierarchical_memory section.
 */
export function attachHierarchyOverlay(packageModel, hierarchyOptions) {
  return {
    ...packageModel,
    hierarchical_memory: {
      enabled: hierarchyOptions.enabled === true,
      mode: hierarchyOptions.mode ?? "none",
      axes: hierarchyOptions.axes ?? ["entity", "date", "topic"],
      node_granularity: hierarchyOptions.nodeGranularity ?? "compact",
      raw_trace_retention: hierarchyOptions.rawTraceRetention ?? "link-only",
      max_context_tokens: hierarchyOptions.maxContextTokens ?? 1000,
      review_gate: hierarchyOptions.reviewGate ?? "manual",
      derived_export_formats: hierarchyOptions.exportFormats ?? ["json"],
    },
  };
}

The second example is a proposed export shape for a read-only hierarchy node. It is designed around HORMA’s need for hierarchy, temporal anchoring, and raw-trace linkage, while preserving UAIX-style provenance and review-state tracking.

{
  "node_id": "mem.topic.lgbtq-support-group",
  "parent_node_id": "mem.topic.lgbtq",
  "kind": "topic",
  "title": "LGBTQ support group",
  "summary": "Accepted current facts relevant to ongoing project memory.",
  "time_range": {
    "start_utc": "2026-06-13T00:00:00Z",
    "end_utc": "2026-06-13T00:00:00Z"
  },
  "state": "reviewed",
  "sensitivity": "internal",
  "raw_refs": [
    {
      "source_path": ".uai/decisions.uai",
      "source_section": "Decision 3",
      "checksum_sha256": "..."
    }
  ],
  "retrieval_hints": {
    "keywords": ["support", "topic", "context"],
    "max_summary_tokens": 120
  }
}

The third example is a minimal PostgreSQL storage layer for an optional offline or bridge-track implementation. It uses timestamptz, which should be managed with application/session time in UTC.

create table if not exists memory_node (
    node_id text primary key,
    parent_node_id text null references memory_node (node_id),
    kind text not null,
    title text not null,
    summary text not null,
    state text not null check (state in ('proposed', 'reviewed', 'current', 'stale', 'blocked')),
    sensitivity text not null check (sensitivity in ('public', 'internal', 'restricted')),
    start_utc timestamptz null,
    end_utc timestamptz null,
    created_utc timestamptz not null default current_timestamp,
    updated_utc timestamptz not null default current_timestamp
);

create table if not exists memory_evidence_ref (
    evidence_ref_id bigserial primary key,
    node_id text not null references memory_node (node_id),
    source_path text not null,
    source_section text null,
    checksum_sha256 text null,
    review_event_id text null,
    created_utc timestamptz not null default current_timestamp
);

create index if not exists ix_memory_node_parent on memory_node (parent_node_id);
create index if not exists ix_memory_node_state on memory_node (state);
create index if not exists ix_memory_evidence_ref_node on memory_evidence_ref (node_id);

Documentation, releases, risks, and roadmap

Documentation updates to make together

A HORMA integration should not land on one page only. At minimum, update AI Memory, Project Handoff Knowledge Graphs, the AI Memory Package Wizard page, Get Started, and Changelog. If formal profiles are later added, then Schemas, Registry, Examples, Validator, API Reference, Implementations, and Conformance Pack should also be updated in the same release family. This mirrors both the Schemas page instruction to carry release-facing changes into Implementations, Changelog, and References, and the changelog’s own expectation that entries capture affected records, change type, migration notes, and links to updated canonical documents.

A concise documentation plan is below.

This is the smallest update set that fits UAIX’s documentation-led governance model.

Sample changelog and release-note language

UAIX’s changelog format is explicit enough that HORMA can be introduced cleanly. A suitable entry would be:

Change type: Additive AI Memory and wizard guidance update. Affected records: AI Memory, Project Handoff Knowledge Graphs, AI Memory Package Wizard, Get Started, Changelog, and related release-note language. Migration note: use the published hierarchical-memory guide and local-first wizard overlay when reviewable hierarchy planning is needed; keep .uai files and reviewed handoff records as the source of truth; do not infer hosted graph APIs, automatic repository writing, SDK/CLI support, or new runtime adapters. Support-claim effect: UAIX now publishes bounded public guidance and local-first planning exports for hierarchical memory without widening hosted-runtime or certification claims.

A public-readable release note can be shorter: UAIX now publishes a HORMA-style hierarchical-memory guide and a local-first wizard planning overlay for teams that need navigable project memory, while keeping reviewed .uai files and Project Handoff bundles as the canonical memory surface. That phrasing stays within the site’s press and support-boundary rules.

Risks and research gaps

The biggest product risk is overclaiming. HORMA is a compelling primary paper, but in the materials reviewed here it is still a brand-new research result rather than a mature public implementation surface comparable to UAIX’s own published routes and packages. Publishing a guide is justified; publishing a large normative or hosted-memory claim is not. UAIX’s own public language guidance strongly supports this conservative stance.

The biggest technical risk is semantic drift through abstraction. Both HORMA and the broader governance literature imply that repeated coarsening can help or harm, depending on whether the hierarchy keeps the right provenance and detail links. The Project Handoff knowledge-graph guide already answers this in spirit: derived structures are useful, but they must remain subordinate to reviewed sources and must not become hidden write-back targets.

Another open research gap is transfer from benchmarks to repository memory. HORMA is evaluated on ALFWorld, LoCoMo, and LongMemEval. Those are meaningful long-horizon settings, but they are not identical to UAIX’s real target domain of project-memory bundles, handoff files, docs, release records, and public standard artifacts. That does not weaken HORMA’s conceptual value, but it does mean UAIX should benchmark on its own representative handoff and documentation cases before moving from guide-level support to validator-backed profile-level support.

Prioritized roadmap

The recommendation is to stop after the second or third milestone unless UAIX-specific benchmark evidence is strong enough to justify normative schema work. That is the lowest-risk path that still captures most of HORMA’s immediate value.

Source priorities

The source strategy used for this report should also be the source strategy used in publication.

That priority order matches UAIX’s own “primary record first” posture and the user’s request to prefer original/official publications.

Open questions and limitations

A few important unknowns remain. The reviewed HORMA materials clearly describe the framework and publish strong benchmark results, but they do not, in the sources reviewed here, provide the same kind of public implementation/package surface that UAIX already expects when widening support claims. The best response is not to wait indefinitely, but to publish the guide first and keep the rest of the roadmap evidence-driven.

The optimal hierarchy shape for UAIX content is also not settled. HORMA’s appendix examples suggest people/date/topic-style directories, while UAIX’s own knowledge-graph guide emphasizes projects, bundles, documents, claims, constraints, checks, decisions, and cold-memory records. A UAIX integration will probably need a domain-tuned hybrid of both, and that tuning should be tested on real handoff bundles rather than copied directly from benchmark conversations.

Finally, the point at which hierarchy becomes normative remains an organizational decision, not a purely technical one. UAIX’s current public record argues for caution: new claims should move through public docs, machine artifacts, validator evidence, implementations, policy/trust review, and the changelog. For HORMA, that means the guide can be strong now, but spec-level commitment should come later, after shadow-mode data shows that the added complexity pays for itself.