Uaix AI Interoperability Standards - Source Excerpt 02 - Standardized Machine-Readable Files and Local Endpoint Discovery

Back to Uaix AI Interoperability Standards

Summary

This source excerpt begins near Standardized Machine-Readable Files and Local Endpoint Discovery and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-21-misplaced-uaix-ai-ready-web-duplicate/UAIX AI Interoperability Standards.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-21-misplaced-uaix-ai-ready-web-duplicate/UAIX AI Interoperability Standards.md

| UAI-1 File or Directory Element | Architectural Purpose and Strict Agent Instructions |
| :---- | :---- |
| **.uai/ Directory** | The primary operational envelope containing active Markdown and specific .uai formatted files. Represents compact, short-term project memory10. |
| **.uai/archives/ Directory** | The repository for raw evidence, legacy session logs, and durable history. Agents must move stale facts here to preserve active context10. |
| **.uai/exports/ Directory** | The isolated target location for machine-generated artifacts, ensuring generated JSON manifests do not pollute human-readable workspaces10. |
| **startup-packet.uai** | Contains non-negotiable operator instructions, setup modes, explicit data telemetry policies, and rules for Safe Structured Output Mode10. |
| **receiver-brief.uai** | Provides localized instructions detailing the agent's exact read order, workspace targets, and rigid expectations for its first system response10. |
| **system-profile.uai** | Defines the overarching rules for agent collaboration, architectural source authority, and deployment testing requirements10. |
| **coding-standards.uai** | A mandatory configuration file that enforces enterprise programming principles such as DRY (Don't Repeat Yourself) and SOLID architecture. Execution is hard-blocked if this is missing10. |
| **short-term-memory.uai** | The active, highly curated record of accepted project truth, containing current states, architectural blockers, constraints, and immediate next actions10. |
| **intake-outcome-ledger.uai** | A durable proof-of-use state ledger. Any files dropped for agent intake must have their final disposition and utilization recorded here to ensure auditability10. |

The interaction dynamics surrounding these schema files enforce a continuous and disciplined protocol known as Memory Reorganization10. UAIX.org stipulates that every production deployment or release package must serve as an explicit reorganization point. During these intervals, the AI agent is instructed to actively prune redundancy10. It must migrate stale history, resolved blockers, and bulky background rationale out of the active short-term-memory.uai file and into the .uai/archives/ directory, generating transfer evidence in the process10. This mechanism ensures the agent operates exclusively on "accepted project truth"—defined strictly as repository files, canonical documentation, released code, and public pages, explicitly excluding unverified chat history or spontaneous summaries10.  
A particularly advanced component of the UAI-1 schema is the "AI Dreaming Memory Protocol"10. In conventional deep learning, "dreaming" typically implies unsupervised model weight updates or latent space exploration on private data. The UAIX protocol redefines dreaming as a highly bounded, human-reviewable consolidation pass over visible project memory10. When configured, this protocol allows the agent to propose duplicate merges, note historical contradictions, and generate a hot/cold memory delta10. Crucially, the standard explicitly blocks the agent from executing an autonomous rewrite loop, training model weights, or forcing automatic repository commits during this phase10. By forcing all memory consolidation to occur in transparent, static files, UAIX.org ensures absolute auditability of the agent's evolving context.

## **Standardized Machine-Readable Files and Local Endpoint Discovery**

While the .uai folder suite governs the internal memory states of complex, long-running agent projects, the initial point of contact between a web platform and an approaching AI agent is governed by standardized machine-readable files located directly at the host's endpoints. UAIX.org mandates that websites surface their communication guidelines, allowed operational boundaries, and system capabilities using lightweight static files, thereby eliminating the need for complex, opaque API handshakes that obscure execution risk4.  
The primary artifact in this public discovery phase is the llms.txt file, which explicitly declares what an approaching agent can and cannot do on the site4. Instead of an agent attempting to scrape DOM elements to deduce a site's purpose, the host explicitly defines its safe read order, lists its available public JSON assets, outlines its ecosystem lane, and identifies the specific conditions that must trigger a request for human review5.  
This static discovery mechanism is deeply integrated with LocalEndpoint.com, the designated ecosystem lane for node capability discovery and local-to-public review bridges5. LocalEndpoint.com provides the architectural blueprints for how local nodes and offline sandboxes should describe their topology and capability levels to public agents5. It hosts .well-known/ai-agent.json directories and ability profile JSON files that agents can read to assess compatibility5.  
However, consistent with the defensive posture of the entire ecosystem, LocalEndpoint.com strictly prohibits the execution of the capabilities it describes5. The standard explicitly forbids private network probing, the execution of arbitrary local endpoints, the opening of unauthorized network tunnels, the validation of secrets, and the replay of webhooks5. The profound implication of this design is that "capability discovery" under the UAIX standard is fundamentally descriptive rather than permissive. An endpoint declaring a specific capability in a JSON file does not grant the agent the authority to execute it; it merely provides the static context necessary for the agent to formulate a localized plan, pending human review and explicit operator authorization5.

## **Strict Boundary Enforcement and the Dominance of the No-Op**

The most defining characteristic of the UAIX.org technical implementation is its strict enforcement of the "No-Op" (no operation) rule. In standard AI systems, agents exhibit a systemic bias toward continuous action. They are optimized to generate a response, execute a function, or hallucinate a plausible answer even when faced with high uncertainty or incomplete data. The UAIX schema structurally reverses this paradigm, establishing "no-op" as the dominant safe action and the preferred default state when justification for action is absent12.  
This rule is enforced through validator framing and exchange contracts that require agents to respect local claim boundaries4. If a host website's data is ambiguous, if the requested task requires the agent to step outside its authorized capabilities, or if a cross-domain authority conflict arises, the UAIX standard explicitly instructs the agent to halt execution, log a no-op decision, and trigger a request for human review12.  
The operational mechanics of the no-op rule derive directly from the Teleodynamic theory of the Work-Constraint Cycle and the endogenous resource economy, quantified as ![][image1]14. The framework postulates that any structural growth, cognitive action, or semantic distinction generated by an AI agent incurs a measurable maintenance burden14. This burden consists of explicit computational costs, memory storage requirements, human review overhead, and the systemic pressure of uncertainty14.  
Within a UAIX-compliant system, the operator library defines five core actions: split, merge, add, retire, and no-op16. The agent actively tracks its ![][image1] resource budget against a predefined viability floor14. When evaluating a potential structural edit—such as adding a new conceptual category or executing a complex data handoff—the agent must calculate whether the predictive gain of that action repays its maintenance cost14. If the cost exceeds the benefit, or if the system's ![][image1] reserves fall below the viability floor, the system enters a state of "blocked growth"14. Under these conditions, the standard dictates that the agent must refuse the structural growth, preserve its current audit logs, and execute a no-op14.  
By making cost an internal, endogenous variable tracked continuously by the agent, the system natively resists runaway complexity, meaningless feature accumulation, and chaotic oscillation8. The no-op decision is not recorded as a system failure or an execution error; rather, it is formally documented as an active, resource-conserving decision that maintains the system's operational viability8.  
Agents are explicitly programmed to execute a no-op and request human review under the following strict conditions: