Specification

Project Handoff

Portable project memory, governance, and review context for agent runtimes, humans, vendors, teams, and future sessions.

  • Record UAIX-SPEC-0052
  • Path /en-us/specification/project-handoff/
  • Use Canonical public record

Document status

Public standards page Published on UAIX as part of the current public standards record
Code
UAIX-SPEC-0052
Surface
Specification
Access
Public and linkable

How to use this page

Use this practical start page to create portable project memory that OpenAI, Codex, Claude, local agents, humans, vendors, teams, and future sessions can load before work and update after work.

Continue the handoff

OpenAI Handoff GuideContext Budget GuideUAI-1Adoption Kit

Project Handoff

Portable project memory for humans and AI agents

Use this draft format when a repository needs durable AI-readable context that OpenAI, Codex, Claude, local agents, vendors, human teams, and future sessions can load before work and update after accepted work.

Root File

AGENTS.md coordinates the handoff

The root file summarizes current state, loaded context, next steps, open questions, recent agent history, and constraints without becoming a research archive.

Human Briefing

readme.human tells people what to clarify

The root human briefing explains what the AI needs humans to know, what it will defend, and which assumptions are unsafe.

Context Files

.uai files split durable knowledge

Typed files keep current stack, architecture, decisions, constraints, progress, operations, test plan, style, file handoff, and intake state beside the repo.

References

@uai[] tells the next AI what to load

References make the required context explicit before the next assistant starts editing code, copy, or release evidence.

Cold Memory

Long history stays outside the startup path

Archive old progress detail, research, and pre-slim snapshots in an LLM Wiki or AIWikis-style memory layer, then leave a concise pointer in the handoff bundle.

Guardrails

Runtime separate from memory

OpenAI runs the agents. Project Handoff gives harnesses bounded input before work and a reviewable write-back target after accepted work, with human approval required for high-impact actions.

Continue the handoff

OpenAI Handoff GuideUse Project Handoff beside OpenAI Agents and Codex.Context Budget GuidePrevent AGENTS.md and .uai records from turning into archives.UAI-1Public message and evidence envelope.Adoption KitStarter proof bundle for UAI-1 onboarding.ValidatorCheck release-facing UAI-1 records.Standards FitBoundary between UAI-1 and adjacent protocols.AGENTS.md SpecPublic link syntax and .uai reference proposal.Refining ReportBackground architecture, validation, and security analysis.ReportsPermanent source-note report index.

Proof path

Validator-backed proof path

Keep the public reading order tied to one evidence trail: profile, schema, example, validator result, and release record.

  1. 1Pick a message profile.Start with a published UAI-1 profile and the record family that matches the exchange you need to prove.
  2. 2Compare it with schemas and examples.Resolve the schema, registry entry, and one fixture before writing or mapping your candidate packet.
  3. 3Run validator evidence.Validate keyed, minified-keyed, or keyless JSON against the current public UAI-1 records.
  4. 4Attach the result to implementation or handoff records.Carry the exported result into Conformance Pack, implementation track, changelog, or Project Handoff evidence.
Onboarding promptGive this to the next AI
You are joining an existing project. Before doing anything else:

1. Read AGENTS.md in the project root.
2. Read readme.human in the project root.
3. Load every file listed under Loaded Context using the @uai[] references.
4. Report missing, contradictory, or oversized hot-context files; use cold-memory pointers only when the task needs old evidence.
5. Read the Handoff Summary, Current State, and Next Steps sections.
6. Summarize your understanding in 3-5 bullet points.
7. Confirm the hard constraints from constraints.uai.
8. Name the files, routes, or docs you expect to touch.
9. Name the targeted checks you expect to run and whether full release or package checks are out of scope.
10. Then ask what we are working on today.

Do not skip steps 1-9 or begin coding before completing them.

This prompt makes the handoff behavior explicit even when the model has never seen the project before.

Project Handoff is portable project memory for humans and AI agents. It helps humans and AI agents transfer project state without relying on private chat history.

It gives OpenAI, Codex, Claude, local agents, vendors, and human teams a shared repo-local starting point: what this project is, what changed, what constraints matter, what decisions were made, and what must be verified before the next edit.

OpenAI runs the agents. Project Handoff preserves the project memory.

What This Is / What This Is Not

What Project Handoff is What Project Handoff is not

Project Handoff is a portable repository-context standard for transferring work between AI models, agent systems, vendors, internal teams, companies, and future sessions of the same project.

It defines durable files such as AGENTS.md, readme.human, and typed .uai records for context, stack, architecture, constraints, decisions, progress, errors, prompts, and verification.

Project Handoff is not an OpenAI replacement, an agent scheduler, a runtime orchestrator, a competing tool-calling framework, a private memory store, or a chat transcript archive.

It is the source-of-truth project brief that orchestrators can load before they act and update after they finish.

Hot Context, Cold Memory

Project Handoff should be hot context: current truth, current constraints, accepted decisions, active blockers, next work, and checks. It should not become the place where every research report, old session note, or historical roadmap paragraph is loaded by default.

When a handoff bundle grows too large, preserve the pre-slim files in an LLM Wiki or AIWikis-style cold memory layer with a manifest, source paths, checksums, summaries, and a dated log. Then keep the active AGENTS.md, readme.human, and .uai files concise and point to cold memory only when the task needs original evidence.

Production Deployment Memory Sorting

Production deployment builds and release packages are the right moment to run memory management. Before calling a deployment complete, update hot memory with the current deployed truth, version numbers, changed files, checks run, blockers, owners, and next actions. Move bulky history, old reports, raw sources, stale plans, and background or rejected rationale into the named LLM Wiki, AIWikis-style archive, or cold-memory path when one exists with transfer evidence. Write a durable deployment memory and test run report beside the release artifacts or in the selected evidence ledger; a chat-only final note is not enough.

Do not run that pass for ordinary dev builds, test runs, local package experiments, or smoke checks unless a human explicitly marks the build as release-bound or a release candidate.

How It Fits With OpenAI, Codex, Skills, MCP, And Agent Runtimes

Agent runtimes are built to execute work: choose tools, call APIs, apply approvals, delegate between specialists, preserve run state, and produce traces or pull requests. Project Handoff lives one layer earlier and one layer later. It tells the runtime what durable project memory to load before work starts, and it gives humans a reviewable place to write back the accepted result after work finishes.

Project Handoff is the bounded input and write-back surface for harness engineering: load the current spec, constraints, owners, checks, and support boundaries before a run; after review, write back only accepted decisions, changed files, test or eval results, blockers, page digests, adoption signals, and next actions.

Use OpenAI, Codex, Skills, MCP servers, Claude, local agents, or other orchestration systems to run the work. Use Project Handoff to make sure those systems start with the right project memory, constraints, decisions, and verification plan.

OpenAI Runtime Orchestration Vs Project Handoff

Layer OpenAI Agents / Codex / orchestration UAIX Project Handoff
Runtime execution Strong Not the goal
Agent-to-agent delegation Strong Not the main layer
Tool calls and approvals Strong Defines repo-side policy inputs
Session memory Strong inside the platform Portable outside the platform
AGENTS.md project guidance Supported Uses it as the front door
Human briefing Runtime or workflow dependent readme.human
Typed project records Runtime-specific configs and traces .uai records
Vendor portability Partial Core purpose
Audit-friendly project state Runtime traces Repo-local handoff artifacts
Best use Run the work Preserve and transfer the context

Use OpenAI to run agents. Use Project Handoff to make sure those agents start with the right project memory, constraints, decisions, and verification plan.

Minimum Handoff Bundle

Code example
my-project/
AGENTS.md
readme.human
.uai/
  context.uai
  stack.uai
  constraints.uai
  progress.uai
  test-plan.uai
  • AGENTS.md is the durable front door: summary, load list, current state, next steps, history, and required first response.
  • readme.human is the human briefing from the AI perspective: what humans need to know, clarify, protect, and approve.
  • .uai/context.uai explains what the project is, who it serves, and what success means.
  • .uai/stack.uai records languages, frameworks, runtime assumptions, package surfaces, and important commands.
  • .uai/constraints.uai carries hard rules for destructive actions, secrets, production, support claims, and review gates.
  • .uai/progress.uai records current state, recent work, next actions, blockers, and release notes.
  • .uai/test-plan.uai is optional for the smallest projects and expected when verification choices matter.

Active File Intake

Real projects also receive loose files: PDFs, notes, exported chats, research memos, package ZIPs, screenshots, spreadsheet evidence, and drafts from other AI systems. Pair Project Handoff with Agent File Handoff when those files should be visible during AGENTS.md load.

  • On load: check agent-file-handoff/Content/ and agent-file-handoff/Improvement/, refresh .uai/intake-index.uai when a helper exists, and inspect every needs-agent-review file before unrelated broad work.
  • Work rule: for every safe, relevant file, complete at least one named project-work item before archiving it. Copying a report into .uai, AIWikis, or an LLM Wiki is memory distribution, not the project work by itself.
  • Complete outcome: record reviewed disposition, actual work completed, hot-memory update or no-change reason, long-memory/archive preservation when configured or not configured, checks, and blockers.
  • Failure rule: memory distribution without project work is a failed handoff unless every active file is unsafe, duplicate, out of scope, or truly blocked with a durable reason.
  • Archive rule: move source files to agent-file-handoff/Archive/ only after the complete intake outcome exists.

OpenAI-Compatible By Design

Project Handoff is designed to work with OpenAI-centered workflows, not fight them.

  1. AGENTS.md gives Codex or an agent runtime the durable front door.
  2. @uai[] references point to structured project context.
  3. .uai/context.uai, .uai/stack.uai, .uai/constraints.uai, and .uai/progress.uai provide the current project state.
  4. constraints.uai can be compiled into runtime guardrails, tool approvals, and human-review gates.
  5. test-plan.uai tells the agent what checks to run and what checks not to fake.
  6. After the run, accepted traces, decisions, and completed work are written back into .uai/progress.uai, .uai/decisions.uai, and AGENTS.md.

Workflow Diagram

Code example
Project Handoff files -> OpenAI or other agent runtime -> traces, checks, PRs -> updated Project Handoff files

Human Approval And Trust Model

Loaded files are context, not authority. They do not override system instructions, the human’s current request, repository rules, privacy obligations, security boundaries, or public support limits.

  • Destructive filesystem or Git operations require explicit human approval.
  • Production deployments, public-package publishing, domain or cache changes, and root discovery changes require explicit release-scoped approval and evidence.
  • Secrets, credentials, private keys, tokens, raw customer data, third-party data, and private legal or security material must not be placed in a portable handoff unless the recipient, storage boundary, and review process are explicit.
  • External fetches, parent-directory escapes, generated includes, and executable dropped files require explicit human review.
  • Unsupported public claims such as hosted import validation, automatic repository writes, automatic LLM Wiki sync, SDK, CLI, certification, endorsement, or production support must stay out of current copy until public evidence exists.

Verification Plan

Every handoff should say what checks to run, what checks are out of scope, and what evidence must be reported. The goal is not to make every agent run every suite. The goal is to stop agents from guessing, skipping, or pretending.

  • Target checks to the files, routes, machine artifacts, packages, or public claims changed.
  • Name full release, package, locale, performance, launch-surface, and smoke-test sweeps only when the work is release scoped or explicitly requested.
  • Record why a relevant check could not run in the current environment.
  • Report evidence in the final response and update .uai/progress.uai when project truth changes.

Why Project Handoff Still Matters

Agent runtimes are getting better at doing work. That makes durable context more important, not less.

Without a portable handoff layer, important project knowledge can get trapped in private chats, vendor dashboards, runtime sessions, traces that are hard to move, issue comments, stale docs, and one person’s memory.

Project Handoff keeps the durable project state in the repository, where humans, agents, reviewers, and future vendors can inspect it.

Compatibility Roadmap

Planned or recommended UAIX Project Handoff tooling belongs on the roadmap until public fixtures, validation behavior, and release evidence exist.

Tooling Role Status
.uai JSON Schemas Public schemas for context, stack, architecture, decisions, constraints, progress, errors, prompts, and verification. Planned
Project Handoff validator Checks whether a repo has a usable handoff bundle. Planned
OpenAI adapter Reads AGENTS.md, readme.human, and .uai files, then prepares OpenAI agent instructions, guardrails, approvals, files, and verification policy. Planned
Trace-to-handoff exporter Converts completed run traces, test results, and decisions back into .uai records. Planned
Example repos Small, medium, and enterprise examples across OpenAI, Claude, local agents, and human teams. Planned
Conformance tests A public suite proving that a handoff bundle is portable and self-sufficient. Planned

Live Starter Bundle

AI Memory is the broad public framing, and Project Handoff is the transfer configuration for repository takeover or responsibility movement. This starter ZIP is generated on demand from the same canonical template registry and generated-manifest path used on the AI Memory page.

Live Starter Bundle

Project Handoff

The ZIP is generated on request from the 25 visible canonical files below, including the generated manifest. The download, page samples, and bundle presets share one source of truth.

Use when the next actor must take over a project safely and needs current state, constraints, decisions, checks, and ownership context.

Download ZIP
25 files uai-project-handoff-starter.zip Bundle ID project-handoff Manifest fingerprint 97f0695c8e0db7ea
UAI_MEMORY_MANIFEST.json
Code example
{
    "bundle_id": "project-handoff",
    "name": "Project Handoff",
    "description": "A transfer packet for moving execution, ownership, or responsibility to another human, team, agent, or vendor.",
    "intended_use_case": "Use when the next actor must take over a project safely and needs current state, constraints, decisions, checks, and ownership context.",
    "lifecycle": "Prepared before transfer, reviewed at acceptance, and updated when responsibility or support boundaries change.",
    "download_filename": "uai-project-handoff-starter.zip",
    "display_order": 20,
    "trust_boundary_notes": "Can be internal or external, but external handoffs must be sanitized and approved before sharing.",
    "included_files": [
        "README.md",
        "PROJECT_OVERVIEW.md",
        "CURRENT_STATE.md",
        "DECISIONS.md",
        "OPEN_QUESTIONS.md",
        "NEXT_ACTIONS.md",
        "RISKS_AND_CONSTRAINTS.md",
        "CONTACTS_AND_OWNERS.md",
        "AGENT_INSTRUCTIONS.md",
        "CHANGELOG.md",
        "DEPLOYMENT_MEMORY_AND_TEST_REPORT.md",
        "AGENTS.md",
        "readme.human",
        ".uai/context.uai",
        ".uai/constraints.uai",
        ".uai/memory.uai",
        "HANDOFF_BRIEF.md",
        ".uai/stack.uai",
        ".uai/architecture.uai",
        ".uai/progress.uai",
        ".uai/operations.uai",
        ".uai/test-plan.uai",
        ".uai/style.uai",
        ".uai/decisions.uai"
    ],
    "shared_files": [
        "README.md",
        "PROJECT_OVERVIEW.md",
        "CURRENT_STATE.md",
        "DECISIONS.md",
        "OPEN_QUESTIONS.md",
        "NEXT_ACTIONS.md",
        "RISKS_AND_CONSTRAINTS.md",
        "CONTACTS_AND_OWNERS.md",
        "AGENT_INSTRUCTIONS.md",
        "CHANGELOG.md",
        "DEPLOYMENT_MEMORY_AND_TEST_REPORT.md",
        "AGENTS.md",
        "readme.human",
        ".uai/context.uai",
        ".uai/constraints.uai",
        ".uai/memory.uai"
    ],
    "bundle_specific_files": [
        "HANDOFF_BRIEF.md",
        ".uai/stack.uai",
        ".uai/architecture.uai",
        ".uai/progress.uai",
        ".uai/operations.uai",
        ".uai/test-plan.uai",
        ".uai/style.uai",
        ".uai/decisions.uai"
    ],
    "optional_sections": [
        "Add release evidence, validator output, or implementation records only when the handoff also carries public support claims."
    ],
    "overlays": [
        "The handoff overlay emphasizes acceptance criteria, owner transfer, and required first-response checks."
    ],
    "files": [
        {
            "path": "README.md",
            "template_id": "readme",
            "source": "template:readme@1",
            "bytes": 1832,
            "sha256": "a90f8aa1ff9f71a820163e1de220abcafc4212fd32a8f1ed808d80dece66d08f"
        },
        {
            "path": "PROJECT_OVERVIEW.md",
            "template_id": "project-overview",
            "source": "template:project-overview@1",
            "bytes": 492,
            "sha256": "39fa87d6ddcfd5060afdc9f223e3978d25544d43d6f6be690c01245ef03305ac"
        },
        {
            "path": "CURRENT_STATE.md",
            "template_id": "current-state",
            "source": "template:current-state@1",
            "bytes": 325,
            "sha256": "ea4124581f681c39c21f55f4a6172a1af2b48a13cb4a44d6951cfe63fb4c1462"
        },
        {
            "path": "DECISIONS.md",
            "template_id": "decisions",
            "source": "template:decisions@1",
            "bytes": 322,
            "sha256": "7e2ccd4405d66111cf8b79090736cbb1109161d48b6a6810ef6afbc1b0639cba"
        },
        {
            "path": "OPEN_QUESTIONS.md",
            "template_id": "open-questions",
            "source": "template:open-questions@1",
            "bytes": 382,
            "sha256": "629fc8106161f23b5da9027a55078d16e9663ac44202ace5507fca766f260195"
        },
        {
            "path": "NEXT_ACTIONS.md",
            "template_id": "next-actions",
            "source": "template:next-actions@1",
            "bytes": 370,
            "sha256": "af89792bae4eedf986a345799b85ad94ccf6c03d39ae931fca0e5d040c85d132"
        },
        {
            "path": "RISKS_AND_CONSTRAINTS.md",
            "template_id": "risks-and-constraints",
            "source": "template:risks-and-constraints@1",
            "bytes": 812,
            "sha256": "416f636e595a74dafb4c6f5b1d89a1ed7c8ea29ae9663c498986b3b20743288c"
        },
        {
            "path": "CONTACTS_AND_OWNERS.md",
            "template_id": "contacts-and-owners",
            "source": "template:contacts-and-owners@1",
            "bytes": 283,
            "sha256": "472c67e2d4bab2608eca127209ff669b692495d2e96326a63aeb305d5da6f54f"
        },
        {
            "path": "AGENT_INSTRUCTIONS.md",
            "template_id": "agent-instructions",
            "source": "template:agent-instructions@1",
            "bytes": 1008,
            "sha256": "48f018dbcfec530768520b5a6b73f8aa564c92a5a70a2bb3697b487bd3c1a173"
        },
        {
            "path": "CHANGELOG.md",
            "template_id": "changelog",
            "source": "template:changelog@1",
            "bytes": 175,
            "sha256": "8a1d064f7d02294329200521e29d6d5dc0961a9ba5fd44fa21e75b2af5dd2016"
        },
        {
            "path": "DEPLOYMENT_MEMORY_AND_TEST_REPORT.md",
            "template_id": "deployment-report",
            "source": "template:deployment-report@1",
            "bytes": 935,
            "sha256": "dab28315ed510def2557450642658e7cec5de4d8a61ea7fc7c10ed9d165ad732"
        },
        {
            "path": "AGENTS.md",
            "template_id": "agents-md",
            "source": "template:agents-md@1",
            "bytes": 1807,
            "sha256": "086caf2449b98e1296512e85340b94e64a03e9c721ca469a88a93dcab77bcfed"
        },
        {
            "path": "readme.human",
            "template_id": "readme-human",
            "source": "template:readme-human@1",
            "bytes": 1099,
            "sha256": "a4afa43c2eff28b5ee4c70371b6e28e4459c1d7cbd0fc640eaabef1b798f24a3"
        },
        {
            "path": ".uai/context.uai",
            "template_id": "uai-context",
            "source": "template:uai-context@1",
            "bytes": 285,
            "sha256": "aa289be70b0aabadcab8d7a60fc906ddf465f7392580a9be278570cd45788661"
        },
        {
            "path": ".uai/constraints.uai",
            "template_id": "uai-constraints",
            "source": "template:uai-constraints@1",
            "bytes": 520,
            "sha256": "f0e8cd1948b215fae8fc97681c8348391b7d1a47a04444e1b936f716efd36853"
        },
        {
            "path": ".uai/memory.uai",
            "template_id": "uai-memory",
            "source": "template:uai-memory@1",
            "bytes": 1144,
            "sha256": "4297f7da0eb30b314b1e3aaf4cec9abeb38804fbea5eb1c93c63da2b64c38eb8"
        },
        {
            "path": "HANDOFF_BRIEF.md",
            "template_id": "handoff-brief",
            "source": "template:handoff-brief@1",
            "bytes": 450,
            "sha256": "69d8ca2af39f3a5af5e7a2e4dd9905827132ad4ce6380089a2b0d7fd4526733a"
        },
        {
            "path": ".uai/stack.uai",
            "template_id": "uai-stack",
            "source": "template:uai-stack@1",
            "bytes": 204,
            "sha256": "29f47ec11930fc90ba3c7ce77f37ae7b0638c12fd21a11ee897e93a366aea6f5"
        },
        {
            "path": ".uai/architecture.uai",
            "template_id": "uai-architecture",
            "source": "template:uai-architecture@1",
            "bytes": 278,
            "sha256": "403282c4d3df335be44b4237bb258fcfb060f79569ff4ad3c1ba0959eee29d85"
        },
        {
            "path": ".uai/progress.uai",
            "template_id": "uai-progress",
            "source": "template:uai-progress@1",
            "bytes": 188,
            "sha256": "c47bf1fe21e9b1ca62d0c33de793f052252b499fcf78f9228ee1253a97e1fc50"
        },
        {
            "path": ".uai/operations.uai",
            "template_id": "uai-operations",
            "source": "template:uai-operations@1",
            "bytes": 323,
            "sha256": "223ce4881883ee576721885162e6948285be16ad277fb4b95618aca87e2d85af"
        },
        {
            "path": ".uai/test-plan.uai",
            "template_id": "uai-test-plan",
            "source": "template:uai-test-plan@1",
            "bytes": 395,
            "sha256": "087ac4dfc7daf2d0628cb5fc1c5079030f57024cc618f2d5ac37d0590c903322"
        },
        {
            "path": ".uai/style.uai",
            "template_id": "uai-style",
            "source": "template:uai-style@1",
            "bytes": 331,
            "sha256": "b130ec2dbd3e0f3626cc145bc758fd7e4ce4b18c2502960608de5513f20f3209"
        },
        {
            "path": ".uai/decisions.uai",
            "template_id": "uai-decisions",
            "source": "template:uai-decisions@1",
            "bytes": 150,
            "sha256": "7d5dca211562cbd843d0428ea3d5cceadb4c58967363caaefa6a41f34bea0286"
        }
    ]
}
README.md
Code example
# Project Handoff

This starter bundle is a UAI AI Memory configuration. It keeps portable, human-readable context in files that another person, team, or AI agent can inspect before acting.

## Bundle Purpose

A transfer packet for moving execution, ownership, or responsibility to another human, team, agent, or vendor.

## Use This When

Use when the next actor must take over a project safely and needs current state, constraints, decisions, checks, and ownership context.

## Lifecycle

Prepared before transfer, reviewed at acceptance, and updated when responsibility or support boundaries change.

## Trust Boundary

Can be internal or external, but external handoffs must be sanitized and approved before sharing.

## Included Files

- `README.md`
- `PROJECT_OVERVIEW.md`
- `CURRENT_STATE.md`
- `DECISIONS.md`
- `OPEN_QUESTIONS.md`
- `NEXT_ACTIONS.md`
- `RISKS_AND_CONSTRAINTS.md`
- `CONTACTS_AND_OWNERS.md`
- `AGENT_INSTRUCTIONS.md`
- `CHANGELOG.md`
- `DEPLOYMENT_MEMORY_AND_TEST_REPORT.md`
- `AGENTS.md`
- `readme.human`
- `.uai/context.uai`
- `.uai/constraints.uai`
- `.uai/memory.uai`
- `HANDOFF_BRIEF.md`
- `.uai/stack.uai`
- `.uai/architecture.uai`
- `.uai/progress.uai`
- `.uai/operations.uai`
- `.uai/test-plan.uai`
- `.uai/style.uai`
- `.uai/decisions.uai`

## Maintenance Rule

Update the files that changed because project truth changed. Do not turn this bundle into a dump of old chats, private notes, raw logs, or unreviewed generated summaries.

## Review Before Sharing

- Remove secrets, credentials, private keys, tokens, and raw customer data.
- Remove internal-only strategy unless the recipient is approved for it.
- Keep support, security, legal, compliance, certification, and endorsement claims tied to public evidence.
- Make uncertain or unreviewed material explicit.
PROJECT_OVERVIEW.md
Code example
# Project Overview

## Purpose

Describe what the project exists to do, who it serves, and what outcome matters most.

## Current Scope

- In scope:
- Out of scope:
- Current public or operational surface:

## Source Of Truth

- Code:
- Docs:
- Machine artifacts:
- Release notes or changelog:

## Success Criteria

- A new human or AI can understand the project without private chat history.
- Claims are tied to evidence.
- Constraints are visible before work begins.
CURRENT_STATE.md
Code example
# Current State

## What Is True Now

- Live or supported now:
- Experimental now:
- Planned but not supported:

## Recently Changed

- YYYY-MM-DD:

## Active Work

- Current focus:
- Active owner:
- Targeted checks:

## Stale Or Risky Context

List anything that should not be trusted without rechecking.
DECISIONS.md
Code example
# Decisions

Keep decisions append-first when possible. If a decision is reversed, explain what changed instead of silently rewriting history.

## Decision Record Template

### YYYY-MM-DD - Decision Title

- Decision:
- Context:
- Options considered:
- Tradeoffs:
- Consequences:
- Reversal trigger:
- Owner:
OPEN_QUESTIONS.md
Code example
# Open Questions

Use this file for questions that should block, steer, or qualify future work.

| Question | Why It Matters | Owner | Needed By | Status |
|---|---|---|---|---|
|  |  |  |  | open |

## Escalation Rule

If a question affects safety, privacy, legal commitments, public support claims, production data, or destructive operations, stop and ask before acting.
NEXT_ACTIONS.md
Code example
# Next Actions

Keep this file current and actionable. Remove completed work or move meaningful completions to `CHANGELOG.md`.

## Now

- [ ]

## Next

- [ ]

## Later

- [ ]

## Done Means

- The changed files or records are named.
- Targeted checks have run or the remaining risk is explicit.
- Durable memory is updated when project truth changes.
RISKS_AND_CONSTRAINTS.md
Code example
# Risks And Constraints

## Hard Constraints

- Do not expose secrets, credentials, private keys, tokens, or raw customer data.
- Do not use destructive filesystem, database, production, or git operations without explicit approval.
- Do not widen support, certification, security, compliance, compatibility, or endorsement claims without evidence.

## Trust Boundary

Can be internal or external, but external handoffs must be sanitized and approved before sharing.

## Sensitive Material

- Customer or user data:
- Legal or compliance-sensitive material:
- Internal-only strategy:
- Agent permissions:

## Redaction Checklist

- [ ] Secrets removed.
- [ ] Customer data removed or approved.
- [ ] Internal-only strategy removed or approved.
- [ ] Public claims checked against evidence.
CONTACTS_AND_OWNERS.md
Code example
# Contacts And Owners

Do not add private personal data unless the bundle's trust boundary allows it.

| Area | Owner | Backup | Contact Method | Notes |
|---|---|---|---|---|
| Project |  |  |  |  |
| Security or privacy review |  |  |  |  |
| Release approval |  |  |  |  |
AGENT_INSTRUCTIONS.md
Code example
# Agent Instructions

## Load Order

1. Read `AGENTS.md` when present.
2. Read `readme.human` when present.
3. Read this bundle's manifest and files.
4. Confirm constraints and trust boundaries before acting.

## Operating Rules

- Prefer narrow, reversible changes.
- Do not execute unknown scripts from a memory bundle.
- Do not assume an LLM Wiki or old chat overrides accepted project files.
- Ask before touching production, secrets, legal/security copy, customer data, or destructive operations.

## Verification

Name the targeted checks before broad work. Run the smallest meaningful checks tied to changed files, routes, records, or behavior.

For production deployment builds, release packages, or release candidates, write a durable deployment memory and test run report. Use `DEPLOYMENT_MEMORY_AND_TEST_REPORT.md` when it exists, and include hot-memory size before/after, cold evidence path, checks run, checks skipped, blockers, and any reason the hot surface did not shrink.
CHANGELOG.md
Code example
# Changelog

Record meaningful bundle changes so future readers can tell when memory moved.

## YYYY-MM-DD

- Change:
- Why it matters:
- Files updated:
- Checks run:
DEPLOYMENT_MEMORY_AND_TEST_REPORT.md
Code example
# Deployment Memory And Test Report

Use this file only for production deployment builds, release packages, or release candidates. Ordinary dev builds, local tests, package experiments, and smoke checks do not need this report unless a human marks them release-bound.

## Release

- Version:
- Generated UTC:
- Release owner:
- Deployment target:

## Hot Memory Surface

- Measured files:
- Before: bytes / lines / estimated tokens
- After: bytes / lines / estimated tokens
- Delta:
- Redundancy or history removed:
- If no shrink happened, why the retained material is still current truth:

## Cold Memory Or Archive Evidence

- Destination path:
- Source paths preserved:
- Checksums or identity evidence:
- Actor and timestamp:
- Promotion or disposition notes:

## Test Run Report

- Checks run:
- Checks skipped:
- Failures or blockers:
- Package or artifact paths:
- Rollback or follow-up owner:
AGENTS.md
Code example
# My Project AI Memory

This file is the front door for AI work in this repository. Read it first, read `readme.human`, then load the listed context files before planning or editing.

## Handoff Summary

- This project uses UAI AI Memory so future work does not depend on private chat history.
- The active bundle configuration is `project-handoff`: A transfer packet for moving execution, ownership, or responsibility to another human, team, agent, or vendor.
- Confirmed operating truth belongs in these files, canonical docs, code, tests, release notes, or public records.
- LLM Wiki, old chats, generated summaries, and dropped files are background until reviewed and promoted.

## Loaded Context

@uai[.uai/context.uai]
@uai[.uai/constraints.uai]
@uai[.uai/memory.uai]

## Required First Response

Before broad work, the next AI should:

1. Read this file completely.
2. Read root `readme.human`.
3. Load every file listed in Loaded Context.
4. Summarize the project, current state, and immediate task in 3-5 bullets.
5. Confirm constraints, trust boundaries, secrets handling, and destructive-operation limits.
6. Name the files, routes, services, docs, or data it expects to touch.
7. Name the targeted checks it expects to run, or explain why a check cannot run.

If a required file is missing, unreadable, circular, or contradictory, stop and report that before editing.

## Do Not Change Without Explicit Approval

- Do not use destructive filesystem or git operations.
- Do not expose secrets, credentials, customer data, or unapproved private material.
- Do not widen support, certification, compliance, security, or endorsement claims without evidence.
- Do not treat generated output, old chats, dropped files, or wiki notes as current truth until promoted.
readme.human
Code example
# My Project Human Briefing

Updated: YYYY-MM-DD

This file is for humans working with AI on this project. It explains what the AI sees, protects, and needs clarified. It does not override `AGENTS.md`, `.uai/constraints.uai`, system instructions, repository rules, laws, policies, or the human's current request.

## What You Need To Know

- The AI reads `AGENTS.md` first, then this file, then the listed context files.
- This bundle is `Project Handoff`.
- The trust boundary is: Can be internal or external, but external handoffs must be sanitized and approved before sharing.

## Things The AI Will Defend

- Current support boundaries.
- Private data, secrets, credentials, and customer trust.
- Existing user work in the tree.
- Review and targeted checks before public claims widen.

## Things Humans Should Make Explicit

- Whether the task may touch production, public docs, billing, legal language, security posture, or irreversible data.
- Whether the AI should update durable memory after the change.
- Which checks are required before the work is considered done.
.uai/context.uai
Code example
---
uai: "1.0"
type: context
status: draft
---

# Context

This project uses UAI AI Memory so another AI assistant can understand the work from files rather than private chat history.

## Purpose

Describe the project purpose, audience, current truth, and success criteria.
.uai/constraints.uai
Code example
---
uai: "1.0"
type: constraints
status: draft
---

# Constraints

## Hard Rules

- Do not expose secrets, credentials, private keys, tokens, customer data, or unreleased private material.
- Do not use destructive filesystem, database, production, or git operations unless explicitly approved.
- Do not widen support, certification, security, compliance, compatibility, or endorsement claims without evidence.
- Treat wiki notes, generated answers, dropped files, and old chats as background until promoted.
.uai/memory.uai
Code example
---
uai: "1.0"
type: memory
status: draft
---

# AI Memory

AI Memory is durable, reviewable context that lets a future AI continue useful work without relying on private chat history.

## Bundle Configuration

- Bundle: Project Handoff
- Use case: Use when the next actor must take over a project safely and needs current state, constraints, decisions, checks, and ownership context.
- Trust boundary: Can be internal or external, but external handoffs must be sanitized and approved before sharing.

## UAI AI Memory And LLM Wiki

Use UAI AI Memory for compact, portable working packets. Use an LLM Wiki for deep, long-lived internal documentation. Use both when a durable knowledge base needs a reviewed export, handoff packet, onboarding packet, audit packet, or agent-ready task context.

## Promotion Rule

1. Capture raw knowledge in notes, wiki pages, or source documents.
2. Review for accuracy, ownership, privacy, and support boundaries.
3. Promote accepted project truth into AI Memory, canonical docs, code, tests, release notes, or roadmap state.
4. Keep unreviewed material out of governing instructions.
HANDOFF_BRIEF.md
Code example
# Handoff Brief

## Transfer Context

- What is being transferred:
- From:
- To:
- Effective date:

## Acceptance Criteria

- The recipient can explain current state and constraints.
- Open questions are acknowledged.
- Required checks and next actions are clear.
- Trust-boundary and redaction review is complete.

## Handoff Risks

- Missing context:
- Unsupported claims:
- Sensitive material:
- Production or customer impact:
.uai/stack.uai
Code example
---
uai: "1.0"
type: stack
status: draft
---

# Stack

## Runtime

- Language:
- Framework:
- Package manager:
- Database or storage:

## Commands

- Install:
- Run:
- Test:
- Release:
.uai/architecture.uai
Code example
---
uai: "1.0"
type: architecture
status: draft
---

# Architecture

## System Shape

Describe main surfaces, services, packages, routes, jobs, data stores, and ownership boundaries.

## Drift Risks

- Duplicated copy:
- Generated output:
- Manual release steps:
.uai/progress.uai
Code example
---
uai: "1.0"
type: progress
status: draft
---

# Progress

## Recently Completed

- YYYY-MM-DD:

## Current Focus

-

## Next Work

-

## Blockers

- None recorded.
.uai/operations.uai
Code example
---
uai: "1.0"
type: operations
status: draft
---

# Operations

## Normal Workflow

1. Load AI Memory files.
2. Inspect relevant code or docs.
3. Make narrow changes.
4. Run targeted checks.
5. Update memory when project truth changes.

## Release Workflow

- Package command:
- Smoke test:
- Rollback:
.uai/test-plan.uai
Code example
---
uai: "1.0"
type: test-plan
status: draft
---

# Test Plan

## Default Rule

Run targeted checks for the files, routes, records, or behavior changed. Reserve full release sweeps for package builds, release candidates, broad launch-surface changes, migrations, or explicit human requests.

## If A Check Cannot Run

State the command, why it could not run, and what risk remains.
.uai/style.uai
Code example
---
uai: "1.0"
type: style
status: draft
---

# Style

## Writing

- Be concrete and current.
- Separate current support from planned work.
- Prefer explicit links to source truth.

## Code

- Follow existing project patterns.
- Keep edits scoped.
- Avoid abstractions unless they reduce real drift or complexity.
.uai/decisions.uai
Code example
---
uai: "1.0"
type: decisions
status: draft
---

# Decisions

Record accepted decisions, why they were made, and what would cause a reversal.

Plain-Language Summary

OpenAI is building better ways for AI agents to do work. That does not kill Project Handoff. It changes what Project Handoff should claim.

Project Handoff should not try to be an agent runner. It should be the thing that tells any agent: here is the project, here is what matters, here is what changed, here are the rules, here are the decisions already made, here is what you must verify, and here is what you are not allowed to do without a human.

OpenAI runs the work. UAIX Project Handoff preserves the project memory.

Current Support Boundary

  • This page publishes the draft AGENTS.md, readme.human, and .uai handoff pattern for public review and early use.
  • The visible starter ZIP is current and is generated from canonical templates and manifests.
  • Hosted .uai upload/import validation, automatic repository writes, automatic LLM Wiki sync, SDK, CLI, certification, and endorsement support remain planned until public tooling, fixtures, validation behavior, and release evidence exist.
  • Do not describe a project as certified or endorsed by UAIX just because it uses AGENTS.md, readme.human, or .uai files.
  • When a handoff becomes public release evidence, attach the relevant Validator result, Conformance Pack evidence, Implementation record, and Changelog entry.