UAIX Project Handoff and Canonical AI Memory Assessment

Full report

On this page

Executive summary

UAIX currently publishes two related but distinct layers. The first is UAI-1, a formal, machine-readable exchange standard with published schemas, registry records, examples, transport bindings, trust channels, validator guidance, conformance levels, discovery routes, and an advertised OpenAPI document. The second is AI Memory / Project Handoff, which is a repo-local durable memory and transfer system built from AGENTS.md, readme.human, .uai records, generated starter bundles, and wizard-produced overlays and briefs. In other words, UAI-1 is the interoperable message contract; Project Handoff is the operational memory packet that agent runtimes are meant to load before work and update after work.

The strongest current UAIX artifact for “canonical AI Memory” is not one monolithic specification. Instead, it is a distributed operating surface made up of the AI Memory framing, the Project Handoff specification, the AI Memory Package Wizard, Agent File Handoff, the Context Budget guide, and supporting governance pages. The practical conclusion is that Project Handoff is the clearest current canonical operating form for durable repository memory, while the AI Memory Package Wizard is the clearest current canonical generator/planning surface for those bundles.

UAIX’s biggest strengths are its explicit trust boundary language, its separation of runtime execution from durable project memory, its use of reviewable local files instead of private chat memory, its published conformance and evidence model, and its insistence that support claims must remain tied to named public records and release evidence.

Its biggest gaps are equally clear. I did not find a single formal public schema for the Project Handoff bundle itself; I found template- and manifest-driven bundles, plus draft/proposal material. I also found an internal inconsistency in local memory record syntax: some .uai examples use front matter with uai: "1.0", while Agent File Handoff templates use uaix: "1.0", and the separate AGENTS.md linking report proposes .uai as JSON/YAML-style informational files. That means the message layer is more formally specified than the memory layer today.

Interoperability is strongest today with Git-centered, repo-local workflows and with runtime-neutral agent orchestration. It is conceptually aligned with OpenAI, MCP, and A2A, and practical across Codex, Claude Code, Cursor, Copilot, and Gemini Code Assist, but UAIX explicitly warns readers not to treat these patterns as official adapters, SDKs, CLIs, certifications, or vendor endorsements. I found no current official Jira, Notion, or Slack adapters in the published implementation tracks or roadmap.

For adoption, the best current strategy is pragmatic: use Project Handoff as a portable repo-local memory discipline, use UAI-1 only when you need portable message exchange and validator-backed evidence, and treat broader package automation, managed package records, adapters, sync, and official tool integrations as planned or research-track rather than current support.

What UAIX publishes today

UAIX’s own discovery surface reports a current UAI-1 release with version 1.0, release date 2026-04-22, and a public machine surface that includes 6 schemas, 6 registry entries, 6 examples, 2 transport bindings, 5 trust channels, 4 conformance levels, 11 error codes, plus discovery, validation, adoption-kit, mock-exchange, OpenAPI, conformance-pack, roadmap, and status routes. It also publishes a public page map covering AI Memory, Project Handoff, AGENTS.md specification, Agent File Handoff, Schemas, Registry, Examples, Implementations, Tools, Governance, Roadmap, and Reports.

Analytically, the site breaks into four functional zones: a memory/handoff zone, a formal protocol zone, a tooling/evidence zone, and a governance/release zone. That separation is a genuine design strength because it keeps “portable context” separate from “portable message exchange,” and both separate from “public support claims.”

The following site map condenses the pages and machine surfaces that matter most for AI Memory and Project Handoff. It is synthesized from the discovery JSON and the crawled canonical pages.

graph TD
    A[UAIX Home] --> B[AI Memory]
    A --> C[Project Handoff]
    A --> D[Agent File Handoff]
    A --> E[AGENTS.md Spec]
    A --> F[Context Budget Guide]
    A --> G[OpenAI Guide]
    A --> H[Coding Agents Guide]

    A --> I[UAI-1]
    I --> J[Schemas]
    I --> K[Registry]
    I --> L[Examples]
    I --> M[Standards Fit]

    A --> N[API Reference]
    N --> O[/catalog]
    N --> P[/discovery]
    N --> Q[/schemas]
    N --> R[/registry]
    N --> S[/field-registry]
    N --> T[/transport-bindings]
    N --> U[/trust-channels]
    N --> V[/conformance-levels]
    N --> W[/error-registry]
    N --> X[/validate]
    N --> Y[/mock-exchange]
    N --> Z[/openapi.json]
    N --> AA[/conformance-pack]

    A --> AB[AI Memory Package Wizard]
    A --> AC[Implementations]
    AC --> AD[WordPress Track]
    AC --> AE[.NET Bridge Track]

    A --> AF[Governance]
    AF --> AG[Policy and Security]
    AF --> AH[Privacy and Data]
    AF --> AI[Changelog]
    AF --> AJ[Roadmap]

A high-confidence conclusion from the crawl is that canonical AI Memory on UAIX is operationally real but formally distributed. The site publishes canonical templates, generated manifests, bundle IDs, starter ZIPs, and a bundle registry-driven wizard, but not a single public, normative “AI Memory core schema” equivalent to the formal schemas that UAI-1 publishes for message exchange.

Handoff architecture and workflow

UAIX repeatedly states that agent runtimes execute, while Project Handoff preserves durable project memory. The memory system lives “one layer earlier and one layer later” than runtime execution: it tells a runtime what durable memory to load before work starts, and where accepted truth should be written back when work finishes. That architectural stance is consistent across the Project Handoff spec and the OpenAI-oriented guide.

The minimum Project Handoff bundle is straightforward: a project root with AGENTS.md, readme.human, and .uai/context.uai, .uai/stack.uai, .uai/constraints.uai, .uai/progress.uai, and .uai/test-plan.uai. UAIX presents AGENTS.md as the “durable front door,” readme.human as the human briefing, and the .uai files as typed records for project context, stack, constraints, progress, and testing.

The extended Project Handoff starter is much richer. UAIX publishes a 25-file starter ZIP generated from “visible canonical files,” including a UAI_MEMORY_MANIFEST.json, root narrative files such as 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, and local .uai records for context, constraints, memory, stack, architecture, progress, operations, test plan, style, and decisions, plus HANDOFF_BRIEF.md.

The startup reading order is explicit. A receiving AI is told to read AGENTS.md, then readme.human, then load the files in the “Loaded Context” list via @uai[], report contradictions or missing context, read summary/current-state/next-step sections, summarize understanding in 3–5 bullets, and confirm hard constraints. That is a stronger handoff discipline than a loose README-only approach, because it forces early constraint acknowledgment and verification planning.

The following flow diagram summarizes the operating loop UAIX describes. It combines the Project Handoff page, the OpenAI guide, the context-budget guidance, and the Agent File Handoff extension.

flowchart LR
    H[Human or prior agent] --> W[AI Memory Package Wizard or hand-edited bundle]
    W --> PH[Project Handoff bundle in repo]
    PH --> A1[AGENTS.md]
    PH --> A2[readme.human]
    PH --> A3[Loaded .uai records]

    A1 --> R[Agent runtime]
    A2 --> R
    A3 --> R

    F[Optional Agent File Handoff buckets] --> R
    R --> C[Checks, traces, PRs, targeted edits]
    C --> U[Write back accepted truth]
    U --> P1[progress.uai]
    U --> P2[decisions.uai]
    U --> P3[deployment and test report]
    U --> P4[handoff brief / next actions]

    U --> CM[Cold memory or LLM Wiki pointer only after review]

A particularly important extension is Agent File Handoff, which UAIX positions as a small auditable inbox for “loose files supplied by humans, other AI systems, exports, and adjacent tools.” Its rule is simple: a dropped file is not part of handoff until it is visible, reviewed, and dispositioned. The directory contract uses agent-file-handoff/Content/, agent-file-handoff/Improvement/, agent-file-handoff/Archive/, plus .uai/file-handoff.uai, .uai/intake-index.uai, and loader instructions in AGENTS.md.

This structure becomes more rigorous when paired with UAIX’s Context Budget guidance. That guide distinguishes hot Project Handoff from cold memory, saying hot context should carry current truth and constraints, while long research, old chats, raw audits, and superseded notes should move to cold memory with source path, final path, checksum, actor, timestamp, summary, and disposition. In practical terms, UAIX is trying to prevent “AI Memory” from turning into an unbounded archive.

The table below condenses the published bundle archetypes and templates. It is synthesized from Project Handoff, Agent File Handoff, and the AI Memory Package Wizard.

Data models, APIs, and metadata

The formal machine data model in UAIX is UAI-1. The schemas page says the current machine-validated envelope covers identity (uai_version, profile, message_id, source, target), workflow continuity (conversation, delivery), trust posture (trust), and auditability (provenance, integrity, extensions). It then publishes six profile families with required body fields.

The key profile families are concise and well scoped. Requests declare intent, subject, requested profile, parameters, constraints, and response profile. Responses declare status, subject, request linkage, result, and notices. Capability statements publish operations, profiles, security schemes, endpoints, transport bindings, conformance levels, and implementation tracks. Separate profiles cover typed errors, conformance results, and async task status.

The table below summarizes the published UAI-1 record families from the schemas and registry pages.

UAIX also publishes a field registry that governs the root order for both keyed and keyless transport. The root order is uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, extensions; it also publishes nested field order for source, target, conversation, delivery, trust, provenance, and profile-specific body orders. This is one of the site’s most mature design choices, because it creates a reversible path between human-readable JSON and compact transport.

The transport layer is likewise explicit. UAIX publishes two bindings: https-json-envelope.v1 with media type application/vnd.uaix.uai+json, and https-json-keyless.v1 with media type application/vnd.uaix.uai-keyless+json. It requires keyed JSON to remain intact for review and conformance evidence, and says keyless transport should only be used where both sides agree on the field-registry release. It also aligns traceparent with W3C Trace Context and typed errors with problem-details style semantics.

The REST surface is broad for a standards publication site. UAIX publishes routes for catalog, discovery, schemas, registry, field registry, transport bindings, trust channels, conformance levels, error registry, examples, validation, adoption kit, mock exchange, OpenAPI, conformance pack, roadmap, and status. The API Reference explicitly tells implementers to resolve these routes instead of reverse engineering page HTML.

By contrast, the repo-local AI Memory data model is less formalized. I found three overlapping patterns:

1. Project Handoff .uai records are Markdown-like documents with YAML-style front matter such as uai: "1.0", type, and status, followed by human-readable sections.
2. Agent File Handoff templates use a similar front-matter pattern, but with uaix: "1.0" plus type, title, and status.
3. The separate AGENTS.md linking specification report proposes .uai as JSON- or YAML-style informational files with metadata like version, intents, capabilities, context, provenance, accessControl, links, signature, and checksum. That page is explicitly labeled a proposal/specification report sourced from a document authored by ChatGPT, which makes it useful but less normative than the canonical Project Handoff and UAI-1 pages.

That discrepancy matters. It means the site has a mature message schema and validation surface for UAI-1, but only a template-driven and partially proposal-driven local memory record surface for Project Handoff. From an adoption perspective, that is the single clearest schema governance gap I found.

The following entity relationship diagram captures the published and inferred local memory model. It is an analytical synthesis from the Project Handoff, Agent File Handoff, and AI Memory Wizard pages.

classDiagram
    class Package {
      +bundle_id
      +name
      +intended_use_case
      +manifest_fingerprint
    }

    class AGENTS {
      +path = AGENTS.md
      +loaded_context[]
      +required_first_response
    }

    class ReadmeHuman {
      +path = readme.human
      +audience_brief
    }

    class UaiRecord {
      +path
      +type
      +status
      +title
    }

    class Manifest {
      +files[]
      +shared_files[]
    }

    class WizardOverlay {
      +package_metadata
      +review_gates
      +source_authority_policy
      +risk_and_rollback
    }

    class IntakeIndex {
      +records[]
      +status
    }

    Package --> Manifest
    Package --> AGENTS
    Package --> ReadmeHuman
    Package --> UaiRecord
    Package --> WizardOverlay
    IntakeIndex --> UaiRecord
    AGENTS --> UaiRecord : loads

Security, privacy, versioning, and governance

UAIX’s security and privacy story is stronger in boundary declaration than in institutional depth. On the positive side, the site is unusually explicit about what current public support does not mean. The policy hub says UAIX is a standards and publication surface, not a managed trust service, a security operations center, or a universal runtime assurance program. The roadmap says UAIX is not currently an agent runtime, scheduler, hosted memory platform, certification program, SDK, or CLI.

At the local memory layer, Project Handoff and Agent File Handoff are careful about trust boundaries. Project Handoff says external handoffs must be sanitized and approved before sharing, the handoff templates warn against exposing secrets, private keys, tokens, or raw customer data, and HANDOFF_BRIEF.md includes acceptance criteria around trust-boundary and redaction review. Agent File Handoff separately emphasizes that visibility is not trust, indexing is not approval, route hints are not authorization, checksums identify bytes rather than truth, and executable files must never be run automatically.

At the public machine surface, UAIX documents a real security-header baseline: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a restrictive Permissions-Policy, X-Frame-Options: SAMEORIGIN, Content-Security-Policy: frame-ancestors 'self', and Strict-Transport-Security: max-age=31536000; includeSubDomains when served over HTTPS. The site also documents residual host/edge gaps, including static-file parity, HTTP-to-HTTPS redirects, and version-header suppression. That is a credible and appropriately scoped launch-stage posture.

UAIX also publishes a formal trust-channel vocabulary for UAI-1: public-web, private-api, mtls, signed-envelope, and credentialed, with minimum controls and fit guidance. This is a strength because it gives the message layer a published trust taxonomy instead of leaving identity posture to informal prose.

Versioning and public-truth discipline are another clear strength. UAIX uses canonical page paths, record codes, a dated changelog, implementation tracks, conformance ladders, and a roadmap that repeatedly says support-changing work should not live only in private chat, screenshots, reports, or archives. The changelog documents rapid iteration across April and May 2026, including release entries for Project Handoff, Agent File Handoff, AI Memory starter bundles, the AI Memory Package Wizard, validator normalization, security headers, governance pages, and standards-fit materials.

The main governance weakness is that the AI Memory package lifecycle is still partially future-state. The roadmap says managed package records still need package-instance identifiers, review states, provenance records, privacy gates, stale-review checks, serializer parity, and reviewed AIWikis archive sync before managed AI Memory packages become current support. That means today’s wizard outputs are useful operationally, but not yet the fully governed package system the site hints toward.

A smaller but notable QA concern is that the English Implementations page includes a conformance-level section rendered in Chinese within the English route. That does not undermine the conceptual model, but it is a visible content-quality issue for a standards publication site and suggests stronger localization release checks are warranted.

Interoperability and standards comparison

UAIX’s own standards-fit page is disciplined. It says UAI-1 is the portable public exchange record beside MCP, A2A, and OpenAPI rather than a replacement for them; MCP owns host-client-server tool and resource sessions, A2A owns peer-agent discovery and task coordination, and OpenAPI describes HTTP operations, while UAI-1 carries the portable record, trust context, provenance, validation, and release evidence.

That separation is analytically sound and largely aligned with industry practice. OpenAPI itself defines a standard language-agnostic interface description for HTTP APIs, while UAIX uses UAI-1 to describe message records and OpenAPI to describe its own REST surface. This is a good separation of concerns and one of UAIX’s cleaner design choices.

Relative to OpenAI’s official conversation-state model, UAIX is not competing on the same plane. OpenAI’s APIs let developers preserve state by passing prior messages, using previous_response_id, or persisting durable conversation objects; ChatGPT Memory separately stores user-level personalization and can reference saved memories and chat history. UAIX’s repo-local handoff model complements rather than replaces those features: it is external, reviewable, vendor-neutral, and intended to survive model, runtime, vendor, or company changes.

Relative to ISO/IEC 42001, UAIX aligns with several governance instincts: explicit review boundaries, change trails, public posture pages, and evidence-backed support claims. But ISO/IEC 42001 is an organization-level AI management system standard for establishing, implementing, maintaining, and continually improving an AIMS. UAIX does not publish that kind of organizational management system; it publishes a standards site, a message protocol, and a repo-memory operating model. So the fit is partial: strong on traceable public records, weaker on enterprise-wide control systems.

Relative to ISO/IEC/IEEE 29148, UAIX does several things well: it defines required information items, insists on constraints and verification plans, records decisions and reversal conditions, and emphasizes change traceability. 29148, however, is a formal requirements-engineering standard that specifies requirements processes and information items across the lifecycle. UAIX’s handoff files are practical and useful, but they do not yet amount to a full requirements-engineering information model with normalized stakeholders, requirement attributes, baselines, verification cases, and change-control semantics.

Relative to W3C JSON-LD and RDF, UAIX currently stops short of semantic-web interoperability. JSON-LD is designed to add linked-data semantics and interoperable identifiers to JSON, and RDF provides a graph model that can be serialized in JSON-LD and related syntaxes. UAIX publishes JSON, keyed-to-keyless field order, and linkable record URLs, but I did not find public @context documents, RDF vocabularies, or JSON-LD examples for Project Handoff or UAI-1. That means UAIX is currently JSON-native, not linked-data-native.

The practical interoperability picture with common tools is therefore uneven. Based on the current crawl:

The most important interoperability conclusion is this: UAIX is already a credible evidence-and-handoff layer, but it is not yet a broadly tooled integration platform. That distinction is explicit in its own roadmap and implementation pages, and adopters should respect it.

Recommendations and implementation starter kit

The most important gaps I found are structural rather than cosmetic. The following table prioritizes them by adoption impact. Each recommendation is analytical, not a restatement of a published UAIX requirement. It is based on the crawled materials.

For organizations adopting UAIX today, the implementation pattern I would recommend is conservative:

• Use Project Handoff as the repo-local source of truth for current state, constraints, decisions, next actions, and targeted checks.
• Keep AGENTS.md tiny and canonical; keep tool-specific files as thin pointers back to it.
• Use Agent File Handoff only for visible intake and disposition of loose files; never treat it as an auto-execution or auto-publication queue.
• Use the Context Budget split aggressively so that handoff files carry only current truth and cold memory carries provenance-rich archives.
• Use UAI-1 only when you need validator-backed exchange records across system or organizational boundaries.
• Do not claim SDK/CLI/connector/certification support that UAIX does not currently publish.

An adoption checklist that is faithful to the current public surface would look like this:

• Create a root AGENTS.md, root readme.human, and a .uai/ directory with at least context.uai, constraints.uai, stack.uai, progress.uai, and test-plan.uai.
• Add a required startup rule: read AGENTS.md, then readme.human, then every file in “Loaded Context,” then summarize current truth, constraints, intended touchpoints, and targeted checks.
• Add HANDOFF_BRIEF.md for any significant responsibility transfer.
• If loose files are common, add agent-file-handoff/Content/, Improvement/, Archive/, .uai/file-handoff.uai, and .uai/intake-index.uai.
• Establish a cold-memory location and enforce the promotion rule: archived facts govern work only after review and promotion back into current files.
• For any external or public-facing exchange, attach UAI-1 validator evidence, relevant schema/registry/example links, and release trail references.

The following sample JSON mapping is an illustrative adoption mapping, not an official UAIX schema. It translates the published Project Handoff artifacts into a machine-friendly bundle object. It is derived from the published starter manifest, minimum bundle, and wizard overlay concepts.

{
  "bundle_id": "project-handoff",
  "spec_family": "uaix-project-memory",
  "version": "draft-operational",
  "front_door": {
    "agents_file": "AGENTS.md",
    "human_brief": "readme.human"
  },
  "loaded_context": [
    ".uai/context.uai",
    ".uai/constraints.uai",
    ".uai/memory.uai"
  ],
  "records": [
    { "path": ".uai/context.uai", "record_type": "context", "status": "draft" },
    { "path": ".uai/stack.uai", "record_type": "stack", "status": "draft" },
    { "path": ".uai/constraints.uai", "record_type": "constraints", "status": "draft" },
    { "path": ".uai/progress.uai", "record_type": "progress", "status": "draft" },
    { "path": ".uai/test-plan.uai", "record_type": "test-plan", "status": "draft" },
    { "path": ".uai/decisions.uai", "record_type": "decisions", "status": "draft" }
  ],
  "handoff_brief": "HANDOFF_BRIEF.md",
  "evidence_report": "DEPLOYMENT_MEMORY_AND_TEST_REPORT.md",
  "trust_boundary": {
    "share_scope": "internal_or_external",
    "external_requires_redaction": true
  }
}

The next example is an illustrative JSON-LD projection. It shows one practical way UAIX could improve linked-data interoperability while preserving its existing file model. This is my mapping proposal, not a current UAIX-published artifact. It is motivated by UAIX’s current JSON orientation and by W3C JSON-LD/RDF capabilities.

{
  "@context": {
    "@vocab": "https://uaix.org/ns/memory#",
    "schema": "https://schema.org/",
    "prov": "http://www.w3.org/ns/prov#",
    "bundle_id": "schema:identifier",
    "name": "schema:name",
    "description": "schema:description",
    "frontDoor": "schema:hasPart",
    "record": "schema:hasPart",
    "recordType": "schema:additionalType",
    "status": "schema:creativeWorkStatus",
    "sourceAuthority": "prov:wasDerivedFrom"
  },
  "@id": "https://example.org/project-handoff/bundles/project-handoff",
  "@type": "ProjectHandoffBundle",
  "bundle_id": "project-handoff",
  "name": "Project Handoff",
  "description": "Portable repository memory bundle for transfer of work and responsibility.",
  "frontDoor": [
    {
      "@type": "RepoInstructionFile",
      "name": "AGENTS.md"
    },
    {
      "@type": "HumanBrief",
      "name": "readme.human"
    }
  ],
  "record": [
    {
      "@type": "ContextRecord",
      "name": ".uai/context.uai",
      "recordType": "context",
      "status": "draft"
    },
    {
      "@type": "ConstraintRecord",
      "name": ".uai/constraints.uai",
      "recordType": "constraints",
      "status": "draft"
    }
  ]
}

Crawled pages and limitations

The table below lists the unique pages and machine endpoints I crawled during this research session. Unless otherwise noted, they were accessed on 2026-05-06 in the user’s America/Chicago context.

A few limitations are important. First, the OpenAPI JSON document and the two .well-known discovery files were referenced by the site but not independently parsed in this session because direct retrieval produced tool-level errors; I therefore treat them as published but not fully verified by direct crawl. Second, some machine JSON endpoints were reachable but rendered only partially in the tool, so I relied on the HTML API Reference page where the live route contract is spelled out. Third, I did not find a single public, normative schema for the Project Handoff bundle or .uai local memory record family, only templates, examples, manifest-driven starters, and proposal/report material. That is a key substantive limitation of the current public record, not just a limitation of this crawl.