Hierarchical Goal Memory for UAIX Long-Running Work

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#

Operating loop#

1. 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.
2. Name the hierarchy: split the goal into bounded subgoals with success criteria, likely files, checks, and non-goals.
3. Run one slice: edit only the selected slice and keep runtime state separate from durable memory.
4. 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.
5. Review-gated promotion: write accepted results into .uai/progress.uai, .uai/short-term-memory.uai, docs, code, tests, release notes, roadmap state, machine artifacts, or archive evidence only after review.
6. 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#

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.

Related UAIX records#

• Long-Running Goal ExecutionRuntime goal overlays, checkpoints, blockers, final reports, and reviewed write-back.
• Project Handoff Context BudgetHot/cold memory rules for keeping handoff context compact.
• Project Handoff Knowledge GraphsStable IDs, provenance, claim nodes, and derived projection boundaries.
• Project HandoffRepository-local durable memory and handoff source pattern.
• AI MemoryPortable memory framing and starter packages.
• .uai File GuideTyped memory files and package-scope rules.
• Agentic Harness Strategies And UAIKeep runtime execution separate from portable evidence.
• Standards FitKeep support claims tied to public proof.
• RoadmapCurrent and planned boundaries.

Machine-readable page digest#

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

{
    "id": "uaix.hierarchical_goal_memory.guide.v1",
    "route": "http://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"
}

[]