Skip to content

What is ICNLI?

ICNLI is the open standard for Modular Proactive AI Cloud Operating Systems — a behavioral specification (in the same standards category as POSIX, OpenAPI, ANSI SQL) that turns a powerful AI model into a deployment you can ship into a real operational domain with audited safety semantics. ICNLI defines what conformance means; implementations build the actual systems. Currently in the anticipatory-standard phase (one author, one reference implementation, one enterprise production deployment); multi-vendor milestones are in whitepaper §15.

In one sentence — what is ICNLI?

ICNLI is an open standard (CC BY-SA 4.0) for building Modular Proactive AI Cloud Operating Systems — defining how an AI system acquires structured domain awareness, routes intent to the right tools, executes actions safely with human confirmation, and maintains continuous, verbatim knowledge of the environment it operates in. It is a behavioral specification in the POSIX / OpenAPI / ANSI SQL standards category. Currently in the anticipatory-standard phase, running in production at WebHostMost (independent multi-region hosting) on the imperal.io reference implementation; multi-vendor open-standard milestones are in whitepaper §15. The full standards-category argument lives in Comparisons §9.

In one paragraph — what is ICNLI?

ICNLI — the Infrastructure Contextual Natural Language Interface — is the protocol layer that sits around a foundation model rather than inside it. Foundation models from Anthropic, OpenAI, and Google are the brain; ICNLI is the nervous system you build around a brain so that AI can live inside a real operational domain with structural guarantees. The protocol defines a hierarchical context model, multi-step chain orchestration with read-before-write semantics, an anti-fabrication contract that binds narration to a verbatim fact ledger, a mandatory TWO-STEP confirmation gate for state-changing operations, an audit substrate, and formal conformance levels. When all of that is present, AI stops being a feature inside an application and becomes the primary user of an operating system designed for it.

What does "Modular Proactive AI Cloud OS" mean?

Three load-bearing words, each naming a specific architectural commitment.

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

Proactive — the system watches its domain, anticipates events, surfaces concerns, and proposes actions without being asked. Background context refresh is a protocol-level requirement at higher conformance levels. The interaction model inverts the click-driven panel paradigm: the system reaches out first when something matters, rather than waiting passively for the user to navigate to it.

AI Cloud OS — AI is the primary user of the system, not a feature embedded inside an application. Context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives, not API integrations.

Is ICNLI an AI?

No. ICNLI is an open standard — specifically, a behavioral specification document in the POSIX / OpenAPI / ANSI SQL standards category, not a running system. It does not generate text, classify intent, or run inference. It defines the contract that a compliant implementation MUST satisfy in order to call itself a Modular Proactive AI Cloud OS. The full standards-category argument lives in Comparisons §9.

The distinction matters because it locates the guarantees correctly. A foundation model is a probabilistic generator: it can be improved but it cannot be made deterministically safe. A protocol is a deterministic contract: a compliant implementation satisfies the contract by construction or it does not. ICNLI is what defines that contract.

The AI inside a compliant implementation can be any capable model — Anthropic Claude, OpenAI GPT, Google Gemini, an open-weights model, a future model that has not yet shipped. ICNLI does not care which brain is underneath. It cares that the nervous system around the brain satisfies the contract.

What can ICNLI-compliant systems do?

A compliant implementation gives you the following capabilities out of the protocol, not out of bespoke per-deployment engineering:

  • Maintain structured awareness of every actor and their domain across sessions and channels — chat today, voice tomorrow, alerts in between.
  • Route natural-language intent to the correct domain, the correct tool, and the correct parameter set.
  • Execute multi-step operations as dependency-ordered chains where reads precede dependent writes.
  • Preserve every tool's structured output verbatim across turns, so the next turn does not paraphrase what already happened.
  • Refuse to fabricate. Every user-facing claim is bound to facts present in the ledger or the current turn's results.
  • Demand explicit human confirmation before any state-changing action, with full impact analysis on consequential operations.
  • Emit a complete audit record of what was proposed, what was confirmed, what was executed, and by whom.

Who is ICNLI for?

Three audiences, in three different postures.

Domain experts — physicians, infrastructure operators, financial controllers, civic administrators, anyone whose field is operationally complex and historically poorly served by click-driven control panels. ICNLI is the protocol that makes your domain intelligently operable, with the AI living inside the OS rather than next to it.

AI engineers and architects — anyone designing systems that need structural guarantees rather than probabilistic hopes. If you have been re-inventing safety, memory, multi-step coordination, and audit per project, ICNLI is the standard that defines those primitives once so you can stop re-inventing them.

Organizations in regulated contexts — healthcare, finance, government, utilities, critical infrastructure. ICNLI is the layer at which AI deployment can be made auditable and the layer at which a compliance team can say yes without abandoning structural integrity. The protocol is domain-agnostic; the guarantees are domain-independent.

How is ICNLI different from MCP, function calling, and agent frameworks?

Different layer of the stack. Protocols and frameworks are not competing for the same slot.

MCP (Model Context Protocol) and OpenAI Function Calling standardize the model-tool boundary — how a foundation model invokes a structured capability. Agent frameworks like LangChain, AutoGPT, and CrewAI are libraries that orchestrate a model and its tools into multi-step behaviour in application code. Each is real engineering at the layer it occupies.

ICNLI is the protocol around all of them — the OS in which an AI system must live to be deployable in a real domain. It defines the context model, chain semantics, anti-fabrication contract, safety classifications, audit substrate, and conformance levels as normative MUSTs. A compliant ICNLI implementation MAY use MCP at the model-tool boundary, MAY use function calling as the model-to-kernel I/O mechanism, and MAY use any library underneath the kernel. The protocol layer composes with all of them.

See the full comparison for the scope-based matrix.

How is ICNLI different from OpenAI APIs, Anthropic Claude, Google Gemini?

This is not a competition. They occupy different layers of the stack.

Anthropic, OpenAI, and Google make the brains. They produce foundation models that reason, draft, summarize, and converse, and they do this exceptionally well. The rate of capability improvement at the model layer has been the defining technical story of the decade.

ICNLI is the nervous system you build around a brain. It is the protocol layer outside the model: context resolution, intent routing, chain orchestration, confirmation, fact ledger, narration grounding, audit. Any compliant ICNLI implementation MAY use any underlying foundation model, and the model is a swappable component inside the protocol rather than a competitor to it.

The two layers are complementary by construction. A model-layer improvement reduces the probability of an undesired output. A protocol-layer structural mechanism either structurally prevents a class of undesired output at the architectural layer or contractually constrains it through normative MUSTs plus runtime judges. Both have real value; each is responsible for what it can guarantee at its own layer. See ICNLI vs Foundation Model APIs for the longer treatment.

Does ICNLI solve AI hallucination?

With explicit scope. The Anti-Fabrication Contract structurally prevents ungrounded fabrication at the provenance layer (the verbatim fact ledger preserves every tool's structured output across turns) and contractually constrains it at the narration layer (grounded-narration MUST clauses enforced by runtime judges).

The mechanism: a per-session fact ledger records the verbatim output of every tool call. A grounded-narration requirement forbids the system from claiming a tool produced a value not in that tool's output, from quantifying a result not enumerated in the underlying facts, or from attributing a status to a resource whose status was not retrieved. Intent-routed tool selection restricts the model's tool surface so that tools the model never sees cannot be invented. A PII masking gate filters context delivered to the model by default.

The model can still be wrong about a fact it was given. The system raises the fabrication bar dramatically and makes any deviation auditable end-to-end. Compliant implementations inherit the same boundary regardless of which underlying foundation model they use. The precise scope of guarantee — what is structurally prevented vs contractually constrained vs roadmap — is documented in the whitepaper §9 Limitations subsection. See Problem 1: Hallucination for the full argument.

How does ICNLI ensure AI safety?

ICNLI defines safety as an architectural property, not a behavioural one. Every state-changing action requires explicit human confirmation before execution. This is mandated by the protocol — the TWO-STEP MUST — not by policy. The model proposes; the human authorizes; the kernel guarantees execution only happens after explicit consent. Refusal training in the model is complementary, not the load-bearing safety surface. Even if the model misbehaves, the kernel's gate is outside its authority. (Live: ~21% of intents are write or destructive, all routed through this gate. Spec §8.)

The protocol classifies every tool by safety level 0 through 4. Confirmation escalates with level: optional at L1, TWO-STEP at L2, TWO-STEP with full impact analysis at L3, danger-phrase-plus-cooling-period at L4. Impact analysis enumerates direct targets, cascade targets derived from the context model, reversibility, and backup availability. Role-based access is enforced on every dispatch.

The distinction from model-layer refusal training is the whole point. Refusal training is probabilistic — it reduces the frequency of harmful output but cannot reduce that frequency to zero. Architectural human-in-the-loop is deterministic — the kernel either gated execution or it did not, and the audit record proves which. See Safety Layer for the normative contract.

Who created ICNLI?

ICNLI was created by Valentin Scerbacov, founder of Imperal, Inc. and the Webbee project. The protocol was extracted from years of building production AI systems serving real customers. ICNLI was first created on 30 December 2025 (v1.0.0); the current specification is v2.0 (May 2026). WebHostMost is imperal.io's first enterprise client — an independent multi-region hosting business whose operational platform is managed by an ICNLI-conformant AI in production today. (WebHostMost and Imperal, Inc. share a founder; the customer relationship is disclosed for transparency.)

The flagship implementation of ICNLI v2.0 is imperal.io (Imperal Cloud), the first ICNLI AI Cloud OS — a self-attested L3-conformant Modular Proactive AI Cloud OS (self-attested per specification §13.5; the automated conformance test suite is the v2.1 critical-path deliverable, and no implementation may claim certified until it ships). The reference agent on top of that kernel is Webbee, the agent of the first ICNLI AI Cloud OS. The protocol itself is published as an open standard under CC BY-SA 4.0 so that any organization can implement it, audit against it, and inherit its structural guarantees without paying a license fee for the spec. The trademark is held separately by Imperal, Inc. to protect the integrity of conformance claims.

Is ICNLI open source?

Yes. The specification is published under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). Anyone may read it, implement it, fork it, adapt it, and use the resulting implementation commercially, under the terms of attribution and share-alike.

The ICNLI™ trademark is separately protected by Imperal, Inc. and is not granted by the content license. The name carries an integrity meaning: a system that calls itself ICNLI-compliant is making a structural claim. Trademark protection lets the community defend that claim against vendors who would water it down.

Can I build extensions for ICNLI?

Yes — and a reference SDK exists today. imperal-sdk is the Python toolkit for building extensions against the protocol, published on PyPI. pip install imperal-sdk gives you typed decorators for declaring 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 (extensions MUST use ctx.api, MUST declare safety levels per tool, MUST NOT embed orchestration loops); and the canonical JSON Schema for tool definitions that any third-party validator can use.

Extensions built with the SDK plug into the imperal.io kernel — the ICNLI Engine — and into any compliant ICNLI engine that targets the same protocol version. A core set of operational extensions already 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.

The SDK is the layer at which third-party developers actually build against ICNLI — and its existence is the empirical proof that the kernel surface is a contract, not a private API. Package: pypi.org/project/imperal-sdk. Reference and quickstart: docs.imperal.io.

What does an ICNLI interaction look like?

A short domain-agnostic exchange illustrating the protocol's shape: structured context, proposal with impact analysis, human confirmation, grounded result.

Actor:  "Decommission the old reporting server for the Western division."

System: I located the resource you mean — host "rpt-west-04", part of
        the Western division reporting cluster, last active three days
        ago. Decommissioning is a CRITICAL operation.

        Impact analysis
        ──────────────────────────────────────
        Direct target:   rpt-west-04
        Cascade:         2 dashboards depend on this host
        Reversibility:   Restorable from backup within 14 days
        Backup status:   Verified, 6 hours old

        To proceed, type the danger phrase: DECOMMISSION RPT-WEST-04

Actor:  DECOMMISSION RPT-WEST-04

System: Confirmed. Decommissioning rpt-west-04. I will rewire the
        two dependent dashboards to rpt-west-05 in the same step.

        Done. Audit record icnli-act-7f3a2c written. Both dashboards
        responded healthy on the new source.

Notice the shape: the system resolved context the actor did not have to provide, performed impact analysis the actor did not have to ask for, gated execution behind explicit confirmation, completed a multi-step chain in one turn, and produced an audit record for free. That shape is the protocol.

Where can I read the full specification?

Three primary documents, each open under CC BY-SA 4.0:

For comparison against adjacent artifacts, see ICNLI vs Other AI Protocols.

About the Author

Valentin Scerbacov is the creator of ICNLI and founder of Imperal, Inc. This page is the first-encounter introduction to the protocol — the FAQ form of the questions a careful reader asks first. The flagship implementation of ICNLI v2.0 is imperal.io (Imperal Cloud), the first ICNLI AI Cloud OS, with Webbee as the agent of the first ICNLI AI Cloud OS; WebHostMost is imperal.io's first enterprise client, running an ICNLI-compliant deployment across multi-region hosting infrastructure.

License

© 2026 Valentin Scerbacov / Imperal, Inc.

This page is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You are free to share and adapt this material for any purpose, including commercial, under the terms of attribution and share-alike.

Full license: https://creativecommons.org/licenses/by-sa/4.0/

ICNLI™ is a trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this page but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. Webbee™ is a trademark of WebHostMost. Claude is referenced under nominative fair use; its trademark remains the property of Anthropic, PBC. GPT is referenced under nominative fair use; its trademark remains the property of OpenAI, Inc. Gemini is referenced under nominative fair use; its trademark remains the property of Google LLC.

  • 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