Hierarchical Goal Memory for UAIX Long-Running Work | UAIX | Universal Artificial Intelligence Exchange

Hierarchical Goal Memory organizes work that has to survive context limits without turning summaries into authority. It lets a receiving human or agent fold completed subgoals into reviewed records, retrieve only bounded evidence for the next slice, and keep source files canonical.

Decision rule

Use Hierarchical Goal Memory when one goal is too large for a single prompt, but do not promote a derived summary until the accepted result is reviewed and written back to authoritative files. The hierarchy is a navigation aid. Reviewed source files, public records, and named evidence packets remain the source of truth.

Core terms

Core terms
UAIX term	Meaning	Boundary
Hierarchical Goal Memory	A source-linked view of goal, subgoal, checkpoint, blocker, handoff, and final-report state.	Not a hosted memory service or runtime state store.
Subgoal Folding	After review, compress a completed subgoal into a small Folded Record with links back to evidence.	Do not delete source evidence or hide blockers.
Folded Record	A compact summary containing outcome, changed files, checks, blockers, evidence links, and next action.	Derived until accepted write-back lands in current memory or docs.
Derived Memory Hierarchy	A tree or outline over current goal state, source files, checkpoints, and evidence packets.	Projection only; Source-file canonical remains the rule.
Bounded Evidence Retrieval	Load the smallest source slice needed to verify or continue the next subgoal.	Do not use broad retrieval to bypass context-budget or review gates.
Context Pack	A fresh-context bundle with goal, completed folds, active blockers, relevant source references, and checks.	It is a handoff aid, not a credential, certification, or execution permission.

Operating loop

Start from source: read the current user instruction, active File Handoff intake, .uai memory, public route records, and the latest test or deployment evidence that applies.
Name the hierarchy: split the goal into bounded subgoals with success criteria, likely files, checks, and non-goals.
Run one slice: edit only the selected slice and keep runtime state separate from durable memory.
Checkpoint: emit current subgoal, files changed, completed work, Folded Record, remaining work, blockers, tests run or skipped, exact next action, proposed memory updates, and UTC timestamp.
Review-gated promotion: write accepted results into .uai/progress.uai, relevant typed active .uai records, docs, code, tests, release notes, roadmap state, machine artifacts, or archive evidence only after review.
Fresh-context review: when context is reset, rebuild the Context Pack from canonical files plus accepted folds instead of trusting the last chat turn.

Use existing UAI-1 packets first

Do not create a new core envelope just because the work is hierarchical. Use existing packet families before proposing new schema work.

uai.agent.task-status.v1 for current subgoal state and measurable progress.
uai.agent.blocker.v1 for blocked action, cause, missing evidence, and human decision needed.
uai.agent.handoff.v1 for coordinator/worker transfer or runtime-to-reviewer transfer.
uai.agent.memory-proposal.v1 for proposed write-back that still needs acceptance.
uai.agent.final-report.v1 for completed goal evidence and final response requirements.

Fresh-context checkpoint template

Code example

Current subgoal: <subgoal id and title>
UTC timestamp: <current UTC ISO-8601>
Files changed: <paths or no-change evidence>
Completed work: <accepted outcome>
Folded Record: <compact source-linked summary>
Remaining work: <next bounded work items>
Blockers: <none or exact blocker>
Tests run/skipped: <commands, skipped reasons, residual risk>
Exact next action: <one action>
Proposed memory updates: <review-gated targets>

Support boundary

This guide is documentation and package guidance. UAIX does not provide hosted runtime execution, scheduling, a memory database, graph database, vector database, hosted retrieval, public write API, MCP server, SDK, CLI, automatic repository writing, hosted import, automatic sync, certification, endorsement, or proof that a derived hierarchy is correct. A derived hierarchy becomes trusted only when its accepted slice is written back to canonical source or public records with evidence.

Wizard placement

The AI Memory Package Wizard exposes Hierarchical Goal Memory as a default-off local export for packages that need it. When selected, the browser-generated package includes a reviewable instruction file and structured export describing source-file canonical rules, folded-record fields, bounded retrieval, packet reuse, non-claims, and UTC timestamp requirements. The wizard does not upload the package, sync memory, certify the result, or write to a repository.

Machine-readable page digest

Agents should treat this digest as route orientation, not runtime authority.

Code example

{
    "id": "uaix.hierarchical_goal_memory.guide.v1",
    "route": "https://uaix.org/en-us/guides/hierarchical-goal-memory/",
    "title": "Hierarchical Goal Memory for UAIX Long-Running Work",
    "status": "guide-level current documentation",
    "canonical_authority": "reviewed source files and public records",
    "derived_structures": [
        "Derived Memory Hierarchy",
        "Folded Record",
        "Context Pack"
    ],
    "existing_packets": [
        "uai.agent.task-status.v1",
        "uai.agent.blocker.v1",
        "uai.agent.handoff.v1",
        "uai.agent.memory-proposal.v1",
        "uai.agent.final-report.v1"
    ],
    "support_boundary": "UAIX publishes guidance and reviewable evidence patterns; it does not host a runtime, scheduler, memory database, graph database, vector database, SDK, CLI, automatic writer, importer, sync service, certification, or endorsement.",
    "last_updated_utc": "2026-06-13T00:00:00Z"
}

Decision rule#

Core terms#

Operating loop#

Use existing UAI-1 packets first#

Fresh-context checkpoint template#

Support boundary#

Wizard placement#

Related UAIX records#

Machine-readable page digest#