Integrating Openai Follow Goals With UAIX Memory Files And The UAIX Memory Wizard

The strongest integration pattern is **not** to treat OpenAI Follow Goals as a new durable memory system. The public OpenAI guidance currently documents Goal mode as a **runtime control layer** for Codex threads: a pe...

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-62a797da/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-11/openai-follow-goals-wizard/Improvement/Integrating OpenAI Follow Goals with UAIX Memory Files and the UAIX Memory Wizard.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-11T20:06:23.8473721Z
Content hash	sha256:62a797da8671d0e72ffc09fcb2ca8fff6cfb990f9d5b9d7441d1d8c1925a0e41
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-11-openai-62a797da8671.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-11-openai-62a797da8671.txt

Current File Content

Structure Preview

• Integrating OpenAI Follow Goals with UAIX Memory Files and the UAIX Memory Wizard
• Executive summary
• Current OpenAI Follow Goals guidance
• Current UAIX memory files and memory-wizard capabilities
• Mapping Follow Goals to UAIX memory files
• Proposed field-by-field mapping
• Proposed machine export
• Proposed human-facing file snippets
• receiver-brief.uai
• short-term-memory.uai
• UX design and UAIX documentation draft
• Proposed wizard UI
• Validation rules
• Privacy and security implications
• Draft UAIX documentation page
• Example: Codex Goal mode handoff text
• Example: OpenAI Responses API request with UAIX files
• Goal
• Success criteria
• Constraints
• Output
• Stop rules

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: 38571
• Preview characters: 11958

# Integrating OpenAI Follow Goals with UAIX Memory Files and the UAIX Memory Wizard

## Executive summary

The strongest integration pattern is **not** to treat OpenAI Follow Goals as a new durable memory system. The public OpenAI guidance currently documents Goal mode as a **runtime control layer** for Codex threads: a persistent objective attached to the active thread, with pause/resume/clear controls, measurable completion criteria, and a recommendation to use `/plan` first when the goal is not yet crisp. In parallel, the OpenAI API guidance for long-running agentic work emphasizes structured prompting with explicit **Goal / Success criteria / Constraints**, plus `conversation`, `background`, file inputs, and persisted reasoning or conversation state. In the material reviewed, I did **not** find a public top-level Responses API `goal` parameter; the documented “goal” capability is in Codex product surfaces, while the API guidance exposes goal-shaped prompting patterns rather than a native request field. citeturn7view0turn8view0turn6view0turn13view1turn13view3turn13view0turn13view2turn12search0turn13view4

UAIX, by contrast, is explicitly organized around **reviewable, local-first, typed memory and handoff files**. The AI Memory Package Wizard already generates `.uai` files, startup packets, receiver briefs, system profiles, manifest overlays, JSON exports, `llms.txt`, and copy blocks for Codex, Claude, and GPT agents, while also stating that it is **not** a hosted importer, auto-sync layer, SDK, CLI, repository writer, or certification surface. UAIX’s file guide also makes clear that `.uai` records are structured package records with a closed required-file-set model, and that hot handoff files should remain compact while broader history belongs in wiki/archive layers. citeturn23view0turn33view4turn34view3turn25view0turn26view0turn28view0turn23view3

Because of that difference in purpose, the recommended design is **additive and backward-compatible**: add an optional wizard setting named **“Alternative: Follow Goals”** that generates goal-aware exports and prompt blocks, while keeping existing UAIX files as the durable source of truth. Concretely, the wizard should write a proposed `follow_goal` block into `.uai/receiver-brief.uai` and `.uai/startup-packet.uai`, mirror lightweight goal state into `.uai/short-term-memory.uai`, and optionally emit a machine export such as `.uai/exports/follow-goal.json`. Existing UAIX packages should continue to work unchanged when the setting is off. This aligns with UAIX’s current support boundary and with OpenAI’s documented runtime-vs-memory split. citeturn35view4turn34view3turn25view0turn26view0turn27view0turn7view0turn18view0

The practical result is a two-lane architecture. **Lane one** is durable UAIX memory: accepted context, constraints, progress, operations, decisions, and project handoff files. **Lane two** is runtime execution: either Codex Goal mode through `/goal`, or the Responses API using a structured Goal / Success Criteria / Constraints prompt plus attached UAIX files, conversation state, and background mode when needed. That separation keeps goals easy to execute while preventing “current task intent” from silently becoming long-term truth. citeturn7view0turn8view0turn13view3turn13view0turn13view2turn25view0turn26view0turn28view0

## Current OpenAI Follow Goals guidance

OpenAI’s current public documentation presents Follow Goals through **Codex Goal mode**. The core behaviors are consistent across the Codex app, IDE extension, and CLI: `/goal <objective>` sets the goal, `/goal` views it, and `/goal pause`, `/goal resume`, and `/goal clear` control it while the goal remains attached to the active thread. OpenAI also documents that the goal text acts as both the **starting prompt** and the **completion criteria**, and that the objective must be non-empty and at most **4,000 characters**; for longer instructions, the guidance is to put the details in a file and point the goal to that file. citeturn6view0turn6view1turn7view0turn8view0

The docs also describe the current product UX around goals. In the Codex app, when a goal is active, progress appears above the composer with controls to **pause, resume, edit, or clear** the goal, and the user can continue steering the task with follow-up messages while the goal runs. OpenAI’s changelog further says Goal mode is no longer experimental and is available in the app, IDE extension, and CLI, although the app and CLI docs still keep a compatibility fallback telling users to enable `features.goals` if `/goal` does not appear. citeturn8view0turn7view0turn9search6

OpenAI’s recommended writing pattern for a goal is very explicit: the goal should name a **specific outcome**, include a **measurable target** or **test criteria**, and make it easy for Codex to determine whether it has succeeded. When the target is not well-formed yet, OpenAI recommends starting with `/plan` so the agent can help shape the goal before execution starts. The same guidance also recommends continued steering with follow-up constraints and using side conversations for recap or explanation rather than interrupting the main task. citeturn7view0turn8view0turn6view0

For API users, the relevant public guidance is adjacent rather than identical. OpenAI’s prompt guidance recommends a structured prompt with sections for **Goal**, **Success criteria**, **Constraints**, **Output**, and **Stop rules**. For long-running or tool-heavy work, OpenAI separately recommends `conversation` or `previous_response_id` for continuity, `background: true` for long-running tasks, file inputs for larger instruction payloads, and persisted reasoning or stored context for better follow-up performance. In the request parameter section I reviewed for `POST /responses`, OpenAI documents fields such as `background`, `context_management`, `conversation`, and `include`; I did not find a documented public top-level `goal` request parameter in that material. citeturn13view3turn13view0turn13view2turn12search0turn13view4turn15view0turn13view1

That yields the following implementation reading for UAIX:

| OpenAI construct | Current documented surface | What is documented | Integration implication for UAIX |
|---|---|---|---|
| Persistent goal | Codex app / IDE / CLI | Goal stays attached to the active thread. citeturn6view0turn8view0 | Map to runtime-only goal state, not durable truth by default. |
| Goal text = start + done criteria | Codex Goal mode | Goal text drives both execution and completion checking. citeturn7view0 | Store primary objective plus explicit success criteria in receiver-facing files. |
| Pause / resume / clear | Codex Goal mode | Runtime controls are first-class. citeturn6view0turn8view0 | Add goal status fields to short-term memory only. |
| Goal length limit | Codex Goal mode | Non-empty, max 4,000 chars; use files for more. citeturn6view0 | Validate goal length in wizard; force file references above the cap. |
| Plan before goal | Codex Goal mode | Use `/plan` when the goal is not clear yet. citeturn7view0turn8view0 | Add an optional “plan first” toggle in the wizard export. |
| API equivalent | Responses API + prompt guidance | Goal-shaped prompting, file inputs, conversation state, background mode. citeturn13view3turn13view0turn13view2turn15view0 | Generate a structured prompt block rather than a native `goal` field. |

The key design constraint is therefore simple: **Codex Goal mode is native; Responses API Goal mode is prompt-mediated**. UAIX should support both, but it should present them honestly as different execution surfaces. citeturn8view0turn13view3turn13view1

## Current UAIX memory files and memory-wizard capabilities

UAIX’s AI Memory guidance is centered on **compact, reviewable project memory** and on a clear boundary between **hot handoff files** and **cold wiki/archive memory**. The AI Memory page tells users to start with the wizard, keep startup context compact, preserve broader background in LLM Wiki or archive systems, and treat reviewed current records—not raw notes, generated summaries, or all history—as the active truth. UAIX’s Context Budget guide reinforces that split by telling teams to archive long research and only promote accepted facts back into hot files. citeturn25view0turn23view3

The `.uai` file guide is unusually explicit about required scopes. Every package starts with a closed required-file-set model: `.uai/memory-maintenance.uai`, `.uai/identity.uai`, `.uai/world-context.uai`, and `.uai/short-term-memory.uai` are universal launch-baseline files; Project Handoff packages then add `.uai/startup-packet.uai`, `.uai/system-profile.uai`, and `.uai/receiver-brief.uai`; additional files such as `.uai/context.uai`, `.uai/constraints.uai`, `.uai/progress.uai`, `.uai/operations.uai`, `.uai/test-plan.uai`, `.uai/coding-standards.uai`, `.uai/next-recursive-prompt.uai`, `.uai/decisions.uai`, `.uai/memory.uai`, `.uai/long-term-memory.uai`, and `.uai/file-handoff.uai` are activated by profile or content. UAIX also publishes a required **read order**, beginning with `AGENTS.md` or `.uai/readme.human`, then memory maintenance, identity, world context, guardrail files, short-term memory, and only then profile-specific files and long-memory pointers. citeturn26view0turn27view0turn28view0turn29view0

The wizard is already close to what an OpenAI integration needs. It is an **eight-step local-first planner** with steps for Preset, Basics, Collaboration, Operations, Governance, Active Memory, Receiver, and Review & Export. It stores a local browser draft, provides page-level validation and prompt nudges, and can generate startup packets, system profiles, receiver briefs, manifest overlays, JSON exports, `llms.txt`, `llms-full.txt`, File Handoff and LLM Wiki planning files, and copy blocks for Codex, Claude, and GPT. The wizard repeatedly states that previews and browser-generated ZIPs remain local and do not upload, sync, import, certify, or write to repositories. citeturn33view0turn33view4turn33view5turn34view3

The wizard’s current settings also expose the right places to extend. In Step 1 it already asks users to declare package facts that change the required file set, including code-like work, tool permissions, contact memory, calendar memory, communication style memory, tasks and commitments, routines and preferences, safety/support boundaries, source notes, and public-facing boundaries. In Step 6 it configures local Active Memory, background compilation into `.uai/exports/*`, Safe Structured Output Mode, and optional LLM Wiki planning. In Step 7 it defines the receiver, success evidence, first task, launch-baseline read order, and optional File Handoff behavior. citeturn34view0turn34view2turn35view2turn35view4turn35view5

On file format, the public picture is **partly specified and partly unspecified**. UAIX clearly says `.uai` files are typed records, publishes minimal examples for many files with common top-level fields such as `file`, `required_status`, `owner`, `current_state`, `no_op_trigger`, `evidence`, and `last_reviewed`, and explicitly says that `next-recursive-prompt.uai` is a derived artifact using canonical JSON profile `uaix.next-recursive-prompt.v1`. At the same time, from the pages reviewed I did **not** find a complete public field-by-field JSON schema for every `.uai` file, nor a normative external contract for a wizard-generated Follow Goals record. UAIX also says the page-level machine-readable digests are orientation evidence, not runtime authority. citeturn32view0turn32view1turn32view2turn31view1turn32view3turn26view0turn29view0

Because of that, the safest implementation options are these:

| Schema option | Description | Fit with current UAIX evidence | Pros | Cons | Recommendation |
|---|---|---|---|---|---|

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 OpenAI Follow Goals with UAIX Memory Files and the UAIX Memory Wizard; Executive summary; Current OpenAI Follow Goals guidance; Current UAIX memory files and memory-wizard capabilities; Mapping Follow Goals to UAIX memory files; Proposed field-by-field mapping; Proposed machine export; Proposed human-facing file snippets. 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-475 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Integrating Openai Follow Goals With UAIX Memory Files And The UAIX Memory Wizard",
    "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-62a797da/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-11/openai-follow-goals-wizard/Improvement/Integrating OpenAI Follow Goals with UAIX Memory Files and the UAIX Memory Wizard.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:62a797da8671d0e72ffc09fcb2ca8fff6cfb990f9d5b9d7441d1d8c1925a0e41",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-11T20:06:23.8473721Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-475",
    "duplicate_role":  "primary",
    "related_files":  [

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