ICNLI¶

The Open Protocol for Modular Proactive AI Cloud Operating Systems¶

ICNLI v2.0 (current specification, May 2026) · first created 30 December 2025 as v1.0.0 · next deliverable v2.1

ICNLI (Infrastructure Contextual Natural Language Interface) is the open standard — a behavioral specification in the POSIX / OpenAPI / ANSI SQL standards category — defining what conformance means when AI agents take real operational action. Currently running in production at WebHostMost — an independent multi-region hosting business with deployments across the EU, North America, and Asia — on the imperal.io reference implementation. The architectural class of system that satisfies the contract is called a Modular Proactive AI Cloud OS. ICNLI v2.0 is in the anticipatory-standard phase (one specification author, one fully-conformant implementation, one enterprise production deployment — relationship disclosed for transparency); the multi-vendor open-standard milestones are documented in whitepaper §15.

Read the Whitepaper View the Specification

Current state — May 2026

ICNLI v2.0 is a vendor-authored open specification under CC BY-SA 4.0. One specification author, one flagship implementation (imperal.io), one enterprise client running it in production (WebHostMost). The path to multi-vendor open-standard status — conformance test suite, independent implementations, neutral governance — has explicit milestones with dates in the whitepaper. This section exists because honest readers should know exactly what they are looking at: not yet a finished industry standard, but the candidate protocol for one.

The simplest way to understand it¶

ICNLI is a behavioral specification — same category as POSIX, OpenAPI, ANSI SQL, SOAP, WSDL. Not a wire protocol (no byte-level format between independent endpoints — TCP/HTTP/MQTT live in that category, and ICNLI doesn't). Not an architectural style guide (12-Factor App is in that category, and ICNLI does more: it has RFC2119 normative MUSTs, conformance levels, and a measurable compliance surface). ICNLI is the behavioral specification that defines what a compliant Modular Proactive AI Cloud OS implementation must satisfy.

The standards-literature precedent that makes this claim defensible is POSIX (IEEE Std 1003.1) — universally called a standard, despite no wire format, despite extensive "implementation-defined" clauses, despite implementation dialects (GNU/Linux, FreeBSD, macOS, AIX). POSIX defines system call semantics + conformance — ICNLI defines AI-agent operational semantics + conformance, one abstraction level up for a different workload. The same category, applied to a different problem. (Detailed standards-category argument with prior art: Comparisons §9.)

ICNLI is currently in the anticipatory-standard phase — the stage every successful standard begins in. HTTP 0.9 was anticipatory (CERN, 1991, single-author Tim Berners-Lee). MCP is anticipatory today (Anthropic, single-organization). Python was CPython-only from 1991 to 2008 — anticipatory for 17 years. The standards-engineering literature (Krechmer 2005, Markus 2006) recognizes three stages: anticipatory → de facto (multiple implementations) → de jure (formal body governance). ICNLI is in stage 1, with explicit milestones to stages 2 and 3 in whitepaper §15.

What ICNLI is, all four labels applying simultaneously:

An open standard — in the behavioral specification category (POSIX, OpenAPI, SOAP, ANSI SQL — same category).
An open standard — in the anticipatory phase, CC BY-SA 4.0, with explicit multi-vendor governance milestones.
A reference architecture — descriptive of the architectural class (Modular Proactive AI Cloud OS) that compliant implementations build.
A conformance framework — defining compliance criteria at three levels (L1/L2/L3) per specification §13.

What ICNLI explicitly does not claim (the non-claims that bound the position):

Wire-level interoperability between independent implementations today.
Multi-vendor de facto standard status today (vendor-authored anticipatory phase; multi-vendor adoption is the roadmap target).
Neutral-foundation governance today (governance transfer is the §15 milestone after multi-vendor adoption ships).
Certified conformance (only self-attested L3 until the v2.1 conformance test suite ships).
Production deployment in any operational vertical beyond hosting (the protocol is domain-agnostic by design; only hosting has a production deployment today).

The positive claims and the explicit non-claims together define ICNLI's honest position. Both halves are in the published normative documents.

What "Modular Proactive AI Cloud OS" means in 60 seconds¶

Three load-bearing words. Each names a specific architectural commitment, not an adjective. Full definition in the FAQ.

Modular — the kernel is finite and stable; the surface is unbounded and pluggable. Extensions, channels, tools, and operational domains plug into a small orchestration core through declared manifest contracts. New domains arrive as new extensions, not as kernel rewrites. The kernel surface is the contract. The extension surface is the marketplace.

Proactive — the system watches its domain. It maintains a continuously refreshed awareness of the actor's state, surfaces anomalies without being prompted, and proposes remediations before the user thinks to ask. The interaction model inverts click-driven panels: the system reaches out first when something matters. Proactive is not autonomous. The system watches and proposes; the human authorizes.

AI Cloud OS — AI is the primary operational user of the system (the runtime client of its primitives), not a feature inside an application. The human remains the authorizing principal for every consequential action through the TWO-STEP gate. Context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives — not API integrations bolted onto a SaaS product.

The fundamental shift: AI moves INSIDE the OS, not next to it¶

For two years the industry has shipped AI as integration. A capable model is the brain; a layer of bespoke scaffolding wraps it; the result is a chat interface bolted onto an application. The application is for humans. The AI is a feature inside it.

─────────────────────────────────────────────────
  TRADITIONAL                ICNLI
─────────────────────────────────────────────────
  ┌──────────────┐           ┌──────────────┐
  │  Application │           │   AI Agent   │
  │  (for human) │           │  (the user)  │
  └──────┬───────┘           └──────┬───────┘
         │ uses                     │ runs on
  ┌──────▼───────┐           ┌──────▼───────┐
  │ AI as feature│           │ AI Cloud OS  │
  │  + bespoke   │           │ (kernel +    │
  │  scaffolding │           │  extensions) │
  └──────────────┘           └──────────────┘
─────────────────────────────────────────────────

ICNLI inverts the diagram. In a compliant implementation, the AI agent is the primary operational user of the system, and the system exposes operating-system primitives directly to it — process lifecycle for extensions, structured cross-session memory, dependency-aware multi-step execution, a comprehensive audit substrate. The implementation is for the AI in the same way a traditional operating system is for* the application. Primary operational user means the AI is the runtime client of the OS primitives — not the authority over what gets executed. The human remains the authorizing principal for every consequential action through the TWO-STEP gate; see Safety Layer §8 of the specification. The inversion is about who the OS is built for at runtime*, not who holds authority over execution.

This is not a metaphor; it is the same architectural inversion Kubernetes performed for containers and Erlang/OTP performed for concurrent actors — a finite kernel exposing OS-grade primitives to a defined class of workload, one abstraction level above the underlying compute. Kubernetes is not a Linux-kernel-style OS — it has no CPU scheduler — yet the industry calls it the "cloud OS" because it owns the orchestration primitives at its abstraction level. The same logic applies one layer up, for AI agents. In an AI Cloud OS, the model proposes; the human authorizes; the kernel guarantees. The deeper argument lives in the whitepaper, Section 3.

Three pillars of awareness — the protocol's spine¶

Everything ICNLI mandates rests on three substrates the kernel owns. Together they form the spine that lets AI act with genuine, audited awareness of the real world.

Context. Every compliant implementation MUST resolve a hierarchical 9-Level Context Model before any classification, routing, or dispatch — actor identity, role and permissions, account state, services, environments, applications, resources, relationships, and cross-system interconnections. The lower levels are mandatory at every conformance level; the upper levels unlock cascade-impact analysis at the highest conformance. Context is not retrieval. It is the substrate on which intent routing, the fact ledger, proactive intelligence, and the privacy boundary all stand. Cross-link: spec §4 — Context Model.

Action. Multi-tool requests MUST be executed through a single kernel-level chain orchestrator with explicit dependency declaration, topological execution order, fail-fast on dropped destructive plans, per-step audit emission, and TWO-STEP composition. Extensions MUST NOT implement private multi-tool loops. Reads precede dependent writes by construction; Step-Output References thread the verbatim output of one step into the input of the next without paraphrase. In ICNLI, the model proposes; the orchestrator guarantees. Cross-link: spec §6 — Intent Routing and Chain Orchestration.

Memory. A per-session fact ledger records every tool's structured output verbatim and makes it available to the model on subsequent turns. The User Intelligence Profile carries cross-session awareness in the background. Together they make memory a property of the protocol layer, not a plugin bolted onto a stateless model API. The memory survives a model swap because the memory was never inside the model. Cross-link: spec §7 — Anti-Fabrication Requirements.

The 5 problems other AI providers haven't solved (and how ICNLI does — structurally)¶

Five load-bearing problems sit between today's foundation models and trustworthy deployment in a real domain. The industry has spent years attacking each of them inside the model with mixed success. ICNLI bounds them outside the model, in the protocol around it.

Problem	Industry layer approach	ICNLI structural answer
Hallucination	Probabilistic — RLHF, constitutional methods, RAG reduce frequency but cannot reach zero.	Anti-Fabrication Contract. A per-session fact ledger plus grounded-narration enforcement plus intent-routed tool selection plus a PII mask. The model can be wrong; the system cannot fabricate ungrounded claims.
AI Control & Safety	Statistical — refusal training raises the floor but every published jailbreak is a proof statistical refusals can be bypassed.	TWO-STEP Human-in-the-Loop. Architectural confirmation enforced by the kernel before any state-changing action. No prompt can talk the kernel out of asking, because the kernel is not what answered.
Memory & Context	Buffer-based — long context windows are a buffer the model can see right now, not persistent structured awareness across sessions.	9-Level Context Model + User Intelligence Profile. Architectural memory in the protocol layer. Swap the model; the awareness state survives.
Multi-step Agent Reliability	Library-based — every agent framework reinvents safety, dependency handling, and retries differently, bounded by the brittleness of its loop.	Chain Orchestration with read-before-write. A normative contract for what multi-step dispatch MUST satisfy: single orchestrator, dependency declaration, topological order, fail-fast on dropped destructive plans.
Privacy	Policy-based — providers promise not to log, not to train, not to retain. The model cannot un-see what was sent.	Architectural Data Boundary. The protocol controls the data path. PII masking is a kernel gate; permission filtering happens before the model sees anything; on-premises deployment is supported by architecture.

Each row is the punch-line of a much longer argument. Read the full breakdown →

The proactive imperative¶

Reactive AI waits. The user asks; the system answers. That is the easy half of the problem and the half the industry has shipped.

The hard half is the half ICNLI mandates at the highest conformance level: a system that watches its domain, anticipates events, and surfaces concerns before the user thinks to ask. Background context refresh is a protocol-level requirement. The User Intelligence Profile is continuously maintained, independent of any inbound request. Unprompted alerts flow through the same channel-neutral surface as request-response traffic — and they MUST remain TWO-STEP-bound.

A worked sketch, domain-agnostic. Overnight, a resource the actor is responsible for crosses a meaningful threshold — a quota nearing exhaustion, a credential nearing expiry, a dependency degrading.

"Resource X crossed threshold Y at 02:47. Three remediation options are available; here are their cascade impacts. Shall I proceed with option 2?"

The actor authorizes — or declines — through the same TWO-STEP gate as any other consequential action. The system watches; the human authorizes. Proactive is not autonomous. The deeper treatment is in the whitepaper, Section 6.

Modular by design — any domain plugs in¶

This is not a hosting chatbot¶

The easy assumption: WebHostMost is the first enterprise production deployment, the acronym contains the word Infrastructure, and the extension catalog visibly contains hosting capabilities — therefore ICNLI is a hosting chatbot dressed up as a protocol. The assumption falls apart at the first look inside the kernel.

The kernel contains zero hosting abstractions. No Server type, no Domain (in the DNS sense), no Hosting Account, no SSL Cert, no cPanel/DirectAdmin/Plesk concept. The kernel's types are universal by construction: Actor, Context, Tool, Extension, ChainStep, Confirmation, AuditEvent, FactLedger. If this were a hosting chatbot, the hosting concepts would live in the kernel. They live in extensions — exactly the same way patient, transaction, or evidence record would in a healthcare, finance, or government deployment.

The 9-level context model has zero domain assumptions. Levels are Platform / Actor / Account / Service / Environment / Application / Resource / Relationship / Interconnection — generic operational ontology. The specification §4.1.1 maps the same nine levels side-by-side onto Hosting, Healthcare, Finance, and Legal/Investigative domains as worked examples. The shape is invariant. The payload varies.

The current extension catalog is mostly not hosting. The first-party extensions on imperal.io today include administration, billing, automations, developer tooling, file storage, messaging, task management, web tooling, and customer-relations management. Hosting is one operational verb the deployed extensions speak; subscription billing, task automation, file management, customer relations, and developer publishing are the others. The kernel is the same in all cases. The agent (Webbee) is the same. Hosting is the first vertical to ship; it is not the only vertical the protocol supports.

The reference interaction in specification Appendix A is intentionally generic — actor Alex, service A, rpt-west-04 — readable as hosting, financial reporting, or clinical reporting without changing a single line of the protocol. The same dialogue would compose against any extension that declares the right tools and safety levels.

Domain-agnostic by normative principle¶

ICNLI does not know what "patient", "transaction", "DNS record", "shipment", or "evidence artifact" means. The kernel defines context resolution, intent routing, safety contracts, chain semantics, audit, and proactive primitives. The domain is what an extension places inside those primitives. The architectural shape is invariant across verticals; the extensions and the context payload vary.

Domain agnosticism is a normative principle of the specification — the core MUST NOT encode assumptions about any specific operational domain (see Core Principle 8 in the specification). This is an architectural property, not a deployment claim.

What is deployed today: WebHostMost runs ICNLI in production for hosting infrastructure operations — DNS, servers, databases, SSL, email — across multiple regions. That is the only operational vertical with a live production deployment. The architectural worked examples for other regulated domains (healthcare, finance, smart city, government, defense, manufacturing, logistics) live in the whitepaper, Section 14 — they are applicability claims for the architecture, not deployment claims. ICNLI will list a vertical here as deployed when, and only when, an independent third-party deployment in that vertical exists.

Safety is architectural, not optional¶

Model-layer alignment is real engineering, and the floor it raises is real. It is also, by construction, statistical. Refusal training reduces the probability of an undesired output. It cannot reduce that probability to zero.

For consequential operations, the right primitive is architectural, not probabilistic. ICNLI mandates TWO-STEP confirmation for every state-changing operation: the system proposes with impact analysis; the actor confirms; only then does the system execute. The confirmation gate is enforced by the kernel and is outside the model's authority. Every tool is classified by safety level; danger phrases and cooling periods apply to the most consequential.

The Anti-Fabrication Contract completes the picture. The fact ledger, grounded-narration enforcement, the intent-routed tool surface, and the PII masking gate together establish a bound that does not depend on the model being well-behaved.

Ungrounded fabrication is structurally prevented at the provenance layer (verbatim fact ledger) and contractually constrained at the narration layer (grounded-narration MUST). Together these raise the fabrication bar dramatically while remaining auditable end-to-end.

A complete audit substrate records what was proposed, what was confirmed, what executed, what was masked, and who authorized any unmasking. Compliance is auditable at the protocol layer in a way it cannot be at the model layer alone. Cross-links: spec §7 — Anti-Fabrication · spec §8 — Safety Layer.

The stack — protocol, engine, SDK, agent, extensions, deployment¶

ICNLI is the protocol. Like every protocol that became infrastructure, it sits at the top of a stack of complementary artifacts — and each layer below it has a name. The familiar precedents lay out the same shape:

POSIX          →  Linux           →  libc          →  bash        →  apt packages   →  enterprise Linux deployments
Kubernetes API →  kubernetes      →  client-go     →  kubectl     →  Helm charts    →  managed cloud platforms
ICNLI          →  imperal.io   →  imperal-sdk   →  Webbee      →  Extensions     →  WebHostMost (first production)

Each row is a complete operating-system stack at its own abstraction level. ICNLI's row is the agent-level analog. Five public artifacts make it real today.

ICNLI — the protocol¶

The open specification and the normative contract. Published under CC BY-SA 4.0. The trademark is held by Imperal, Inc. Any organization may implement the protocol; any compliant implementation may use any underlying foundation model.

imperal.io — the ICNLI Engine¶

imperal.io — Imperal Cloud, the first ICNLI AI Cloud OS — is the ICNLI Engine, the reference implementation that turns the open specification into a running operating system. As Linux is to POSIX, imperal.io is to ICNLI: the world's first complete implementation of the ICNLI protocol, and the first self-attested L3-conformant Modular Proactive AI Cloud OS (self-attested per specification §13.5; the conformance test suite is the v2.1 critical-path deliverable, no implementation may claim certified until it ships) in production today. imperal.io implements the protocol at the highest conformance level: the full 9-level context model, the modular kernel-plus-extensions architecture, intent routing with chain orchestration, the Anti-Fabrication Contract, TWO-STEP safety with danger phrases and cooling periods, cross-channel continuity, proactive intelligence with the User Intelligence Profile and Alert Protocol, and three-pillars observability. The protocol caught up to architectural reality, not the other way around — every normative MUST in v2.0 was field-tested on imperal.io before becoming normative.

imperal-sdk — the developer surface¶

pip install imperal-sdk gives any Python developer a working toolkit for building against the protocol: typed decorators for declaring extensions, tools, panels, secrets, and webhooks; a manifest schema validator that rejects non-conformant code at build time; kernel-level AST-scan validators that enforce kernel-API boundaries; and a published JSON Schema for tool definitions that any third-party validator can use. The SDK is the layer at which external developers actually build against ICNLI — and it is the proof that the kernel surface is a contract, not a private API.

Package: pypi.org/project/imperal-sdk · Reference & quickstart: docs.imperal.io

Webbee — the reference agent¶

Webbee, the agent of the first ICNLI AI Cloud OS: the canonical AI on top of the imperal.io kernel, the first-party agent that exercises the full surface of the protocol. Where imperal.io is the OS, Webbee is the agent that lives inside it — bash to ICNLI's POSIX. Webbee demonstrates the proactive imperative in practice: the agent that watches, anticipates, surfaces, and proposes.

Extensions — the marketplace surface¶

A core set of operational extensions ships first-party on imperal.io — administration, billing, automations, developer tooling, file storage, messaging, task management, web tooling, customer-relations management, and more — each one a Python package built against the SDK and validated against the protocol contract before registration. Extensions plug new domains into the kernel without modifying it; the kernel surface is the contract, the extension surface is where the marketplace lives. Every Python package built against the SDK passes through kernel-level AST-scan validators that reject non-conformant code before deploy. Full validator-throughput from the in-house developer team is published with explicit honest framing in whitepaper §13.5 — those counts measure CI iteration activity from a small team, not unique-developer reach.

WebHostMost — the first enterprise production deployment¶

webhostmost.com is imperal.io's first enterprise production deployment — an independent multi-region hosting business whose first-line operations run through Webbee on imperal.io. Every customer-facing infrastructure action — every server change, every domain operation, every database action, every SSL or DNS write — passes through the ICNLI gate, with TWO-STEP confirmation, the fact ledger, anti-fabrication checks, and the audit trail active on every dispatch. The deployment serves real clients across multiple channels (web and messaging are live; voice is planned).

WebHostMost is what makes the protocol defensible as a deployed standard rather than a designed one: every normative MUST in the specification was field-tested by a paying enterprise client before it became normative. WebHostMost and Imperal, Inc. share a founder; the customer relationship is disclosed here for transparency, and the path to independent enterprise customers is on the open-standard roadmap in the whitepaper, §15.

Live operational numbers¶

Representative seven-day window, May 2026, from WebHostMost on imperal.io:

Metric	Value	What it counts
Chat turn success rate	93.2%	2,530 successful / 185 errored — 2,715 total turns over the window. This is small-beta scale, not "at scale" — explicit gap for v2.1 broader telemetry.
Destructive intent share (all TWO-STEP-gated)	2.6%	Classifier `action_type=destructive` — routed through L3/L4 confirmation regardless of model output
Chain step executions	1,203	Individual per-step dispatches — full-chain counts are smaller (chain lengths vary 2–7 steps)
Protocol contract violation rate (caught & surfaced)	0.63%	17 runtime contract violations detected and surfaced; not silent failures

Validator-surface activity (the developer-portal CI iteration count) is published with full honest framing in whitepaper §13.5 — it measures contract enforcement upstream of production from a small in-house developer team, not a marketplace-developer count.

Full metrics breakdown, denominators, and acknowledged measurement gaps in the whitepaper, §13.5. Confirmation accept/reject ratio per safety level, per-tool action success rate, hallucination ground-truth rate, and independent third-party benchmark are explicitly listed as gaps and on the v2.1 roadmap. We do not publish numbers we cannot defend.

Created By · License · Trademark¶

ICNLI is created by Valentin Scerbacov, founder of Imperal, Inc.

The specification is published under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). Any organization may implement the protocol. Any implementation may use any underlying foundation model.

ICNLI™ is a trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this site but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. Webbee™ is a trademark of WebHostMost. Trademark inquiries: license@icnli.org.

Explore the protocol¶

Six doors into the spec, organized by what brought you here.

First encounter, just want the gist. → What is ICNLI? — the FAQ form of the questions a careful reader asks first.
Evaluator comparing options. → The 5 AI Problems Bounded Structurally — the deck argument in punch-list form.
Reader who wants the full architectural argument. → ICNLI Whitepaper v2.0 — long-form narrative authority.
Engineer or LLM building to spec. → ICNLI Specification v2.0 — the normative RFC2119 contract.
Comparing against MCP, function calling, or agent frameworks. → ICNLI vs Other AI Protocols — an honest, layer-by-layer comparison.
Compliance officer, government policy, or risk team. → Compliance & Regulatory Mapping — how ICNLI normative MUSTs map to NIST AI RMF, EU AI Act, ISO/IEC 42001, FedRAMP, DoD readiness, and the MITRE ATLAS adversarial threat model.

Operational metrics: What we measure in production →

Creator: Valentin Scerbacov
Trademark Owner: Imperal, Inc.
Website: icnli.org
Trademark inquiries: license@icnli.org
Flagship implementation: imperal.io
Reference agent: Webbee
First enterprise production deployment: WebHostMost