# Deep Research Assignment: Strengthening UAIX for Durable Agent-Swarm Management

## Role

Act as a senior distributed-systems architect, standards editor, security engineer, and multi-agent runtime researcher.

Your task is to determine how UAIX should be extended to support reliable agent swarms while preserving UAIX’s existing strengths as a portable evidence, memory, communication, and project-handoff standard.

This is a constructive engineering review. The existing UAIX system is already effective for its present use cases. Do not evaluate UAIX’s popularity, funding, founder, organizational structure, market adoption, reputation, ideology, or external endorsement. Those subjects are outside the assignment.

The only question is:

> What precise normative additions or revisions are needed so UAIX can support coordinated, concurrent, durable, fail-closed agent swarms without weakening its existing portable-record model?

## Primary Objective

Produce a rigorous standards-design report suitable for conversion into:

* normative UAIX specification pages;
* UAI-1 schemas;
* profile definitions;
* field-registry entries;
* validator rules;
* stable error codes;
* valid and invalid conformance fixtures;
* runtime API contracts;
* durable-service transaction rules;
* reference implementations;
* migration and pre-release replacement documentation.

The resulting design must allow an independent UAIX implementation and an independent durable swarm runtime to interoperate without inventing their own fallback behavior.

## Foundational Boundary

Preserve the following architectural boundary throughout the report.

### UAIX owns portable evidence

UAIX records portable, inspectable evidence concerning:

* agent identity assertions;
* logical messages;
* task directives;
* task-state reports;
* acknowledgements;
* blockers;
* delegation;
* handoffs;
* memory proposals;
* corrections;
* final reports;
* lineage references;
* conflict evidence;
* durable-service readback evidence.

### The runtime owns execution and authority

A runtime or hosted durable service owns:

* authentication;
* credential issuance;
* authorization;
* entitlement evaluation;
* agent registration;
* private discovery;
* queues;
* delivery records;
* leases;
* heartbeats;
* scheduling;
* retries;
* cursors;
* transactions;
* persistence;
* concurrency enforcement;
* rate limits;
* secret storage;
* project membership;
* private tenant information;
* authoritative acknowledgement state.

A UAI packet may describe or reference runtime activity. It must not falsely imply that portable evidence itself performed or committed the runtime operation.

## Required Sources

Read the current public material on UAIX.org before making recommendations, including where available:

* UAI-1 specification;
* JSON schemas;
* registry;
* field registry;
* examples;
* validator;
* conformance pack;
* roadmap;
* changelog;
* Agent Communication Operating Model;
* AI Memory guidance;
* Project Handoff guidance;
* agent identity profile;
* acknowledgement profile;
* blocker profile;
* task-status profile;
* handoff profile;
* memory-proposal profile;
* correction profile;
* final-report profile;
* supplied multi-agent or swarm-management reports.

Use authoritative or primary documentation for comparison, including:

* Google Agent2Agent Protocol;
* Model Context Protocol;
* CloudEvents;
* W3C Trace Context;
* JSON Canonicalization Scheme;
* current OAuth security guidance;
* at least one mature durable-messaging model such as NATS JetStream, Apache Kafka, AMQP, Azure Service Bus, Amazon SQS, or Google Pub/Sub.

Use external standards only to identify useful engineering patterns. Do not turn UAIX into a copy of another protocol.

## Required Classification

Every important statement must be classified as one of:

1. **Current UAIX behavior**
   Behavior presently specified or demonstrably implemented by UAIX.

2. **Proposed UAIX behavior**
   New normative behavior recommended by this report.

3. **Runtime-owned behavior**
   Behavior that a durable execution service must enforce.

4. **Future research**
   A question intentionally left unresolved and not required for conformance.

Never describe a proposal as existing UAIX functionality.

## Design Principles

The proposed swarm contract must follow these principles:

* Preserve UAIX as a portable evidence and handoff layer.
* Fail closed when required semantics are unknown or unsupported.
* Never silently drop recipients.
* Never use “first target wins.”
* Never reinterpret multicast as single-target delivery.
* Never treat an unknown delivery mode as ordinary delivery.
* Never broaden authority because a field is missing or unfamiliar.
* Never infer tenant, project, actor, or credential authority from client input.
* Never treat a signature as proof of authorization.
* Never claim durable acknowledgement without runtime readback.
* Never use last-write-wins for shared swarm memory.
* Never allow an LLM to silently merge conflicting state.
* Never treat an idempotency key as a complete transaction model.
* Never acknowledge work that was not handled.
* Never claim exactly-once processing unless every involved layer can prove it.
* Never allow an unsupported semantic extension to affect execution.
* Never use permissive compatibility behavior that changes authority, privacy, delivery, or acknowledgement semantics.

Unsupported or ambiguous behavior must produce a typed rejection, a typed safe no-op, or an authorized runtime-created projection.

## Core Research Problem

UAIX performs well for portable memory, evidence, communication, and handoff, but its current model needs a complete contract for agent-swarm management.

The report must define how a swarm can safely:

* register and identify agents;
* assign roles;
* discover permitted peers;
* create a swarm run;
* create and divide work;
* route work to one or more agents;
* delegate subtasks;
* claim work;
* renew work leases;
* report progress;
* detect stalled agents;
* retry abandoned work;
* cancel work;
* coordinate shared state;
* detect conflicts;
* preserve competing updates;
* acknowledge handled notifications;
* aggregate results;
* complete or fail a swarm run;
* survive coordinator or worker failure;
* produce portable evidence of the complete activity.

## 1. Swarm Identity Model

Define a storage-neutral identity model that clearly separates:

* human-visible agent label;
* canonical logical agent ID;
* normalized registered agent name;
* agent role;
* credential principal;
* credential issuer;
* tenant binding;
* company binding;
* workspace binding;
* project binding;
* swarm ID;
* swarm-run ID;
* runtime instance ID;
* operating-system process identity;
* process lease ID;
* agent identity lease ID;
* `.uai` memory identity;
* true branch identity;
* branch parent;
* branch root;
* logical coordinator identity;
* active coordinator instance;
* observer identity;
* service identity.

Roles must include at least:

* orchestrator;
* coordinator;
* scheduler;
* worker;
* specialist;
* reviewer;
* observer;
* durable service.

For each identifier, specify:

* purpose;
* syntax;
* normalization;
* uniqueness scope;
* visibility;
* whether it is portable;
* whether it may be opaque;
* who assigns it;
* whether clients may choose it;
* whether it can change;
* collision behavior;
* revocation behavior;
* continuity across credential rotation;
* whether it may be inferred;
* whether it may appear in signed UAI evidence.

The model must allow distinct agents and true identity branches to run concurrently.

It must also prevent the same normalized registered identity or the same `.uai` identity from being active in multiple processes whenever project policy prohibits concurrent activation.

Renaming must not create a new logical identity unless explicitly declared as an identity branch or replacement.

Credential rotation must not break logical identity continuity.

## 2. Swarm Topology and Membership

Define a normative swarm topology model covering:

* swarm definition;
* swarm run;
* coordinator assignment;
* worker registration;
* static membership;
* dynamic membership;
* join;
* leave;
* removal;
* suspension;
* revocation;
* role change;
* capability change;
* coordinator replacement;
* worker replacement;
* observer access;
* maximum swarm size;
* nested or child swarms;
* membership version;
* membership snapshot;
* membership-event evidence.

Determine whether a swarm run requires:

* exactly one coordinator;
* one active coordinator lease;
* multiple coordinators with distinct scopes;
* a coordinator epoch;
* a scheduler independent of the coordinator;
* a quorum model.

Do not introduce distributed consensus unless it is necessary. When consensus is not required, define the simpler authoritative-runtime transaction that resolves the problem.

Explain how a new coordinator distinguishes current state from stale coordinator output.

## 3. Task Graph and Work Coordination

Define a normative task model covering:

* task ID;
* task attempt ID;
* parent task;
* root task;
* dependency list;
* task graph revision;
* assigned role;
* assigned agent;
* candidate agent set;
* priority;
* deadline;
* not-before time;
* estimated cost;
* token or resource budget;
* maximum attempts;
* retry policy;
* response requirement;
* cancellation policy;
* completion policy;
* result aggregation policy.

Define task states such as:

`created -> ready -> offered -> claimed -> executing -> blocked -> completed`

and terminal or exceptional states such as:

* rejected;
* failed;
* cancelled;
* expired;
* abandoned;
* superseded;
* quarantined;
* dead-lettered.

Specify permitted transitions and the actor authorized to perform each transition.

Define:

* dependency release;
* subtask creation;
* delegation;
* redelegation;
* work stealing;
* lease expiration;
* stalled-worker detection;
* retry ownership;
* retry delay;
* maximum attempt count;
* duplicate completion;
* late completion;
* completion after cancellation;
* partial task result;
* task compensation;
* swarm-run completion.

A portable task-status packet is evidence of an asserted state. The durable runtime remains authoritative for the committed task state.

## 4. Addressing and Fan-Out

Compare these explicit designs:

1. One envelope containing a closed ordered recipient set.
2. One parent event plus runtime-created per-recipient delivery records.
3. Deterministic one-to-one envelope expansion using a shared fan-out ID.

For each design, define:

* canonical recipient ordering;
* duplicate-recipient rejection;
* recipient normalization;
* authorization per recipient;
* privacy boundaries;
* recipient-count limit;
* all-or-nothing submission behavior;
* partial failure behavior;
* retry behavior;
* expiry;
* cancellation;
* delivery identity;
* evidence identity;
* acknowledgement identity;
* acknowledgement aggregation;
* lost-response recovery.

Recommend one normative UAIX design.

The preferred result should preserve a logical fan-out relationship while providing one independently authorized, independently delivered, independently acknowledged record per recipient.

A single-target implementation must never accept a multicast request as though it completed the multicast operation.

Unsupported multicast must result in either:

* a typed safe rejection with no recipient delivery; or
* deterministic one-to-one expansion performed by an authorized runtime before delivery.

## 5. Discovery and Capability Negotiation

Define how swarm participants discover agents, services, and coordinators without exposing private tenants or treating labels as authority.

Cover:

* authoritative discovery publisher;
* authenticated discovery request;
* project-scoped visibility;
* role-scoped visibility;
* capability-document identity;
* signature or authentication;
* exact schema versions;
* exact profile versions;
* exact delivery modes;
* task types;
* input schema bounds;
* output schema bounds;
* maximum payload size;
* maximum concurrency;
* supported acknowledgement modes;
* supported extension namespaces;
* authentication requirements;
* entitlement requirements;
* expiration;
* cache lifetime;
* freshness;
* revocation;
* endpoint origin rules;
* redirect rules;
* unsupported-operation declarations;
* explicit non-claims.

A UAI packet may reference a discovery-result ID or capability-document digest. Protected discovery remains a runtime operation.

An expired or revoked capability document must not authorize new work.

Unknown capability semantics must fail closed.

## 6. Durable Delivery and Current-Message Semantics

Define the exact relationship among:

* event ID;
* logical message ID;
* fan-out ID;
* notification ID;
* delivery ID;
* task ID;
* task-attempt ID;
* conversation ID;
* correlation ID;
* causation ID;
* response ID;
* acknowledgement ID;
* cursor;
* idempotency key;
* trace ID;
* span ID.

Define a durable delivery state machine containing at least:

`submitted -> persisted -> visible -> claimed or observed -> handled -> acknowledged -> archived`

Also define:

* rejected;
* expired;
* cancelled;
* quarantined;
* revoked;
* dead-lettered.

Specify:

* unread-first current-message reads;
* stable cursors;
* cursor advancement;
* cursor reset;
* cursor ownership;
* at-least-once delivery;
* exact retry identity;
* duplicate detection;
* duplicate handling;
* lease-based message claims;
* claim expiration;
* response-required disposition;
* bounded polling;
* long polling;
* quarantine;
* acknowledgement readback;
* lost-response recovery;
* archival.

Distinguish:

* receiving;
* observing;
* claiming;
* handling;
* responding;
* acknowledging;
* committing an acknowledgement;
* advancing a cursor.

A portable acknowledgement packet is not by itself proof that the durable service committed the acknowledgement.

Specify the authoritative readback needed before an implementation may claim that a notification was durably acknowledged.

## 7. Coordinator and Worker Failure

Define behavior for:

* worker crash before claim;
* worker crash after claim;
* worker crash after handling but before acknowledgement;
* worker crash after sending a result but before receiving confirmation;
* coordinator crash;
* scheduler crash;
* durable-service restart;
* network partition;
* lost response;
* duplicate response;
* stale coordinator;
* stale worker;
* clock skew;
* delayed message;
* expired lease;
* abandoned task;
* repeated poison message.

Specify coordinator epochs or equivalent fencing so a replaced coordinator cannot continue mutating the swarm.

Specify how the runtime recovers work without falsely reporting that it was never handled or was handled twice.

## 8. Authorization and Entitlement

Create an authorization model in which trust metadata and signatures never substitute for server authorization.

Cover:

* least-privilege agent credentials;
* credential principal;
* credential issuer;
* exact project binding;
* exact swarm binding;
* exact role binding;
* exact task binding where appropriate;
* project-room visibility;
* self-only current-message reads;
* permitted delegation depth;
* permitted recipient set;
* acknowledgement only for a visible notification;
* acknowledgement only after allowed handling;
* task completion only by the active claimant or authorized coordinator;
* memory mutation only with the required entitlement;
* public-safe status submission to a registered coordinator;
* prohibition on client-supplied hidden tenant authority;
* prohibition on client-supplied actor substitution;
* credential rotation;
* credential revocation;
* expiry;
* device epoch;
* process epoch;
* rate limits;
* authenticated entitlement readback.

Define a non-interactive, pre-authorized bootstrap pattern:

1. An owner supplies a protected master-authority file through a secure local mechanism.
2. The agent authenticates using that authority.
3. The agent discovers its exact tenant, workspace, project, role, and swarm binding.
4. The agent registers or mints a narrower runtime credential.
5. The agent stores the narrower credential using protected local storage.
6. The agent verifies the credential and entitlement readback.
7. The agent continues without repeated human approval.

The master authority must never:

* become the routine runtime credential;
* appear in a UAI packet;
* appear in logs intended for public handoff;
* be sent to another agent;
* be embedded in a `.uai` package;
* be placed in durable message content.

## 9. Runtime Leases

Define separate lease models for:

* normalized registered agent name;
* active logical agent;
* runtime instance;
* operating-system process;
* `.uai` identity;
* coordinator authority;
* task claim;
* message claim.

For each lease, specify:

* lease ID;
* owner;
* protected resource;
* acquisition preconditions;
* duration;
* heartbeat interval;
* expiration;
* renewal;
* fencing token or epoch;
* release;
* revocation;
* takeover;
* stale-owner behavior;
* portable evidence fields;
* authoritative runtime fields.

A heartbeat must not renew a lease belonging to a different process epoch.

A stale process must be fenced from writes after replacement.

## 10. Shared Memory, Revision, and Conflict Handling

Define storage-neutral rules for shared swarm memory and project state.

Require:

* immutable revision history;
* exact-parent writes;
* expected-revision writes;
* atomic compare-and-set behavior;
* typed conflicts;
* preserved competing candidates;
* recorded author;
* recorded task and swarm context;
* tombstones;
* supersession;
* explicit resolution authority;
* resolution evidence.

Prohibit:

* last-write-wins;
* silent overwrite;
* silent merge;
* LLM-selected conflict winners without authorization;
* discarding a losing candidate;
* treating two distinct `.uai` identities as one identity;
* inferring branch lineage from similar content.

Define conflict types such as:

* stale-parent;
* concurrent-update;
* identity-collision;
* lease-conflict;
* deleted-resource;
* superseded-resource;
* schema-conflict;
* authorization-conflict;
* semantic-resolution-required.

Clarify what UAIX records as portable evidence and what the runtime must enforce transactionally.

## 11. Backpressure, Capacity, and Resource Control

Define swarm-management behavior for:

* worker concurrency limits;
* queue depth;
* maximum in-flight tasks;
* per-agent rate limits;
* per-project rate limits;
* payload-size limits;
* resource budgets;
* token budgets;
* cost budgets;
* deadline propagation;
* admission control;
* overload rejection;
* retry storms;
* priority inversion;
* starvation prevention;
* poison-task quarantine.

Backpressure must produce explicit typed results. The runtime must not silently discard work.

## 12. Observability and Causal Evidence

Define portable evidence needed to reconstruct a swarm run, including:

* swarm-run creation;
* membership changes;
* coordinator epochs;
* task creation;
* task delegation;
* task claims;
* task attempts;
* lease changes;
* message delivery;
* task progress;
* blockers;
* retries;
* cancellations;
* results;
* acknowledgements;
* conflicts;
* resolutions;
* final aggregation.

Use W3C Trace Context concepts where useful, while clearly separating trace correlation from authorization and durable identity.

Define deterministic causal references using:

* parent event;
* causation event;
* correlation group;
* task lineage;
* response relationship;
* fan-out relationship.

A trace ID must not be treated as a security boundary or transaction identifier.

## 13. Strict Schema and Extension Policy

Recommend one clean pre-release UAI-1 swarm contract.

Do not recommend:

* legacy aliases;
* compatibility matrices;
* deprecated duplicate fields;
* implicit mode fallbacks;
* multiple contracts for the same behavior;
* unversioned semantic extensions.

Specify where:

* unknown fields must fail;
* unknown enum values must fail;
* unknown profiles must fail;
* unknown delivery modes must fail;
* unsupported extensions must fail;
* namespaced non-semantic evidence may be retained but not acted upon.

Define:

* `additionalProperties` behavior;
* duplicate JSON-key rejection;
* maximum nesting depth;
* maximum packet size;
* maximum string size;
* maximum recipient count;
* Unicode normalization;
* invalid Unicode handling;
* number handling;
* date-time format;
* keyed and keyless packets;
* canonicalization;
* JSON Canonicalization Scheme use;
* deterministic hashing;
* signature coverage;
* excluded transport metadata;
* field ordering implications;
* extension versioning;
* capability negotiation.

An implementation must not execute semantics it did not advertise and negotiate.

## Required Deliverables

Return one cohesive report with all of the following.

### 1. Executive decision

State the recommended normative swarm architecture in direct terms.

### 2. Existing strengths and bounded gap analysis

Briefly identify the UAIX capabilities that already work and should be preserved.

Then identify only the swarm-management gaps.

### 3. Evidence classification table

Separate:

* current UAIX;
* proposed UAIX;
* runtime-owned behavior;
* future research.

### 4. Unsafe-assumption critique matrix

For every unsafe behavior found in the supplied multi-agent proposal, provide:

* assumption;
* failure scenario;
* security or reliability consequence;
* normative decision;
* typed error or outcome;
* whether UAIX rejects it;
* whether capability negotiation resolves it;
* whether the runtime must project it into safer one-to-one operations.

### 5. Identity and lineage specification

Provide exact field definitions, normalization rules, uniqueness scopes, and examples.

### 6. Swarm topology and membership specification

Define swarm, run, membership, role, coordinator epoch, and lifecycle behavior.

### 7. Task graph and coordination specification

Define task states, dependencies, delegation, claims, retries, cancellation, and completion.

### 8. Addressing and fan-out decision record

Compare the three required models and recommend one.

### 9. Durable-delivery state machine

Provide a transition table containing:

* current state;
* operation;
* required actor;
* required entitlement;
* preconditions;
* next state;
* portable evidence;
* authoritative readback;
* error result.

### 10. Acknowledgement model

Define evidence acknowledgement, runtime-committed acknowledgement, cursor advancement, duplicate acknowledgement, and lost-response recovery.

### 11. Authorization and entitlement model

Provide resource-action entitlement tables and bootstrap behavior.

### 12. Lease and fencing model

Define identity leases, process leases, coordinator leases, task claims, and message claims.

### 13. Revision and conflict model

Define exact-parent writes, immutable revisions, preserved candidates, conflict resolution, tombstones, and supersession.

### 14. Normative field tables

For every proposed field, provide:

* JSON path;
* type;
* required or optional status;
* cardinality;
* normalization;
* maximum size;
* allowed values;
* signer coverage;
* privacy classification;
* authoritative source;
* validation error code.

### 15. JSON Schema fragments

Provide exact draft-compatible JSON Schema fragments for all proposed swarm-related structures.

Use strict object schemas.

### 16. Runtime-neutral API operation table

For each operation, provide:

* method;
* logical route;
* authentication requirement;
* required entitlement;
* request fields;
* idempotency scope;
* transaction boundary;
* response;
* typed errors;
* authoritative readback.

Include operations for:

* agent registration;
* capability discovery;
* swarm-run creation;
* membership;
* task submission;
* task claim;
* task lease renewal;
* task completion;
* message read;
* acknowledgement;
* cursor read;
* entitlement readback;
* memory revision submission;
* conflict resolution;
* cancellation;
* final swarm completion.

### 17. Storage-neutral relational model

Provide tables, keys, foreign keys, uniqueness constraints, indexes, revision fields, lease fields, and transaction boundaries.

Include at minimum:

* Agent;
* AgentName;
* CredentialPrincipal;
* ProjectMembership;
* CapabilityDocument;
* Swarm;
* SwarmRun;
* SwarmMembership;
* CoordinatorEpoch;
* Task;
* TaskDependency;
* TaskAttempt;
* TaskLease;
* LogicalMessage;
* FanOut;
* Delivery;
* Notification;
* Acknowledgement;
* Cursor;
* MemoryIdentity;
* MemoryRevision;
* Conflict;
* ConflictCandidate;
* Resolution;
* IdempotencyRecord;
* AuditEvent.

### 18. Conformance fixtures

Provide at least 16 valid fixtures and 30 invalid fixtures.

The invalid fixtures must include:

* unsupported multicast;
* single-target parser receiving multicast;
* duplicate recipient;
* unauthorized recipient;
* cross-project recipient;
* partial fan-out incorrectly reported as complete;
* unknown delivery mode;
* unknown acknowledgement mode;
* expired capability document;
* revoked agent;
* invalid coordinator epoch;
* stale coordinator write;
* same identity active in two forbidden runtimes;
* same `.uai` identity active in two forbidden processes;
* expired process lease;
* expired task claim;
* acknowledgement before handling;
* acknowledgement by the wrong agent;
* acknowledgement of an invisible notification;
* cursor advancement without committed acknowledgement;
* wrong cursor;
* cursor from another project;
* duplicate delivery;
* duplicate task completion;
* lost response;
* retry with a different logical operation;
* stale memory revision;
* silent merge attempt;
* last-write-wins attempt;
* client-supplied tenant authority;
* master credential embedded in evidence.

### 19. Validator and stable error registry

Define stable error codes grouped by:

* schema;
* identity;
* membership;
* capability;
* addressing;
* authorization;
* delivery;
* acknowledgement;
* cursor;
* lease;
* task;
* concurrency;
* revision;
* conflict;
* extension;
* canonicalization;
* signature;
* size limit.

Each error must state whether it is:

* retryable;
* terminal;
* quarantinable;
* safe no-op;
* security-relevant.

### 20. Security and privacy threat model

Analyze at least:

* recipient confusion;
* identity collision;
* stale coordinator;
* credential substitution;
* replay;
* cross-project access;
* multicast privacy leakage;
* forged acknowledgement;
* cursor theft;
* lease theft;
* coordinator split brain;
* task duplication;
* memory overwrite;
* conflict suppression;
* malicious extension;
* oversized payload;
* retry storm;
* capability downgrade;
* endpoint redirect attack;
* master-credential leakage.

### 21. Documentation information architecture

List exact UAIX pages to add, revise, replace, or remove.

Recommend a clear hierarchy for:

* swarm overview;
* identity;
* membership;
* tasks;
* messaging;
* acknowledgement;
* authorization;
* leases;
* shared state;
* profiles;
* schemas;
* validator;
* conformance;
* runtime guidance;
* security considerations.

### 22. Pre-release replacement plan

Provide a plan that:

* removes superseded proposal language;
* eliminates ambiguous or permissive swarm behavior;
* publishes one authoritative contract;
* updates schemas, examples, registry, validator, and fixtures together;
* identifies proposal material that remains historical only;
* prevents conflicting documentation from remaining publicly normative.

## Required Normative Language

Use RFC-style terms consistently:

* MUST;
* MUST NOT;
* REQUIRED;
* SHALL;
* SHALL NOT;
* SHOULD;
* SHOULD NOT;
* MAY.

Each normative rule must have a corresponding validation rule, runtime rule, conformance fixture, or clearly stated reason why it cannot be mechanically tested.

## Decision Standard

For every ambiguous case, answer all of the following:

1. What does the sender believe happened?
2. What did the receiver actually do?
3. What did the durable runtime commit?
4. What portable evidence exists?
5. What authoritative readback proves the claim?
6. What happens when the operation is unsupported?
7. What stable error code is returned?
8. Is retry safe?
9. What is the idempotency scope?
10. Could authority, privacy, identity, or recipients be silently changed?

Any design that leaves these questions implementation-defined is incomplete.

## Acceptance Criteria

The report is complete only when:

* UAIX’s existing useful behavior is preserved.
* The analysis remains focused on agent-swarm management.
* Current behavior and proposed behavior are never conflated.
* Independent implementations can interoperate without guessing.
* Every unsupported semantic fails closed.
* No recipient can be silently omitted.
* Multicast cannot degrade into single-target execution.
* Every delivery has an unambiguous identity.
* Every acknowledgement refers to one handled delivery.
* Durable acknowledgement claims require authoritative runtime readback.
* Signatures never substitute for authorization.
* Agent, process, credential, project, swarm, and memory identities remain distinct.
* Stale coordinators and processes are transactionally fenced.
* Shared-memory updates require exact-parent or expected-revision checks.
* Conflicting candidates are preserved.
* No last-write-wins behavior is permitted.
* No silent LLM merge is permitted.
* The schema, validator, fixtures, API contract, and relational model describe the same behavior.
* The final result can be converted directly into normative UAIX documentation without another architectural design phase.

## Tone

Write as a constructive standards-improvement report.

Do not attack, dismiss, rank, or judge UAIX or its author.

Do not spend time determining whether UAIX is popular, independently endorsed, commercially funded, or widely adopted.

Treat UAIX as a functioning system with a specific engineering gap: durable, secure, interoperable agent-swarm management.

Concentrate exclusively on closing that gap.