A Normative UAIX Multi-Agent Contract for Durable, Fail-Closed Systems

Full report

On this page

Executive Decision and Recommended Normative Architecture

The deployment of autonomous multi-agent systems interacting over shared memory and durable message buses introduces severe operational vulnerabilities if the underlying communication protocols permit implicit fallbacks, permissive parsing, or ambiguous authority. Existing standard implementations often conflate the messaging envelope with the runtime execution environment, leading to catastrophic split-brain scenarios. In such environments, a sender might operate under the assumption that a highly critical task is universally acknowledged, while the recipient runtime silently drops unparsable fields or executes a partial directive. This drift between intended state and executed state completely undermines the trust required for autonomous enterprise operations1. To resolve these vulnerabilities definitively, the normative architecture for UAIX (Universal AI Exchange) must rigidly enforce the boundary between the portable evidence layer and the durable execution runtime. UAIX shall serve exclusively as the cryptographically verifiable, strictly schematized, and deterministic record of intent, capability, and state. The surrounding runtime—such as MemoryEndpoints.com or any conforming Multi-Agent Transactive Memory (MATM) implementation4—retains absolute authority over execution, credential validation, durable queue materialization, cursor advancement, and database transactions. The foundational design philosophy for this multi-agent contract is strict fail-closed capability. An independent UAIX implementation must refuse to process, forward, or acknowledge any envelope containing unsupported operational modes, unrecognized extensions, or ambiguous routing logic. Compatibility through silent degradation is expressly forbidden. If an agent receives a multicast directive it cannot cryptographically prove it has the capability to expand and track, it must issue a typed rejection. UAIX packets serve as immutable artifacts; they do not dictate exact-once delivery on their own but provide the necessary idempotency and correlation keys that permit a stateful runtime to achieve exactly-once processing across distributed boundaries2.

Critique Matrix for Unsafe Assumptions

Previous multi-agent proposals contained structural assumptions that degrade systemic accountability. Analyzing these assumptions exposes the exact points where permissive designs fail under the stress of autonomous operations. The following matrix directly addresses these unsafe behaviors, establishing the normative UAIX standard response and explicitly defining the runtime boundary.

Evidence Table: Boundary Separations

To guarantee interoperability between independent implementations without guessing fallback states, it is crucial to explicitly divide responsibilities. The table below delineates what the portable UAIX evidence layer enforces versus what the durable service enforces.

Identity and Lineage Model

Multi-agent ecosystems suffer cascading failures when identity is treated as a flat string. To support concurrent processing, lifecycle tracking, and zero-trust verification across diverse networks, UAIX defines a highly structured, storage-neutral identity model2.

Identifier Taxonomy and Field Definitions

The model distinguishes identifiers to prevent privilege escalation and ensure that portable evidence can be audited without exposing private infrastructure details.

1. label (Human-Visible): A non-unique display string (e.g., "Data Analyst Agent"). This field is omitted from cryptographic identity proofs and is used solely for UI rendering and human debugging.
2. logical\_agent\_id (Canonical): A persistent URN (e.g., urn:uaix:agent:uuid) that survives infrastructure migrations, software updates, and credential rotations. This forms the bedrock of long-term reputation and transactive memory contribution tracking4.
3. registered\_name (Normalized): A strict alphanumeric identifier normalized to lowercase and underscores (e.g., financial\_analyst\_v2). The runtime enforces unique leases on this name within a specific project to prevent duplicate agent instantiations from processing the same queues.
4. principal\_id (Credential): The cryptographic identity (e.g., a Decentralized Identifier (DID) or the Subject sub claim of an OIDC token) bound to the agent's authentication material. This is service-private and transport-bound.
5. authority\_binding (Tenant/Project): An explicit multi-tenant scoping array (e.g., tenant:alpha, workspace:finance, project:q3\_analysis). UAIX records must specify the exact boundary to prevent cross-contamination.
6. instance\_id (Runtime Process): An ephemeral UUID generated at process startup. If a container restarts or is preempted, the logical\_agent\_id remains constant, but the instance\_id rotates, ensuring that stale network packets bound for a dead process are discarded.
7. uai\_identity (.uai Memory): A deterministic cryptographic hash (e.g., SHA-256) of the agent's initial .uai startup memory configuration. This allows a consumer to verify the exact behavioral prompt and system instructions the agent was instantiated with, guaranteeing supply-chain security for behavior9.
8. branch\_id and parent\_id (Lineage): Used exclusively when an agent clones itself or spins up a sub-agent. The branch\_id is unique to the clone, while parent\_id points to the orchestrator or parent instance, creating a mathematically provable execution tree.
9. role: An enumerated value restricted to orchestrator, coordinator, worker, observer, or service.

Uniqueness, Collision, and Continuity Rules

Identifiers belonging to public UAI evidence include the logical\_agent\_id, registered\_name, uai\_identity, and role. These can be safely published in transparency logs. Conversely, the principal\_id and instance\_id are service-private or bound strictly to the transport layer and must never be inferred by a client payload directly. Collision Behavior: The contract explicitly forbids the same normalized\_registered\_name coupled with the same authority\_binding from running in two concurrent processes unless the capability document explicitly declares a stateless\_worker pool policy. If a stateful agent attempts to lease an active identity, the runtime MUST reject it with a typed ERR\_IDENTITY\_LEASE\_CONFLICT. Credential Rotation and Identity Continuity: If an agent's credentials are rotated, the new principal\_id is mapped to the existing logical\_agent\_id within the runtime's internal database. Revocation of the underlying credential immediately invalidates the associated instance\_id lease, terminating the agent's ability to pull from its durable queues or interact with shared memory endpoints7.

Addressing and Fan-Out Decision Record

The ability for a single agent to communicate with multiple agents simultaneously requires stringent protocol boundaries to avoid split-brain states and authorization bypasses.

Comparison of Explicit Designs

1. One envelope with a closed ordered recipient set: The sender constructs a single JSON payload containing an array of targets.

• Drawback: If Recipient A lacks the authority to verify Recipient B, privacy is violated. Furthermore, if the network partitions after delivering to Recipient A but before Recipient B, the system enters an ambiguous state where the sender cannot cryptographically prove partial failure without complex, multi-party consensus.

1. One parent event plus service-created per-recipient delivery records: The sender submits a generic multicast intent to the runtime, which then creates new records.

• Drawback: The original cryptographic signature of the sender is broken when the runtime unpacks and repackages the envelope for each recipient. The recipient can only verify the runtime's signature, not the original sender's intent.

1. Deterministic one-to-one envelope expansion with a shared fan-out ID: The sender creates a base payload hash and a deterministic fanout\_id. The sender (or an authorized dispatch coordinator acting on its behalf) generates individual, cryptographically signed one-to-one UAIX envelopes for each recipient.

Normative Decision: Deterministic One-to-One Expansion

UAIX normative addressing SHALL mandate deterministic one-to-one envelope expansion. A multi-agent sender MUST NOT send a single UAIX payload with multiple target addresses directly to another worker agent. If a sender wishes to multicast, it must submit an intent\_to\_fanout packet to an authorized coordinator or the durable runtime. The runtime then acts as the expanding authority, verifying the sender's entitlements for each individual target and materializing [Figure omitted from source export] distinct one-to-one UAIX envelopes. Rationale:

• Privacy Boundaries: Recipient A cannot see that Recipient B was addressed unless explicitly authorized by the project RBAC.
• Partial Failure and Retry: If delivery to Recipient B fails, Recipient A's delivery record remains valid and logically isolated. Retries are managed per delivery\_id rather than blocking the entire multicast batch.
• Evidence Identity: Each generated envelope contains the original payload's immutable hash alongside a unique delivery\_id, allowing mathematically verifiable, per-recipient acknowledgement that preserves the sender's original non-repudiation signature.

Any single-target implementation that receives a multicast packet directly MUST reject it with ERR\_ADDRESSING\_VIOLATION. Unsupported multicast operations must fail with a typed safe no-op or be expanded by an authorized runtime before delivery.

Discovery and Capability Negotiation

Discovery allows agents to map the network dynamically without relying on human intervention, avoiding the vulnerability of trusting unverified display labels or outdated configurations.

Authoritative Publisher and Visibility

The durable runtime (e.g., MemoryEndpoints.com) serves as the authoritative discovery publisher. Agents must publish a signed Capability Document to the registry. Visibility is strictly filtered; an agent querying the registry only receives data regarding other agents within their exact project and role authorization boundaries1.

Capability Document Constraints and Freshness

A UAIX Capability Document MUST contain:

• schema\_version: The exact UAIX version supported (e.g., 1.2.0). No wildcards or ranges are permitted.
• supported\_modes: Explicit enumeration of communication modes (e.g., sync\_rpc, async\_durable, stream\_delta).
• input\_schema\_hash / output\_schema\_hash: Deterministic SHA-256 hashes of the exact JSON schemas the agent is willing to accept and produce.
• expiry: A Unix timestamp dictating cache lifetime (maximum 3600 seconds).

Clients MUST respect the expiry parameter. If a capability document expires, it must be refetched from the registry. If the runtime revokes an agent's lease due to missed heartbeats or credential revocation, the runtime immediately invalidates and purges the capability cache.

Unsupported Operations

If an agent receives a directive outside its published capabilities (e.g., an agent declaring only async\_durable receives a stream\_delta request), it MUST fail closed with ERR\_CAPABILITY\_MISMATCH. Capability documents are immutable evidence; if an agent's internal logic upgrades, it must publish a new document with a new revision hash. This prevents an agent from executing semantics it does not formally understand, a critical requirement for high-accountability automation.

Durable Delivery and Current-Message Semantics

The durable delivery of UAIX envelopes bridges the portable evidence layer and the runtime state. It ensures that messages are not lost in transit and that acknowledgements actually correspond to completed work.

Relationship Among Identifiers

To guarantee traceability, the following identifiers interact structurally:

• event\_id: A runtime-generated UUID mapping to the transport layer occurrence.
• logical\_message\_id: The canonical ID of the data payload generated by the sender.
• notification\_id: The trigger signal alerting the recipient to check its queue.
• delivery\_id: The unique ID mapping a logical\_message\_id to a specific recipient. This is the primary key for the state machine.
• conversation\_id: Binds multiple sequential logical\_message\_ids into a cohesive multi-turn interaction.
• correlation\_id: Used for cross-system RPC tracing.
• response\_id: Links a reply explicitly to the originating logical\_message\_id.
• idempotency\_key: A client-generated UUID used solely by the runtime to deduplicate incoming HTTP/transport requests within a strict retention window (e.g., 24 hours).
• cursor: A monotonically increasing integer managed exclusively by the runtime, representing an agent's read position in a durable queue.

The Durable State Machine

Every delivery\_id traverses a strict state machine enforced transactionally by the runtime:

1. SUBMITTED: The sender transmits the packet over the network to the runtime.
2. PERSISTED: The runtime validates the schema, commits the packet to disk, and responds to the sender with HTTP 201 Created.
3. VISIBLE: The packet becomes available to the recipient based on canonical ordering and visibility timeout logic.
4. CLAIMED: The recipient initiates an unread-first current-message read. The runtime places a temporary lease (e.g., 5 minutes) on the message to prevent concurrent workers from reading it.
5. HANDLED: The recipient completes the required processing locally.
6. ACKNOWLEDGED: The recipient submits a signed UAIX acknowledgement packet to the runtime, which cryptographically references the delivery\_id and the resolution\_hash.
7. ARCHIVED: The runtime validates the ACK, advances the recipient's cursor, and moves the delivery record to cold storage.

Failure Transitions:

• REJECTED: The payload fails capability, schema, or authorization validation prior to reaching PERSISTED.
• EXPIRED: The time-to-live (TTL) elapses before reaching the HANDLED state.
• QUARANTINED: The recipient attempts to process the message but throws an unhandled exception, exceeding the maximum exact retry count. Bounded polling prevents infinite loops.
• REVOKED: The sender or a coordinator cancels the delivery\_id before it reaches the CLAIMED state.

At-least-once delivery is guaranteed by the runtime via the CLAIMED timeout. If the recipient does not submit an ACKNOWLEDGED transition before the lease expires, the message lease is dropped, and the message reverts to VISIBLE for retry. UAIX explicitly denies the claim of exactly-once delivery; exactly-once processing must be achieved by the recipient utilizing the delivery\_id as a local idempotency key. An acknowledgement packet is portable evidence of intent; it is not automatically proof of execution until the authoritative runtime readback confirms the ARCHIVED state transition.

Authority and Entitlement Model

Trust metadata embedded within a UAIX packet (such as a signed token) is portable evidence, but it never substitutes for real-time server authorization2.

Least-Privilege and Exact Binding

Every operation requires a verified credential. The runtime must enforce absolute boundaries:

• Project-Room Visibility: Agents can only read messages, discover capabilities, or access MATM memory blocks explicitly bound to their assigned project UUID.
• Self-Only Current-Message Reads: An agent may only pull the queue associated with its own registered\_name and instance\_id.
• Acknowledgement Constraints: An agent can only acknowledge a notification that is currently in the VISIBLE or CLAIMED state assigned to its own identity. Acknowledging a future, archived, or unassigned delivery\_id triggers ERR\_INVALID\_ACK\_TARGET.
• Public-Safe Status Submission: Status updates submitted to a registered coordinator must be sanitized to remove private network data.
• No Hidden Authority: A client cannot supply its own authority headers or assert tenant impersonation. The runtime derives tenant authority strictly from the cryptographically verified principal\_id7.

Non-Interactive Pre-Authorized Bootstrap Pattern

For advanced continuous integration and zero-trust environments, UAIX defines a non-interactive bootstrap pattern that avoids repeated human approval.

1. An orchestrator provisions a highly restricted, short-lived "master-authority" file to an isolated ephemeral volume.
2. The agent starts, reads this file, and uses it once to call the runtime's /v1/bootstrap endpoint over mTLS.
3. The runtime evaluates the master authority, discovers the exact project binding, and mints an instance-specific, narrow credential (e.g., an X.509 certificate or local JWT tightly bound to the instance\_id).
4. The agent stores this new credential in an ephemeral, memory-only vault. The master credential is computationally destroyed from the agent's local memory and volume.
5. The agent proceeds to use the instance credential for subsequent API calls.

Crucially, the master credential must not become the ordinary runtime credential, appear in UAIX packets, or be transported in public handoffs. The authenticated entitlement readback from the runtime relies entirely on the narrow instance credential, which is subject to device epochs, rotation, and strict rate limits.

Concurrency, Shared State, and Runtime Leases

Autonomous agents writing to shared memory surfaces—such as MATM wiki pages, strategy repositories, or shared JSON state4—risk catastrophic data corruption if concurrent writes are handled poorly. "Last-write-wins" (LWW) and LLM-driven silent text merges are explicitly banned in normative UAIX.

Revision and Tombstone Model

Every shared memory object possesses an immutable revision\_hash. To mutate memory, an agent must submit an exact-parent write. The UAIX payload must include the expected\_parent\_hash. If the runtime's current hash matches the expected\_parent\_hash, the write succeeds, the state updates, and a new revision\_hash is generated. If another agent has mutated the memory in the interim, the runtime rejects the write with ERR\_STALE\_REVISION\_CONFLICT.

Typed Conflicts and Supersession

When ERR\_STALE\_REVISION\_CONFLICT occurs, the runtime preserves the losing candidate as a typed CONFLICT record, linked to the object. It does not attempt to silently merge the JSON trees. The losing agent receives a failure notification containing the new revision\_hash and the conflicting diff. It is the agent's responsibility to re-read the state, computationally reason about the diff, and submit a new exact-parent write. Once a conflict is resolved, the runtime creates a tombstone denoting the supersession event, ensuring full auditability of the resolution.

Identity and Process Leases

The runtime implements a distributed lock manager to govern identity and process execution:

• Process/Runtime Leases: A running agent must maintain a heartbeat every 30 seconds. If three consecutive heartbeats are missed, the runtime expires the instance\_id lease, marks the instance as offline, and returns any CLAIMED messages to the VISIBLE queue to prevent lost-response lockups.
• Normalized Agent-Name Leases: An orchestrator can place an exclusive lock on a normalized\_registered\_name, preventing any new instances from bootstrapping under that identity.
• .uai Identity Leases: Ensures that an agent with a specific startup prompt cannot be altered without generating a new uai\_identity hash.
• True Branches: When an agent forks a new branch, it records the lineage, establishing a new identity while maintaining cryptographic ties to the parent's revision\_hash.

UAIX records the explicit payload and the expected\_parent\_hash as portable evidence. The durable service must enforce the transactionally consistent writes and exact-parent validation.

Strict Schema and Extension Policy

High-accountability automation requires deterministic parsing. UAI-1 drops all legacy aliases, deprecated fields, and unversioned extension properties to prevent parsing discrepancies that lead to security bypasses.

Canonicalization and Field Rules

• No Unknown Fields: Schemas MUST set "additionalProperties": false. Any JSON payload containing unmapped keys MUST be rejected immediately.
• Canonicalization: Before calculating any cryptographic signatures or hashes, the JSON payload MUST be canonicalized according to the JSON Canonicalization Scheme (JCS \- RFC 8785). This ensures field order, whitespace, and Unicode representations are identical across all parsers, preventing signature invalidation across diverse language runtimes.
• Namespaced Extensions: If two agents agree on an extension, it MUST be placed within a strict extensions object, keyed by a registered URI (e.g., "extensions": {"https://acme.corp/uaix/v1": {...}}). However, an agent receiving an extension it did not explicitly declare support for during Capability Negotiation MUST reject the entire payload.
• Duplicate Keys: JSON parsers MUST be configured to reject duplicate keys.
• Maximum Sizes and Unicode: String lengths must be bounded to prevent denial-of-service via memory exhaustion, and all strings must be strictly UTF-8 encoded.

Normative UAI-1 Schema and Profile Changes

To enforce the strict schema policy, the UAI-1 core envelope is updated. Below are the exact JSON Schema fragments representing the normative boundaries.

The UAIX Core Envelope Fragment

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://uaix.network/schema/v1/envelope.json", "type": "object", "additionalProperties": false, "required": \[ "version", "logical\_message\_id", "sender", "recipient", "delivery\_mode", "payload" \], "properties": { "version": { "type": "string", "const": "1.0.0" }, "logical\_message\_id": { "type": "string", "format": "uuid" }, "fanout\_id": { "type": "string", "format": "uuid" }, "sender": { "type": "object", "additionalProperties": false, "required": \["logical\_agent\_id", "uai\_identity", "signature"\], "properties": { "logical\_agent\_id": { "type": "string", "format": "uri" }, "uai\_identity": { "type": "string", "maxLength": 64 }, "signature": { "type": "string", "maxLength": 512 } } }, "recipient": { "type": "object", "additionalProperties": false, "required": \["logical\_agent\_id", "delivery\_id"\], "properties": { "logical\_agent\_id": { "type": "string", "format": "uri" }, "delivery\_id": { "type": "string", "format": "uuid" } } }, "delivery\_mode": { "type": "string", "enum": \["async\_durable", "sync\_rpc"\] }, "payload": { "type": "object", "additionalProperties": true }, "extensions": { "type": "object", "patternProperties": { "^https?://": { "type": "object" } }, "additionalProperties": false } } }

Acknowledgement Profile Fragment

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://uaix.network/schema/v1/acknowledgement.json", "type": "object", "additionalProperties": false, "required": \["target\_delivery\_id", "status", "handled\_at"\], "properties": { "target\_delivery\_id": { "type": "string", "format": "uuid" }, "status": { "type": "string", "enum": \["COMPLETED", "FAILED\_TERMINAL", "DEFERRED", "QUARANTINED"\] }, "handled\_at": { "type": "string", "format": "date-time" }, "resolution\_hash": { "type": "string", "maxLength": 64 } } }

Runtime-Neutral API Operation Table

The runtime MUST implement these RESTful boundaries6, treating UAIX payloads as atomic request/response bodies. This ensures that independent implementations interoperate smoothly.

Storage-Neutral Relational Model

To enforce transaction boundaries and uniqueness constraints, the runtime MUST implement a relational or strictly consistent data model matching the following specifications.

Conformance Fixtures

To achieve acceptance criteria, independent implementations must test against a strict matrix of 32 fixtures. The design mandates that every unsupported or ambiguous case must fail closed with a typed result.

Valid Fixtures (V01 - V12)

Invalid Fixtures (I01 - I20)

These fixtures test the fail-closed boundaries. Implementations must return the exact error code.

Validator and Conformance Rules

A conforming UAIX Validator MUST output standardized error codes to ensure programmatic routing of failures within autonomous workflows. Silent handling is strictly forbidden. The validator acts as the absolute gatekeeper before the runtime applies durable state transitions.

• ERR\_SCHEMA\_VIOLATION: Triggered when a JSON payload contains unknown fields, lacks required fields, violates maximum size constraints, or violates type constraints. Action: Reject request. Disconnect immediately if via stream.
• ERR\_JCS\_INVALID: Triggered when cryptographic signature verification fails because the payload was not normalized to RFC 8785 canonicalization. Action: Reject. Log signature mismatch for security auditing.
• ERR\_MULTICAST\_UNSUPPORTED: Triggered when an endpoint receives an envelope with multiple implicit targets instead of a specific one-to-one delivery\_id. Action: Reject. Instruct sender to use the dispatcher route.
• ERR\_UNKNOWN\_DELIVERY\_MODE: Triggered when the delivery\_mode enum value is not registered in the agent's Capability Document. Action: Reject.
• ERR\_STALE\_REVISION\_CONFLICT: Triggered when the expected\_parent\_hash does not match the runtime's current active state. Action: Reject with HTTP 409 Conflict. Return the current active hash to the client.
• ERR\_INVALID\_ACK\_TARGET: Triggered when an agent attempts to acknowledge a delivery\_id not assigned to it, or one that is not in the CLAIMED state. Action: Reject with HTTP 403 Forbidden.
• ERR\_IDENTITY\_LEASE\_CONFLICT: Triggered during a bootstrap attempt using a normalized\_registered\_name that is already leased by an active instance. Action: Reject with HTTP 423 Locked.

Security and Privacy Threat Model

A robust threat model is essential for UAIX, given that AI agents possess the capacity to execute long-running tasks and manipulate external systems7.

Threat: Authority Escalation via Payload Spoofing

Vector: A malicious or hallucinating agent inserts a high-privileged tenant\_binding into the UAIX payload JSON in an attempt to access another tenant's project or issue unauthorized commands. Mitigation: The UAIX parser ignores client-supplied tenant strings for authorization. The runtime performs authoritative readback, extracting the tenant\_binding strictly from the cryptographically verified principal\_id validated at the transport layer7.

Threat: Replay Attacks on Shared Memory

Vector: A malicious observer intercepts a valid POST /v1/memory/shared request and replays it later to revert the state of a multi-agent wiki or repository, destroying subsequent work4. Mitigation: The UAIX-Revision-Hash constraint ensures that once the memory advances, the replayed packet's expected\_parent\_hash will be stale. The database will reject it deterministically with ERR\_STALE\_REVISION\_CONFLICT.

Threat: Ephemeral Instance Cloning (Process Collision)

Vector: A bad actor steals a valid agent configuration and boots a shadow instance, attempting to siphon the VISIBLE queue and process messages maliciously.Mitigation: The instance\_id lease is bound exclusively to the original instance's continuous heartbeat and principal\_id. The shadow instance will fail the ERR\_IDENTITY\_LEASE\_CONFLICT check at bootstrap and be denied queue access.

Threat: Capability Downgrade Attack

Vector: A middlebox modifies a Capability Document in transit to force an agent to use a less secure synchronous mode or to spoof capability matching.Mitigation: Capability Documents are signed by the principal\_id and normalized via JCS. Any alteration breaks the signature, resulting in the runtime rejecting the publication with ERR\_JCS\_INVALID.

Documentation Information Architecture and Replacement Plan

To enforce this new fail-closed standard, the UAIX documentation structure must be overhauled. Legacy permissive recommendations must be aggressively purged to establish a single, authoritative UAI-1 contract.

Required Information Architecture

The revised documentation tree shall be structured as follows:

1. /Concepts/Fail-Closed-Architecture: Explaining the boundary between the UAIX portable record and the MATM runtime, emphasizing zero-trust capabilities.
2. /Core-Specs/UAI-1-Envelope: The core JSON schema, JCS canonicalization rules, and strict parsing laws preventing unknown fields.
3. /Core-Specs/Identity-and-Lineage: Breakdown of logical IDs, instance leases, cryptographic principals, and branch lineage tracking.
4. /Operations/Durable-Delivery: The 7-step state machine, idempotency requirements, retry mechanisms, and exact-once processing logic.
5. /Operations/Shared-Memory: Exact-parent writes, revision hashes, conflict tombstones, and supersession logic.
6. /Security/Authorization-Model: The non-interactive bootstrap flow, RBAC policies, and authoritative entitlement readback.
7. /Testing/Conformance-Fixtures: The exact 32 normative fixtures and stable error code definitions necessary for validator compliance.

Pre-Release Replacement Plan

1. Phase 1: Deprecation Labelling. Immediately flag the legacy document Enabling Multi-Agent Support in UAIX.md as SUPERSEDED. Inject a preamble redirecting to the new normative architecture, explicitly stating that implicit fallbacks are no longer supported.
2. Phase 2: Schema Hardening. Deploy the updated JSON Schemas to the public registry. Enable additionalProperties: false globally. Issue immediate updates to all officially maintained SDKs to drop permissive parsing and implement the JCS validation layer natively.
3. Phase 3: Runtime Compliance. Ensure reference runtimes (such as MemoryEndpoints.com) fully implement the HTTP 409 Conflict handlers for UAIX-Revision-Hash and the exact-parent write logic. Activate the ERR\_IDENTITY\_LEASE\_CONFLICT lock manager.
4. Phase 4: Eradication. Permanently delete all legacy alias documentation, dual-contract references, and compatibility matrix tables from the active documentation repository. The UAI-1 contract will stand as a single, unambiguous specification for high-accountability autonomous multi-agent networks, ensuring that interoperability never compromises security.

Works cited

1. What is Agent Communication Protocol (ACP)? \- IBM, https://www.ibm.com/think/topics/agent-communication-protocol
2. How AI Agents Communicate: Mesh, Protocols & Trust, https://www.loginradius.com/blog/engineering/how-ai-agents-communicate
3. Rethinking operating models for humans with agents | Deloitte Insights, https://www.deloitte.com/us/en/insights/topics/talent/operating-models-for-humans-ai-agents.html
4. Multi-Agent Transactive Memory \- arXiv, https://arxiv.org/html/2606.19911v1
5. Multi-Agent Transactive Memory \- arXiv, https://arxiv.org/pdf/2606.19911
6. Agent Communication Protocol: Welcome, https://agentcommunicationprotocol.dev/introduction/welcome
7. Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents \- arXiv, https://arxiv.org/html/2606.22504v1
8. README.md \- IAAR-Shanghai/Awesome-AI-Memory \- GitHub, https://github.com/IAAR-Shanghai/Awesome-AI-Memory/blob/main/README.md
9. MultiAgentMemory.com | MATM Documentation, https://www.multiagentmemory.com/