AiNxt OS

One Intelligence. Works for Everyone.

AiNxt brings intelligence into enterprise work, development environments, command-line workflows, and the foundations used to build new AI experiences. This repository is AiNxt OS — the foundation you build your own AI applications, agents and workflows on.

An initiative of NPCI — National Payments Corporation of India.

_{Four layers, read top-down: you build (your interface · domain logic · data) → OS primitives (agents · workflows · tools · memory · eval) → inherited platform (identity & access · guardrails · observability · retrieval) → models — BYOM (hosted providers · self-hosted open weights · offline).}

No Rust, no build — download the prebuilt binary:

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/npci/ainxt-os/main/install.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/npci/ainxt-os/main/install.ps1 | iex

Windows with Git Bash / MSYS2: use the curl | bash form above.

The installer detects your OS and architecture (macOS, Linux, Windows — arm64 and x86_64), downloads ainxt-os and ainxt-runtimed for your platform, places them in ~/.ainxt-os/bin/, and adds that to your PATH. Open a new terminal after install, then:

ainxt-os        # macOS / Linux / Git Bash
ainxt-os.exe    # Windows cmd / PowerShell

That starts AiNxt OS and opens a chat window at http://127.0.0.1:8081. No database, no message broker, no model provider, no API key.

Two binaries, one command. ainxt-os is the Console — the browser UI and settings page you interact with. It starts and manages ainxt-runtimed for you automatically. ainxt-runtimed is the runtime — the governed HTTP engine that every AI turn passes through. You only ever run ainxt-os; it takes care of ainxt-runtimed.

No Rust, no build — download the prebuilt binary:

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/npci/ainxt-os/main/install.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/npci/ainxt-os/main/install.ps1 | iex

Windows with Git Bash / MSYS2: use the curl | bash form above.

The installer detects your OS and architecture (macOS, Linux, Windows — arm64 and x86_64), downloads ainxt-os and ainxt-runtimed for your platform, places them in ~/.ainxt-os/bin/, and adds that to your PATH. Open a new terminal after install, then:

ainxt-os        # macOS / Linux / Git Bash
ainxt-os.exe    # Windows cmd / PowerShell

That starts AiNxt OS and opens a chat window at http://127.0.0.1:8081. No database, no message broker, no model provider, no API key.

Two binaries, one command.

ainxt-os is the Console — the browser UI and settings page you interact with. It starts and manages ainxt-runtimed for you automatically.

ainxt-runtimed is the runtime — the governed HTTP engine that every AI turn passes through. You only ever run ainxt-os; it takes care of ainxt-runtimed.

Pin a specific version (replace 0.2.0 with the version you want):

curl -fsSL https://raw.githubusercontent.com/npci/ainxt-os/main/install.sh | bash -s 0.2.0

Build from source instead (Rust 1.94+, ~2 GB disk):

git clone https://github.com/npci/ainxt-os.git && cd ainxt-os && ./setup.sh --run

./setup.sh --run builds both binaries, writes a config, validates it, and opens the Console. Run it from inside the cloned ainxt-os/ directory. On Windows, use Git Bash or WSL2 to run setup.sh.

Your first reply will be offline mode: no model configured. That is the point: the whole governed path — identity, session, compliance gate, authorisation, streaming, audit record — ran end to end without a model attached. Connect one in Settings when you want real answers.

→ Step-by-step: Your first 10 minutes

No model is required to start — the runtime serves offline by default so the entire governed path is exercised first. When you are ready for real answers, three ways to connect a provider — pick one:

Open the Console at http://127.0.0.1:8081, go to Settings, and fill in the provider and API key. The Console validates the config with ainxt-runtimed --check before saving — a bad key never leaves a broken config behind.

Set the key before starting the runtime. The Console picks it up automatically.

Anthropic

export ANTHROPIC_API_KEY=sk-ant-...
ainxt-os                  # if installed via curl
# or, if built from source:
./setup.sh --run

OpenAI

export OPENAI_API_KEY=sk-...
ainxt-os                  # if installed via curl
# or, if built from source:
./setup.sh --run

Ollama (local, no key)

# Start Ollama first: ollama serve
ainxt-os                  # if installed via curl
# or, if built from source:
./setup.sh --run
# Then in Settings, set provider to Ollama at http://localhost:11434

Add a [[models.providers]] block to your runtimed.toml:

Anthropic / Claude

[[models.providers]]
id          = "claude"
kind        = "anthropic"
model       = "claude-sonnet-4-6"
api_key_env = "ANTHROPIC_API_KEY"

OpenAI / GPT

[[models.providers]]
id          = "gpt"
kind        = "openai_schema"
model       = "gpt-4o"
base_url    = "https://api.openai.com/v1"
api_key_env = "OPENAI_API_KEY"

Ollama / any OpenAI-compatible endpoint (local, free, no key)

[[models.providers]]
id       = "local"
kind     = "openai_schema"
model    = "llama3.2:latest"
base_url = "http://localhost:11434/v1"

Validate before serving:

AINXT_TRUSTED_GATEWAY=1 ./target/release/ainxt-runtimed --config runtimed.toml --check

Provider kinds: anthropic → Anthropic Messages API · openai_schema → OpenAI-compatible /v1/chat/completions — works with any provider: OpenAI, Ollama, vLLM, LM Studio, Groq, Together AI, Mistral, Azure OpenAI, and any self-hosted or proxy endpoint · gemini → Google Gemini · local → offline (no model)

AiNxt is four products sharing one intelligence layer. This repository is AiNxt OS.

None of them is a satellite of another: they are peers on a shared foundation.

Are the four products the same product? No. AiNxt Suite is the umbrella; each product addresses a different way of working with AI.

Is AiNxt OS the user interface for AiNxt Enterprise? No — they are distinct products. AiNxt OS is a foundation for building AI experiences; AiNxt Enterprise is an enterprise-facing experience across web and desktop. Neither requires the other.

Where do I find the other repositories? Each product has its own, and each README is that product's documentation:

AiNxt OS is the open-source governed AI runtime for enterprises. Every question it answers passes through the same path: who are you, what are you allowed to see, what did the model actually do — and each of those gates fails closed. Provider-agnostic, data-residency-aware, agentic, and governed by default rather than by configuration.

For an individual — build and customise AI experiences for the way you work, from specialised assistants and agents to workflows that automate recurring tasks.

For an organisation — give teams a common foundation for creating AI capabilities tailored to their domains, processes and business needs.

AiNxt OS is the only product in the suite you build on rather than use.

There are two ways in, and you do not have to choose up front:

The Console is a real front end, not a demo: it is the reference implementation of the authenticating-gateway contract in DOCKING.md, which is exactly what AiNxt OS requires of anything a browser can reach. Use it to evaluate AiNxt OS on day one, and keep using it as an operator's window after you have built your own product on top.

AiNxt OS ships as two binaries:

• ainxt-runtimed — the runtime itself. A single Rust binary that answers a governed AI turn over HTTP: you POST a chat turn and read a Server-Sent-Events stream back. This is the component every client docks into, and the thing you deploy.
• ainxt-os — the Console. Starts the runtime for you, serves a chat window, and turns the configuration into a settings page. This is the thing a person runs.

The point of the runtime is the part between the request and the stream. A turn does not go straight to a model: it passes through an authenticator, a session manager, a compliance gate, an authorizer, a model router and an audit sink, and each of those fails closed. AiNxt OS refuses to start if you have not chosen how identity is established. It refuses a turn whose caller lacks the capability. It records what it did whether or not the model answered.

That is the whole design: the governance is not middleware you can forget to install, it is the only path a turn can take.

It runs on its own. No database, no message broker, no model provider and no API key are needed to start. With no provider configured it serves an offline provider, so the socket always answers and you can exercise the entire path before you commit to any infrastructure. A model is something you connect when you are ready — from the Console's Settings page, or in a config file.

The dashed layer is yours. Everything below it you inherit — you do not implement identity, guardrails, observability or retrieval yourself.

flowchart TD
    subgraph YOURS["01 · You build"]
        UI["Your interface<br/>web · desktop · mobile · headless — it does not have to look like AiNxt"]
        DL["Your domain logic<br/>the rules and vocabulary of your business"]
        DATA["Your data<br/>your systems of record stay yours"]
    end
    subgraph PRIM["02 · OS primitives — you compose these"]
        AG["Agents<br/>specialised intelligence, defined tools, defined limits"]
        WF["Workflows<br/>repeatable multi-step work you can review"]
        TC["Tools and connectors<br/>governed access to enterprise systems"]
        MEM["Memory and context<br/>what an agent knows, and for how long"]
        EV["Eval<br/>measure behaviour instead of assuming it"]
    end
    subgraph INH["03 · Inherited platform — governed by default"]
        ID["Identity and access<br/>SSO and role-based scoping"]
        GR["Guardrails<br/>injection defence and compliance you do not implement"]
        OB["Observability<br/>traces, quality signals, latency, cost"]
        RT["Retrieval<br/>hybrid search over enterprise knowledge and code"]
    end
    MOD["04 · Models — BYOM<br/>model router · hosted providers · self-hosted open weights"]

    YOURS --> PRIM --> INH --> MOD

    classDef yours fill:#ffffff,stroke:#1b3281,stroke-width:2px,stroke-dasharray:6 4,color:#1b3281;
    classDef prim fill:#1b3281,stroke:#0f1f52,color:#ffffff;
    classDef inh fill:#f27b21,stroke:#c25d10,color:#ffffff;
    class UI,DL,DATA yours;
    class AG,WF,TC,MEM,EV prim;
    class ID,GR,OB,RT inh;

The experience does not have to look like AiNxt Enterprise. The same foundation can power purpose-built products for different domains and users.

AiNxt OS is provider-agnostic by construction: the runtime holds a Provider trait and the model is a configuration entry, not a code path.

Choose per use case and swap without rewriting. Configuration reference: runtimed.example.toml, validated by ainxt-runtimed --check.

Scope, stated plainly: the provider enum is closed — openai_schema, anthropic, gemini, local. There is no AWS Bedrock or Vertex AI adapter; both need an OpenAI-schema proxy in front.

65 crates. This is the path a single /v1/chat turn takes:

flowchart TB
    C["<b>The Console</b> (ainxt-os :8081)<br/>or your own front end<br/><i>gateway, UI, CLI, IDE</i>"]

    subgraph D["ainxt-runtimed  ·  one process  ·  :8080"]
        direction TB
        A["<b>Authenticator</b><br/>trusted-gateway or jwt-sso<br/><i>refuses to start unless you choose</i>"]
        S["<b>Session manager</b><br/>concurrency, backpressure, turn timeouts"]
        G["<b>Mandatory gates</b><br/>compliance · authz · audit<br/><i>selectable, never 'none'</i>"]
        SU["<b>Chat surface</b><br/>intent, referent resolution, retrieval, prompt assembly"]
        R["<b>Model router</b><br/>tier routing, eligibility, circuit breaker"]
        T["<b>Tool runtime</b><br/>one capability registry<br/>native · MCP · plugin · connector"]
        P["<b>Provider chain</b><br/><i>offline by default</i>"]
    end

    L[("Ledger · Event log<br/>Incident register<br/>Retention store")]
    M["Model provider<br/><i>Ollama, vLLM, OpenAI, …</i>"]
    X["Connectors<br/><i>GitLab, Jira, Graph</i>"]

    C -->|"POST /v1/chat"| A --> S --> G --> SU
    SU --> R --> P --> M
    SU --> T --> X
    G -.->|"every decision"| L
    T -.->|"exactly-once"| L
    P -->|"SSE stream"| C

    classDef gate fill:#fde,stroke:#b46
    class A,G gate

A refusal arrives inside the SSE stream as an error frame, with HTTP 200. The transport succeeded; the turn was declined. Treating HTTP 200 as success is the most common mistake when docking a new client — see DOCKING.md for the full wire contract.

Your first 10 minutes. Three commands to a running runtime with a chat window — no database, no model provider, no API key.

git clone https://github.com/npci/ainxt-os.git
cd ainxt-os
./setup.sh

You need: Rust 1.94+, a working cc, ~2 GB disk, and network for the first build (299 crates from crates.io). macOS, Linux, and Windows (use Git Bash or WSL2 to run setup.sh). Full detail in Prerequisites.

./setup.sh verifies Rust, a C toolchain and free disk, builds AiNxt OS and its Console, creates runtimed.toml from the shipped example, validates the configuration, and prints exactly what to run next. It is safe to re-run, and ./setup.sh --check inspects prerequisites without changing anything.

./setup.sh --run            # or, once built:  ./target/release/ainxt-os

That starts AiNxt OS, opens http://127.0.0.1:8081 in your browser, and gives you a chat window, a settings page, and the runtime's startup report. Nothing else to install — no Node, no npm, no database, no model provider, no API key.

Your first reply will be offline mode: no model configured. That is correct, and it is not a failure: it means the whole path — identity, session, compliance gate, authorisation, streaming and the audit record — ran end to end without a model attached. Connect one in Settings when you want real answers.

Connect a provider in Settings for real answers — see BYOM.

If you are integrating instead of evaluating, run the runtime directly:

AINXT_TRUSTED_GATEWAY=1 ./target/release/ainxt-runtimed --config runtimed.toml

The rest of this section explains each step, for when you need to change one.

No database, message broker, model provider or API key is required to start. With no provider configured the runtime serves an offline provider so the socket always answers.

cargo build --release -p ainxt-runtimed

A commented example configuration ships in the repository:

cp crates/ainxt-runtimed/config/runtimed.example.toml runtimed.toml

Configuration is layered: pass --config more than once and each later file is deep-merged over the earlier ones (defaults → deployment → tenant). [server] and [session] are consumed by the daemon; everything else is the runtime configuration.

Read this before you conclude a provider is broken. Declaring a cloud provider is not sufficient to make it routable. AiNxt OS installs an RBI outsourcing register as a non-overridable, fail-closed eligibility input: only routes with a board-approved outsourcing arrangement on record — plus signed on-prem/offline exemptions — may receive a turn. Everything else is excluded, and a turn refused this way reports:

"category":"provider_unavailable","message":"no eligible route: NoEligible(Public)"

This is deliberate. A regulated financial entity may not send data to an external service provider without a recorded arrangement, and the runtime enforces that rather than trusting configuration. Register one before routing to a cloud provider:

curl -X POST http://127.0.0.1:8080/admin/outsourcing/register \
  -H 'content-type: application/json' \
  -H 'X-AInxt-User: dpo' -H 'X-AInxt-Role: admin' \
  -H 'X-AInxt-Department: compliance' -H 'X-AInxt-Clearance: confidential' \
  -d '{"id":"outsourcing.cloud.<provider-id>","provider_legal_entity":"…",
       "permitted_data_class":"public","data_residency":"in","exit_plan_ref":"…",
       "concentration_tag":"…","contract_ref":"…","board_approval_ref":"…",
       "right_to_audit_clause":"…"}'

The route id is "outsourcing.cloud." + <the provider's configured id>. The register is held in memory, so it must be re-registered after a restart — persist it in your deployment automation. Full model: docs/governance_compliance/responsible_ai_outsourcing.md.

Adopters outside India: residency defaults to 'in' and the exemption list is India-shaped. Like the settlement perimeter described below, these are behaviour-affecting jurisdictional defaults you will want to change — not branding.

data_residency must satisfy the router's residency requirement. The shipped router runs with residency='in'; an arrangement registered with a different residency stays ineligible, and the turn is refused with the message above rather than routed. Register with the residency your deployment's register actually requires.

The default authenticator is trusted-gateway, which derives role, capabilities and clearance from client-supplied X-AInxt-* headers. That is only safe when the runtime is unreachable except through a gateway that has already validated the caller's token, so the daemon refuses to start rather than silently trusting whatever the client asserts. Pick one:

# (a) You front the runtime with your own authenticating gateway.
#     Only use this when the listener is NOT reachable directly by a browser.
export AINXT_TRUSTED_GATEWAY=1

# (b) The runtime verifies identity itself. In your config:
[server]
authenticator = "jwt-sso"
jwt_hs256_secret = "…"        # required and non-empty, or assembly fails closed

curl -i http://127.0.0.1:8080/healthz     # → 200  {"status":"ok"}
curl -i http://127.0.0.1:8080/readyz      # → 200  {"status":"ready"}

These are the only two routes that do not pass through the identity gate — deliberately, because a load balancer, a Kubernetes kubelet or a supervising process has no token and cannot be given one. Both are safe to leave open because they are inert: they return a fixed body from a closed vocabulary, so an unauthenticated caller learns nothing beyond whether to route here. HEAD works.

They are not interchangeable, and the difference is the remedy:

Wiring /healthz to a dependency check is a classic outage amplifier: if AiNxt OS reported itself unhealthy because its audit disk filled, Kubernetes would kill and restart it — which cannot fix a full disk, so a recoverable condition becomes a crash loop.

/healthz is liveness. A 200 is worth more than a TCP connect: the route exists only on a fully assembled router, so it distinguishes "composed and able to serve" from "a socket is bound", which is all a port probe tells you.

/readyz is readiness, and it checks exactly one thing — whether the durable audit sink accepted its last real write. That is chosen because it is the one condition that makes every turn fail: audit is a mandatory, fail-closed gate, so a sink that cannot write means every governed turn is refused. The signal comes from real appends, never a synthetic probe write, because appending to a tamper-evident audit chain on every load-balancer poll would corrupt the artefact it protects.

It deliberately does not check:

• The model provider — no outbound call. Probes run every few seconds forever; dialling a paid API on each is a cost and rate-limit incident waiting to happen. It is also the wrong signal: AiNxt OS is designed to serve an offline provider, so "no model" is a supported posture.
• Session capacity — the session manager already sheds load with a 503 on a full inbox, which is the correct immediate backpressure. Reporting saturation here too would drop every instance out of rotation at once under a spike, turning a slowdown into an outage.

AINXT_TRUSTED_GATEWAY=1 ./target/release/ainxt-runtimed --config runtimed.toml --check

--check assembles everything, prints a report of what was wired (and what was deliberately left unwired), and exits. Expect config OK (--check) — not serving and exit status 0. Read the report — it names each subsystem that is live versus deployment-owned.

AINXT_TRUSTED_GATEWAY=1 ./target/release/ainxt-runtimed --config runtimed.toml
# → ainxt-runtimed: listening on http://127.0.0.1:8080 (fully-wired: /v1/chat /v1/command
#   /v1/replay /v1/events /v1/observe /graph /v1/query_ledger /v1/infer /v1/harness/*
#   /connectors/* /v1/artifact /v1/replay/step)

Useful flags: --config <file> (repeatable), --port <n>, --surface chat|engine, --check. chat serves the full conversation intelligence (intent cascade, referent resolution, prompt engine) behind the compliance gate; engine serves a bare model turn behind the same mandatory gates.

Under trusted-gateway the runtime takes identity from the X-AInxt-* headers — that is what the mode means — so the request has to carry them. In a real deployment your gateway sets these after validating the caller's token; here you are standing in for that gateway:

curl -N http://127.0.0.1:8080/v1/chat \
  -H 'content-type: application/json' \
  -H 'X-AInxt-User: alice' \
  -H 'X-AInxt-Role: engineer' \
  -H 'X-AInxt-Department: engineering' \
  -H 'X-AInxt-Caps: chat.send' \
  -H 'X-AInxt-Clearance: public' \
  -d '{"session":"c1","turn":"t1","input":"hello","data_class":"public"}'

You should get HTTP 200 and an SSE stream whose frames carry a type discriminator:

id: 1
data: {"v":"1.0","session_id":"c1","turn_id":"t1","seq":1,…,"type":"turn.started",…}

id: 2
data: {"v":"1.0",…,"type":"text.delta","text":"offline mode: no model configured."}

id: 4
data: {"v":"1.0",…,"type":"turn.completed","outcome":"complete"}

offline mode: no model configured is the expected first-run output — it proves the whole transport, session, gate and streaming path works without any provider credential. To use a real model, set ANTHROPIC_API_KEY / OPENAI_API_KEY, or add a [[models.providers]] config layer.

Full request/response contract, the event vocabulary, and worked examples for docking a Python gateway or a React UI: DOCKING.md.

cargo test --workspace

ainxt-os is the thin layer over AiNxt OS: one binary, one command, a chat window in a browser. It exists so that evaluating AiNxt OS, connecting a model, and changing a setting do not require reading TOML or holding a curl invocation in your head.

./target/release/ainxt-os

It starts AiNxt OS as a child process, waits for GET /healthz to answer, and serves the Console on http://127.0.0.1:8081. Stopping the Console stops AiNxt OS with it — Ctrl-C (SIGINT) and pkill ainxt-os (SIGTERM) are both handled, and the child is reaped before the Console exits — so you never leave an orphaned daemon holding port 8080.

This is the important part, and it is a security property rather than an implementation detail.

AiNxt OS's default identity posture, trusted-gateway, derives role, capabilities and clearance from client-supplied X-AInxt-* headers. That is safe only behind something that has already authenticated the caller — which is why the daemon refuses to start until you assert the posture deliberately. A web page served on :8080 under that posture could simply send X-AInxt-Role: admin and be believed.

So the Console does the job the architecture already requires of a front end: it is the authenticating gateway. It decides who the operator is, runs AiNxt OS in jwt-sso mode with a secret generated fresh at every start, and signs a short-lived token per request. The browser never holds the secret and never asserts an identity.

  browser  ──►  ainxt-os (Console, :8081)  ──►  ainxt-runtimed (AiNxt OS, :8080)
  no identity     mints a signed token           jwt-sso: believes only the token

Both listeners bind 127.0.0.1 only. With the Console running, the four obvious attacks on the runtime are all rejected with 401: self-asserted X-AInxt-Role: admin, no credentials at all, an alg:none signature-strip, and a correctly-shaped token signed with the wrong secret.

Can: the model provider and its endpoint or API key; whether answers are grounded in your documents (RAG); whether conversations survive a restart; the five guardrail rails and the prompt-injection mode (off / audit / enforce); the port.

Cannot: the mandatory gates. [gates] compliance, authz and audit are the guarantee AiNxt OS exists to provide and can never be set to none; the Console shows them read-only. Changing them is a deployment decision made in a config file with a review, not from a chat window.

Every save is checked by the daemon itself — the Console writes a staged copy, runs ainxt-runtimed --check against it, and only replaces your runtimed.toml if that passes. A rejected change never leaves a broken config behind, and the daemon's own error message is what you see. Your file's comments are preserved: the Console edits the document in place rather than regenerating it.

.ainxt-console/ next to your config (gitignored):

Credentials never enter runtimed.toml. AiNxt OS reads provider keys from the environment, so the Console holds them in its own 0600 file and injects them when it starts the daemon. That keeps secrets out of the file you are most likely to paste into a support ticket.

It is not a multi-user application. It asserts a single local operator identity and binds loopback, which is right for evaluation, local use and operations — and wrong for serving a team. For that, build your own front end against DOCKING.md, or put AiNxt OS behind a gateway that performs real authentication. The Console is the reference for how such a gateway should behave, and deliberately small enough to read in one sitting.

AiNxt is published as four separate repositories. They are not a monorepo and you do not need all of them — but they do have a required order, and picking the wrong starting point is the most common way to get stuck.

You are here: ainxt-os — the Runtime. It is the one component that also runs perfectly well on its own.

flowchart TB
    CODE["<b>ainxt-code</b><br/>IDE plugins<br/><i>VS Code · IntelliJ</i>"]
    CLI["<b>ainxt-cli</b><br/>terminal agent<br/><i>TUI and headless</i>"]
    M["Model provider<br/><i>Anthropic · OpenAI · Ollama · vLLM · …</i>"]

    PLAT["<b>ainxt-enterprise</b>  —  AiNxt Platform (optional)<br/>FastAPI · :8000 · React UI :5173<br/><i>/ainxt/v1/api/* · /v1/chat/completions</i>"]

    RT["<b>ainxt-os</b>  —  AiNxt OS<br/>ainxt-runtimed · :8080<br/><i>optional sidecar</i>"]

    DB[("PostgreSQL + Redis<br/><i>only needed by the Platform</i>")]

    CODE -->|"direct, by default"| M
    CLI -->|"direct, by default"| M
    CODE -.->|"optional: governed access"| PLAT
    CLI -.->|"optional: governed access"| PLAT
    PLAT --> DB
    PLAT -.->|"RUNTIME_URL"| RT

    classDef opt stroke-dasharray: 4 3
    class PLAT,RT,DB opt

The one dependency you cannot skip: at least one model provider somewhere. Nothing in this suite bundles a model. PostgreSQL and Redis are only needed if you additionally choose to run the Platform.

A note on ports. The Platform binds 8000 by default and ainxt-runtimed binds 8080. If a client reports "gateway not reachable", check the port first.

Everything is in this repository; there is no external docs site.

📚 Full documentation — 251 pages across 7 subject areas. Best read in the browser: open docs/index.html — it works offline, no server needed.

Configuration reference lives with the code: run ainxt-runtimed --check to validate a config file without serving, and see crates/ainxt-surface/profiles/ for the surface presets.

Stated plainly, because building on a placeholder is worse than knowing it is one.

Implemented and exercised by tests: the turn engine and its mandatory gates; the tool runtime; the session manager; connectors; surface profiles; the Rust client SDK and headless CLI; the extensibility seams; the ainxt-runtimed composition binary; a durable file-backed token store; and a SHA-256 hash-chained, tamper-evident event log; and the Console (ainxt-os) — the shipped authenticating-gateway front end. 65 crates in the workspace, 6 binaries.

Design-only or placeholder — do not rely on these yet: the eval platform; durable Postgres/Redis backing for most seams; the real PCI/DSS detector (the OSS default is a labelled placeholder); RAG / context fabric; memory and learning; agent teams; serving-ops; MCP; the WASM sandbox; and the Python and TypeScript SDKs.

The shipped settlement perimeter is India-centric by default. SettlementPerimeter::default_reserved() reserves national payment-rail destination patterns (upi-settlement., neft.rbi, rtgs.rbi, nach.npci, and the 2026 agent-payment-protocol networks). These are behaviour-affecting domain data for a settlement guardrail, not branding, and they are overridable — see SettlementPerimeter::empty(), reserve(), and SettlementPolicy.perimeter_patterns. An adopter outside India must supply their own patterns; the shipped list will not recognise their rails.

The MIT License (see LICENSE) covers this runtime project. It does not cover enterprise plugins (compliance rule packs, directory/RBAC integration, IP-bearing connectors), which may be developed separately and are never part of this OSS tree.

• License — LICENSE (MIT). NOTICE is retained for third-party attribution and the trademark reservation; MIT does not itself require a NOTICE file
• Dependency-license policy, enforced by cargo-deny — deny.toml
• Third-party inventory — THIRD_PARTY_INVENTORY.yaml, THIRD_PARTY_NOTICES.md, THIRD_PARTY_LICENSES.md
• Model weights — none are distributed in this tree, so there is no weight-licensing register
• Software Bill of Materials — not yet published. THIRD_PARTY_INVENTORY.yaml is the dependency inventory this tree actually ships; a machine-readable SBOM (CycloneDX/SPDX) is still outstanding.

Cargo.lock is committed: this is an application workspace, and a reproducible dependency set is part of the licence and supply-chain posture. Do not remove it.

Contributions are not open yet. Published under the MIT License as source-available; external pull requests and issues are not currently accepted or triaged. Security vulnerabilities are the exception and may be reported privately at any time.

• CONTRIBUTING.md — the posture, and the workflow the maintaining team follows (including DCO sign-off)
• CODE_OF_CONDUCT.md
• GOVERNANCE.md, MAINTAINERS.md, CODEOWNERS
• SECURITY.md — report vulnerabilities privately, never as a public issue

AiNxt is an independently engineered platform. External open-source projects were studied as references only; no source code, identifiers, prompts, comments, file layouts, or terminology were copied.

The architecture corpus and decision records (ADRs) that document this design process are not published in this repository. Statements about clean-room provenance therefore cannot be verified from this tree alone.

Licensed under the MIT License. The full text is in LICENSE.

The software is provided "AS IS", WITHOUT WARRANTY OF ANY KIND, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability arising from, out of or in connection with the software or its use. See LICENSE for the governing text.