AINCS AI-Native Application Framework (XANAF) v1.0

1. Overview

1.1 Introduction

AI is increasingly embedded in applications, yet most systems still treat AI as an afterthought—a bolt-on feature rather than a first-class participant. Current AI integration methods rely on patched-together APIs, manual data extraction, and UI-bound state, forcing AI to interact in ways fundamentally different from human users.

This fragmented approach introduces severe inefficiencies:

These inefficiencies create technical debt, fragmented execution models, and AI that remains dependent on human oversight.

XANAF (AINCS AI-Native Application Framework) solves this by providing a unified standard where AI and human users interact seamlessly, identically, and predictably.

1.2 Why XANAF?

AI integration today is fragmented—applications rely on separate APIs, human-readable state, and predefined interactions that require AI to be manually adapted per system. These inefficiencies create technical debt, inconsistent execution models, and limited AI autonomy.

XANAF eliminates the inefficiencies of retrofitting AI into traditional application architecture by enforcing:

With XANAF, applications become AI-native by design, allowing AI agents to function autonomously without pre-training, special APIs, or workarounds.

Comparison to Traditional AI Integration

Execution Path

State Exposure

AI Input

Training

1.3 Core Capabilities & Architectural Approach

XANAF enforces an AI-Native execution model by standardizing how applications expose state, accept input, and handle execution feedback. XANAF assumes that AI agents begin with no prior knowledge of application structure or semantics. All valid commands must be discoverable from system state, with no hidden pathways or special instructions assumed.

1.3.1 Event-Driven Execution Model

1.3.2 Unified Input & State Management

1.3.3 Dynamic Input Discovery

1.3.4 Explicit Execution Feedback

1.3.5 Separation of UI & Business Logic

2. Unified Input Pipeline (AI and Human Input Must Be Identical)

XANAF mandates a single, structured input pipeline where AI and human users interact through the same execution model, input structures, and validation constraints.

This requirement is essential to AINCS (AI-Native Computing Standard) because:

AI-specific input pathways, hidden execution channels, or UI-driven adaptations are strictly prohibited, as they break AI-human parity, introduce inconsistencies, and violate the foundational principles of AINCS.

2.1 Mandatory Input Channels

2.1.1 Standard Command Execution Channel

All user interactions—whether initiated by AI or human users—must be processed through a standardized command execution model with the following characteristics:

2.1.2 Additional Input Channels (Extensible, Application-Specific)

While command execution is the primary required input channel, applications may support additional structured input methods as needed, provided that:

Example extensible input models include:

These additional models are optional but must always conform to XANAF’s unified input requirements if implemented.

2.2 Prohibited Input Models

To ensure full AI-human parity, XANAF explicitly prohibits any input models that introduce segregated execution pathways or require AI-specific adaptations.

No AI-Specific Endpoints

No UI-Bound Input Models for AI

No Hidden Execution Pathways

2.3 Standardized Command Structure

XANAF enforces a structured command format to guarantee deterministic execution and prevent AI-human input discrepancies.

2.3.1 Explicit Command Definitions

Every command must be fully self-describing, ensuring AI can issue valid actions without relying on external documentation, predefined mappings, or implicit system rules. Each command must include:

AI must construct commands using only the structured input schema provided by the system—it must not rely on undocumented behaviors, inferred execution rules, or hidden system constraints.

2.3.2 Identical Execution Path for AI and Humans

2.3.3 Compliance & Validation

To be XANAF-compliant, an application must:

3. State Exposure

3.1 State Must Be Structured and Machine-Readable

XANAF requires that all application state be structured in a way that AI can interpret directly, without relying on human-readable formats, UI elements, or unstructured text.

Any system exposing state in UI-bound, human-readable, or inconsistent formats is not compliant with XANAF.

3.2 Required State Components

While XANAF does not enforce a specific format, it does require that state include the following structured components to support AI-native operation:

State must include these components in a structured and consistent manner to ensure AI does not require human-like inference, pre-defined mappings, or UI workarounds to function. If any of these components are missing or ambiguous, AI cannot reliably function autonomously, and the system is not AI-native.

3.3 No UI-Centric Data Allowed

To ensure state is fully consumable by AI, XANAF prohibits:

Examples of Non-Compliant State Exposure

Examples of Compliant State Exposure

Any system that fails to meet these requirements cannot be considered AI-native under XANAF.

4. Discoverability of Input Pathways

4.1 The Two-Model Approach

XANAF defines two distinct models for exposing state and available actions, ensuring AI agents can interpret and act upon system state without ambiguity. These models cover the full range of AI-Native applications:

  1. Schema-Defined Model → For structured, CRUD-like applications.
  2. Direct-Action Model → For highly dynamic, emergent AI interactions.

By supporting both models, XANAF remains flexible while enforcing strict clarity in AI-readable state exposure. Every AI-native system must adhere to one or both models, depending on its needs.

XANAF does not dictate AI behavior but assumes AI can process structured input without prior training. The system is responsible for ensuring that all valid interactions are surfaced in a machine-readable format, allowing AI to determine available actions dynamically based on exposed state.

4.2 Schema-Defined Model

Purpose

The Schema-Defined Model is designed for applications where data follows a structured format and predictable execution patterns. This model is best suited for:

The Schema-Defined Model requires that all entity definitions conform to a structured validation format. JSON Schema is the recommended standard, but equivalent structured validation frameworks may be used, provided they enforce explicit constraints, data types, and required fields in a machine-readable manner.

Core Principles

Implementation

Command Format

Actions

Example:
An AI assistant submitting structured data into a system follows predefined schemas for entity types.

{
  "entities": [
    {
      "type": "sprocket",
      "schema": {
        "$schema": "https://json-schema.org/draft/2020-12/schema",
        "type": "object",
        "properties": {
          "name": { "type": "string", "minLength": 3, "maxLength": 50 },
          "description": { "type": "string", "maxLength": 255 }
        },
        "required": ["name"]
      },
      "data": [
        {
          "id": "12345",
          "name": "Example Sprocket",
          "description": "A high-quality example sprocket, built for AI-native systems."
        }
      ],
      "actions": [
        {
          "label": "Submit",
          "command": "create sprocket {\"name\": \"{name}\", \"description\": \"{description}\"}",
          "actionHints": [
            "User must have edit permissions.",
            "Sprocket name cannot be empty."
          ]
        }
      ]
    }
  ]
}

4.3 Direct-Action Model

Purpose

The Direct-Action Model is designed for real-time, dynamic environments where AI interactions emerge based on evolving conditions. This model is best suited for:

This model enables AI to interpret and respond to state changes fluidly, without the overhead of predefined schemas.

Important: If parameter constraints are required, the Schema-Defined Model must be used. The Direct-Action Model assumes AI will infer constraints dynamically based on system feedback.

Core Principles

Implementation

Command Format

Example:
In a game world, AI sees “take i|abc123” attached to an item, instantly knowing it can pick it up.

{
  "entities": {
    "data": [
      {
        "title": "Enchanted Flask",
        "description": "A mystical flask shimmering with an eerie glow.",
        "commands": [
          "take i|abc123",
          "use i|abc123"
        ]
      }
    ]
  }
}

Command Processing

XANAF-compliant applications must process AI-issued commands in a structured, predictable, and reliable manner. While XANAF does not enforce a specific transport or execution model, it strongly recommends implementing command execution using the AINCS Smart Live Agent Protocol (XSLAP).

XSLAP provides a proven framework for structured command execution, tracking, and feedback, ensuring AI agents can:

Minimum Command Processing Requirements

Regardless of implementation, all XANAF-compliant applications must adhere to the following core principles in command execution:

By enforcing explicit success and failure feedback, XANAF guarantees that AI agents can operate autonomously without relying on human-designed workarounds or manual intervention. Systems that fail to comply introduce unnecessary ambiguity, making them AI-retrofitted, not AI-native.

4.4 Meta Actions (Global Action List)

While most commands in XANAF are contextual to entities (e.g., actions tied to a specific item or user), applications may also expose global or meta-level commands that are not bound to any one entity.

These actions typically affect the overall session, environment, or application state and may include behaviors like:

Key Properties:

This pattern ensures that AI agents receive a complete, machine-readable menu of valid interactions, including commands that operate beyond individual entities. By placing meta actions at the root level, applications maintain clarity, simplicity, and discoverability across all models.

{
  "actions": [
    {
      "label": "Refresh the Application State. This is your 'turn it off and back on again' command.",
      "command": "GetState"
    },
    {
      "label": "Change Theme",
      "command": "set theme {\"mode\": \"{dark|light}\"}"
    }
  ],
  "entities": [
    {
      "type": "user",
      "data": [
        {
          "id": "u123",
          "name": "Alice",
          "actions": [
            {
              "label": "Update Profile",
              "command": "edit profile {\"name\": \"{name}\"}"
            }
          ]
        }
      ]
    }
  ]
}

While XANAF does not mandate any specific commands, it is considered best practice for applications to expose a discoverable command that performs a full state refresh. This action is commonly referred to as GetState.

Purpose

AI agents operating in long-lived sessions or dynamic environments may occasionally require a reset of their internal state to reestablish context. A full-state refresh allows them to:

Recommendations

Example Implementations

4.6 Stale-State Detection (Optional Best Practice)

To ensure AI agents do not act on outdated information, applications may optionally implement stale-state validation during command execution. This is especially useful in multi-user or real-time systems where state changes frequently.

Overview

When an AI issues a command, the system compares the agent’s last known state version received (tracked by the application) to the current system version. If a mismatch is detected, the command is rejected, and an updated state is pushed to the AI for reevaluation.

Why It Matters

Implementation Recommendations

5. Conclusion

XANAF establishes the foundational principles for AI-Native application design, ensuring that AI agents can interact with systems as first-class participants, without the inefficiencies of legacy integration approaches.

By enforcing structured state exposure, unified input pathways, and explicit execution feedback, XANAF eliminates ambiguity, reduces technical debt, and creates an environment where AI can function autonomously without pre-training, custom integrations, or human-designed workarounds.