ICNLI Whitepaper v2.0¶

The Open Protocol for Modular Proactive AI Cloud Operating Systems¶

Version: 2.0 (current) · next: v2.1 Published: May 2026 Created by: Valentin Scerbacov

ICNLI was first created on 30 December 2025 (v1.0.0). Current specification: v2.0 (May 2026); next deliverable: v2.1. Copyright: © 2026 Valentin Scerbacov / Imperal, Inc. License: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) Trademark: ICNLI™ is a trademark of Imperal, Inc.

*"AI learned to understand language. ICNLI gives that intelligence a domain to know, a reality to act upon, and a human to answer to."*

Executive Summary¶

Every major architectural layer in computing introduced a new abstraction that made the layer below universally accessible to a new class of workload — operating systems for software over hardware, Kubernetes for containers over compute, Erlang/OTP for concurrent actors over processes. ICNLI is a candidate for the layer above foundation models — the agent-level operational substrate, in the same architectural category Kubernetes established for containers and Erlang/OTP for concurrent actors. It is a behavioral specification (in the POSIX / OpenAPI / Kubernetes API category), not a wire protocol — defining normative semantics, conformance levels, audit obligations, and a contract for what compliance means, rather than byte-level interoperability between machines. Candidacy is earned over decades through independent adoption, conformance verification, and multi-vendor governance — none of which are claimed by v2.0; the explicit milestones for that path are documented in §15. In 2026, the bottleneck of useful AI is no longer the model. The bottleneck is the substrate around the model: the layer that gives an AI engine domain awareness, multi-step reliability, persistent memory, structural safety where structural primitives exist (provenance, intent surface, PII gate) and contractual constraints where they do not (grounded narration), and an audit substrate worthy of regulated work. That layer has been missing.

ICNLI — the Infrastructure Contextual Natural Language Interface — is that layer, defined as an open standard. Version 2.0 positions ICNLI as the protocol for Modular Proactive AI Cloud Operating Systems. Modular because extensions, channels, tools, and operational domains plug into a finite, stable kernel through declared contracts — the kernel surface is the contract, the extension surface is the marketplace. Proactive because a compliant system watches its domain, anticipates events, surfaces concerns, and proposes action without being asked; background context refresh is a protocol-level requirement at higher conformance. AI Cloud OS because the architecture treats AI as the primary user of the system rather than a feature embedded inside an application — context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives, not API integrations.

What changes when you have a compliant implementation is measurable in commitments rather than adjectives. Hallucination is bounded structurally by a verbatim cross-turn fact ledger and grounded narration. Multi-step agent reliability is bounded by dependency-aware chain orchestration with read-before-write semantics and fail-fast on dropped destructive plans. Safety is bounded by a mandatory TWO-STEP confirmation protocol no AI can bypass. Privacy is bounded by a permission-filtered architectural boundary, not a policy promise. Memory is bounded by a structured 9-level context model that survives across sessions and channels. The full normative contract lives in the ICNLI Specification v2.0; this whitepaper provides the architecture, the rationale, and the evidence.

1. The Unfinished Revolution¶

Artificial intelligence reached an inflection point. Foundation models from Anthropic, OpenAI, Google, and others can reason, draft, summarize, plan, and converse with a fluency that would have seemed implausible to engineers writing five years ago. The model layer is in remarkable shape. And yet the experience of deploying AI into a real operational domain — a hospital, a hosting provider, a financial back-office, a city traffic authority — remains structurally fragile. The capability is there; the trust is not.

The reasons are not mysteries. They are open problems the industry has named clearly and tried to address inside the model, with mixed success: hallucination, because a probabilistic generator can in principle produce a well-formed, plausible, false sentence on any forward pass; control and safety, because refusal training is statistical and every published jailbreak is a proof that statistical refusals can in principle be bypassed; memory, because a context window is not a structured per-actor awareness model that lives across sessions; multi-step reliability, because a single forward pass cannot natively reason about transactional dependencies; and privacy, because privacy is a property of the data path, not the model — a model that sees raw private data in context cannot un-see it.

Each of these is treated in depth in Section 8. The point here is the diagnosis. These are not model bugs. They are layer-misassignment bugs. Refusal training, constitutional methods, RAG, vector stores, agent frameworks — each is valuable engineering at the layer it occupies, and each is bounded by the layer it occupies. The right response to a layer problem is not a better instance of the same layer. The right response is the layer that has been missing.

2. Evolution of Architectural Layers¶

Each major architectural step in computing introduced a new layer — not to replace what existed below, but to make it universally accessible to a specific class of workload one abstraction level up. ICNLI's claim is that the agent-level operational substrate is the natural next layer above foundation models; the lineage that justifies it is architectural category, not wire-protocol displacement.

1970s:  Operating Systems (UNIX, then Linux)
        └─ OS for processes over hardware           → anyone could write software

1990s:  Browser (HTML/JS over HTTP)
        └─ OS for documents that compute            → any page could behave like an application

2000s:  Cloud Computing
        └─ Abstracted infrastructure                → any team could deploy without owning hardware

2010s:  Kubernetes
        └─ OS for containers over compute clusters  → workload scheduling, declarative state,
                                                       extension surface (CRDs, Operators, Helm) —
                                                       all without a CPU scheduler of its own

2010s:  Erlang/OTP, Smalltalk-80 environments
        └─ OS for concurrent actors / live objects  → architectural-category OS at a non-Linux
                                                       abstraction level

2020s:  Large Language Models
        └─ Abstracted language                      → any system could understand text

2026+:  ICNLI (candidate)
        └─ Behavioral protocol for the agent-level   → finite kernel exposes context resolution,
            operational substrate                      intent routing, chain orchestration, fact
                                                       ledger, TWO-STEP safety, audit substrate
                                                       to AI agents as the runtime client

ICNLI is a candidate for the agent-level layer; the candidacy is what §15 documents the path toward. The architectural-category lineage that justifies it is POSIX-style standards (behavioral specifications with normative MUSTs and conformance levels) rather than wire protocols. The standard abstracts how AI inhabits a domain: how it acquires structured awareness, how it routes intent, how it composes action, how it preserves what is true, how it remains auditable. The model below it remains the model. The applications above it remain the applications. The new layer — agent-level operational substrate with kernel-grade safety and audit primitives — is what has been missing.

3. What "Modular Proactive AI Cloud OS" Means¶

The three load-bearing words in the protocol's positioning are not adjectives. Each names a specific architectural commitment that the Core Principles of the specification turn into a normative MUST.

Modular means the kernel is finite and stable, and the surface is unbounded and pluggable. A compliant implementation MUST be structured as a small orchestration core surrounded by extensions that declare their tools, contributions, and required permissions through a manifest contract. The kernel owns intent classification, chain orchestration, confirmation, the audit substrate, the fact ledger, and the extension lifecycle. Extensions own the tools they declare and the domains they speak for. Extensions MUST NOT alter kernel orchestration semantics. New domains, channels, or capabilities SHOULD be added by registering new extensions, not by modifying the kernel. This is what makes the protocol a platform rather than a product. The kernel surface is the contract. The extension surface is the marketplace.

Proactive means the system watches its domain. At Conformance Level 3, a compliant implementation MUST maintain a User Intelligence Profile that refreshes in the background — independent of any inbound request. The system MUST be capable of surfacing alerts, anomalies, and proposed actions without being prompted. Alerts MUST flow through the same channel-neutral interface as request-response traffic and MUST remain TWO-STEP-bound: an unprompted proposal still requires explicit human confirmation before any state-changing execution. Proactive is not autonomous. The system watches and proposes; the human authorizes. The distinction is load-bearing.

AI Cloud OS is the frame. A compliant implementation exposes OS-level primitives — process lifecycle for extensions, structured memory across sessions, dependency-aware multi-step execution, a comprehensive audit substrate — directly to the AI agent, because the AI agent is the primary user of the system. The implementation is for the AI in the same way a traditional operating system is for the application. This is not a metaphor. It is an architectural inversion. In an AI Cloud OS, the model proposes; the human authorizes; the kernel guarantees. Everything the protocol mandates flows from that inversion.

The three commitments compose. A modular kernel that watches its domain and exposes OS-level primitives to the AI agent is, by definition, a different class of system than an application with a chat interface bolted on. The specification names the class and defines the contract.

4. The 9-Level Context Model¶

ICNLI mandates a hierarchical context model with nine levels, from L0 (Platform) to L8 (Interconnection). A compliant implementation MUST resolve context in order from L0 upward, and MUST NOT skip levels — a request that references L5 also has L0–L4 resolved. The model is domain-agnostic: the levels are about categories of awareness, not about any particular industry.

L0  PLATFORM         Platform capabilities, available tools, system status
L1  ACTOR            Identity, authentication, roles, permissions
L2  ACCOUNT          Account, subscription, quotas, limits
L3  SERVICE          Services owned by the actor, their status and configuration
L4  ENVIRONMENT      Hosts, regions, environments, deployment topology
L5  APPLICATION      Applications, datasets, channels deployed in environments
L6  RESOURCE         Records, files, configurations, metrics
L7  RELATIONSHIP     Connections and dependencies between entities
L8  INTERCONNECTION  Cross-system dependencies and cascade impact analysis

The lower levels (L0–L2) are mandatory at every conformance level. Mid-levels (L3–L6) are required at Standard and Advanced conformance. The upper levels (L7–L8) are required only at Advanced conformance, because relationship and interconnection awareness is what enables genuine cascade-impact analysis — the ability to say, before a destructive operation executes, what else will be affected. A request like "retire service A" is structurally different when the system can enumerate the dependents and the dependents-of-dependents before proposing. Cross-link: Context Model.

The 9-level model is the substrate on which everything else stands. Intent routing depends on it. The fact ledger references it. Proactive intelligence surfaces anomalies in terms of it. Privacy enforcement masks it before transmitting to the model layer. It is not a feature; it is the spine.

5. Modular Kernel + Extensions Pattern¶

A compliant Modular Proactive AI Cloud OS is structured as a finite kernel plus a pluggable surface of extensions. This is not a deployment convenience or an internal organizational choice. It is a normative requirement of the protocol — and it is the mechanism by which ICNLI escapes the gravity well that swallowed earlier monolithic agent frameworks.

The kernel owns the orchestration substrate: intent classification, chain orchestration, confirmation and audit, the fact ledger and memory, and the extension lifecycle itself. The kernel does not own tools. The kernel does not own domains. The kernel does not know what "patient", "transaction", "DNS record", or "warehouse aisle" means. The kernel knows how to classify intent, route to the correct extension, sequence multi-step calls, confirm consequential actions, and emit audit-grade evidence of what happened. Its surface is stable and finite.

Extensions own everything that varies by domain. An extension is a pluggable unit that declares — through a manifest contract the kernel validates before registration — its identity, version, declared tools (each with name, safety classification, parameters, and return shape), its capability surface (panels, channels, background jobs it contributes), the minimum permissions it requires, and the protocol version against which it was built. A compliant kernel MUST validate the manifest categorically before registration; an invalid manifest MUST be rejected with a structured error, and the extension MUST NOT be registered partially. The extension lifecycle is itself an orchestrated set of stages — load, validate, register, dispatch, unload — and the kernel emits audit events at each stage. Cross-link: Modular Extension Contract.

The benefit of this separation is operational, not aesthetic. The kernel's correctness is a one-time concern: the intent router, the chain orchestrator, the confirmation gate, and the audit trail are written once and verified once, and every extension thereafter inherits those properties by construction. An extension author building a tool for a new domain does not re-implement safety, memory, or multi-step coordination — those primitives are already kernel-grade. The marketplace surface is unbounded: new domains arrive as new extensions, not as kernel modifications, governed by the same lifecycle. And conformance is composable — the kernel publishes a conformance level, each extension declares the conformance level it was built against, and a compliant kernel MUST refuse to load extensions targeting a higher level than it supports. Operators see a single conformance number for the deployment; they get marketplace plurality without integrity loss.

The kernel surface is the contract. The extension surface is the marketplace.

6. Proactive Intelligence — The System Watches¶

Traditional AI systems are reactive. A user asks, the system answers. ICNLI introduces a different paradigm at higher conformance: a system that watches its domain, maintains a continuously refreshed awareness of the actor's relevant state, and surfaces concerns and proposed actions without being asked. This is the proactive in Modular Proactive AI Cloud OS, and it is a normative protocol requirement, not a feature to be selectively implemented. Cross-link: Proactive Intelligence Requirements.

The core mechanism is the User Intelligence Profile — a continuously maintained awareness model of an actor and their domain state. At Conformance Level 3, the profile MUST be refreshed in the background, independent of any inbound request. Refresh cadence and scope are implementation-specific; the profile's existence and freshness are not. The profile MUST capture, at minimum, a summary of the actor's relevant services and resources, a summary of recent activity within a configurable window, and any outstanding follow-ups, pending confirmations, or alert states.

Three protocol behaviors stand on this substrate. Background context refresh means the system has already resolved the relevant context before the actor asks — the first turn does not begin from zero, but from a current snapshot of the actor's domain. Anomaly surfacing means the system SHOULD detect state divergence from a baseline and bring it to the actor's attention through the same channel-neutral interface as request-response traffic. The Alert Protocol governs unprompted communication: alerts MUST flow through the same protocol surface as request-response traffic, MUST be paired with a TWO-STEP proposal when they recommend state-changing action, MUST be recorded in the audit substrate, and MUST be suppressible by the actor without loss of other protocol functionality.

A worked illustration, domain-agnostic. An actor is responsible for a fleet of resources. Overnight, one resource crosses a meaningful threshold — a quota nearing exhaustion, a credential nearing expiry, a dependency degrading. In a reactive system, the actor learns about it the next time they ask, or the next time something breaks. In a compliant ICNLI implementation, the User Intelligence Profile refreshed in the background, noticed the threshold crossing, and the system reaches out on the actor's preferred channel: "Resource X has crossed threshold Y. Three remediation options are available; here are their impacts. Shall I proceed with option 2?" The actor authorizes — or doesn't — through the same TWO-STEP confirmation as any other consequential action. The system watches; the human authorizes. Proactive is not autonomous.

7. Intent Routing + Chain Orchestration¶

At Conformance Level 2 and above, the implementation MUST classify request intent and route to candidate operational domains before any tool is selected. The classifier passes only the relevant subset of tools to subsequent stages — the AI engine never sees the full registry; it sees the focused subset the router determined was relevant. Intent routing is the protocol's structural defence against tool mis-selection, and it is also a load-bearing input to the Anti-Fabrication Contract: a tool the model never sees cannot be invented. Cross-link: Intent Routing and Chain Orchestration.

Single-tool dispatch is the easy case. The interesting case is when a request resolves to more than one tool invocation — and here, ICNLI v2.0 introduces a normative architecture that closes a long-standing reliability hole in agent systems.

When a request resolves to multiple tools, the dispatch MUST be treated as a chain, and the chain MUST be executed through a single kernel-level orchestrator. Extensions MUST NOT implement private multi-tool orchestration loops; the orchestrator is the sole multi-tool dispatcher. This single-orchestrator rule is what prevents the architectural drift that has plagued ad-hoc agent loops: every extension trying to coordinate its own retries, its own dependency handling, its own confirmation semantics. The protocol mandates one orchestrator and one set of rules.

The orchestrator's contract has six normative components: a single orchestrator for all multi-tool dispatch; explicit dependency declaration by each step against prior steps by stable identifier; topological execution order computed before dispatch, with reads preceding dependent writes regardless of classified surface order; fail-fast on dropped destructive plans — a planned destructive step dropped during validation MUST surface a user-visible error, never silently fall back to a single-tool path; per-step audit emission for classification, dispatch, result, and confirmation; and TWO-STEP composition, with confirmation applied per-step at the safety classification of each step.

Beneath this, the protocol defines Step-Output References — the typed mechanism by which the output of step N flows into the input of a later step M. Implementations MAY choose any concrete syntax; the protocol mandates the semantics. References MUST identify their producer step unambiguously, MUST remain stable under topological reordering, and MUST be resolved at dispatch time using the verbatim output of the producer step from the fact ledger — never paraphrased, never summarized. A reference whose producer failed or was dropped MUST cause the dependent step to fail explicitly or seek confirmation, never to dispatch with placeholder data.

The cumulative effect is multi-step reliability that does not depend on the model getting a single forward pass right. The model proposes a plan; the orchestrator validates dependencies, orders the steps, binds references to verbatim outputs, gates confirmations at each safety level, and produces an audit trail. If the plan is incoherent, the orchestrator surfaces the incoherence before any state is changed.

In ICNLI, the model proposes; the orchestrator guarantees.

8. The Big AI Problems and How ICNLI Solves Them Structurally¶

The argument for ICNLI is not that it makes AI work better in some general sense. The argument is that five specific, named, well-known open problems in deployable AI — problems the foundation-model providers have been honest about — are addressable at the protocol layer with structural guarantees that the model layer, by its nature, cannot make. This chapter takes those five problems one at a time. The compact, punch-list version of this argument lives at The 5 AI Problems Bounded; the narrative form is here.

8.1 Hallucination → Anti-Fabrication Contract¶

The industry has spent years trying to reduce hallucination inside the model. RLHF reduces it; constitutional methods reduce it; grounding prompts reduce it. None of these eliminate it, and none can — a probabilistic generator can in principle produce a well-formed, plausible, false sentence on any forward pass.

The structural insight is that the problem does not need to be solved inside the model. It can be bounded outside the model. ICNLI's Anti-Fabrication Contract has four normative components at every conformance level: a per-session fact ledger recording every tool's structured output verbatim and making it available to the model on subsequent turns; a grounded narration requirement under which the system MUST NOT claim a tool produced a value not in that tool's output, MUST NOT quantify a result not enumerated in the underlying facts, and MUST NOT attribute a status to a resource whose status was not retrieved; intent-routed tool selection that structurally prevents the model from invoking tools outside the routed subset (a tool the model never sees cannot be invented); and a PII masking gate that masks personally identifiable information by default.

What makes this defensible against a hostile reviewer is that the contract does not depend on the model being well-behaved. The fact ledger is enforced by the kernel. The grounded-narration check is enforced outside the model. The tool surface is determined by the router before the model sees it. The model can still be wrong; the system cannot fabricate ungrounded claims. The system's output is bounded by construction.

8.2 AI Control & Safety → TWO-STEP Architectural Human-in-the-Loop¶

Foundation-model providers have invested heavily in refusal training and constitutional methods — real, valuable work at the model layer. It is also statistical, which means it can in principle be bypassed by clever input. Every published jailbreak is a proof of that property.

For consequential operations, statistical refusal is the wrong primitive. The right primitive is architectural. ICNLI mandates TWO-STEP confirmation for every state-changing operation: the system proposes with impact analysis, the actor confirms, and only then does the system execute. The confirmation gate is enforced by the kernel and is outside the model's authority — no prompt can talk the kernel out of asking. Beyond TWO-STEP, the protocol classifies every tool by safety level 0–4, escalates confirmation with level, mandates impact analysis from L2 upward, requires explicit danger phrases for CRITICAL operations, and enforces role-based access on every dispatch. Cross-link: Safety Layer.

The distinction matters because architectural human-in-the-loop is deterministic, while refusal training is probabilistic. Both have value. They occupy different layers. ICNLI mandates the architectural layer because that is the layer where deterministic guarantees are possible.

8.3 Memory & Context Persistence → 9-Level Context + User Intelligence Profile¶

A context window is not memory. Long-context windows, RAG, and vector stores are valuable engineering tools, but none of them are a structured per-actor awareness model that lives across sessions and channels and survives a model upgrade.

ICNLI's structural answer is the 9-level context model as a normative substrate, plus the User Intelligence Profile from the proactive layer. Together they constitute a kernel-grade memory primitive — every layer resolved structurally, every layer survives the session, the User Intelligence Profile refreshes in the background, and the fact ledger preserves verbatim tool outputs across turns. The defence against a hostile reviewer is that this is not retrieval, it is architecture: the structured context is the kernel's responsibility, and a model can be swapped underneath without losing the actor's memory, because the memory was never inside the model.

8.4 Multi-step Agent Reliability → Chain Orchestration¶

Every agent framework worth taking seriously — and several of them are doing excellent work at the library layer — has invented its own answer to multi-step coordination. Each invention re-implements safety, dependency handling, retry semantics, and confirmation differently, and each framework's reliability is bounded by the brittleness of its loop.

ICNLI defines the answer once, at the protocol layer. Chain orchestration is normative at Level 3 with the six components covered in Section 7: single orchestrator, explicit dependency declaration, topological execution, fail-fast on dropped destructive plans, per-step audit, and TWO-STEP composition. Step-Output References preserve verbatim data flow between steps and resolve stably under topological reordering. The defence against a hostile reviewer is that this is a contract, not a library — the protocol promises the semantics any orchestrator must satisfy, not a particular implementation. That is the right shape for a standard.

8.5 Privacy → Architectural Data Boundary, Not Policy¶

Privacy at the model layer is a promise: the provider promises not to log, not to train on, not to retain. Promises can be broken, audited, regulated — none of those mechanisms produce a deterministic guarantee that private data did not transit a path it should not have transited.

ICNLI's structural answer is that privacy is a property of the data path, and the protocol controls the data path. The PII masking gate in the Anti-Fabrication Contract mandates that personally identifiable information MUST be masked in context delivered to the model by default; exposure MUST be opt-in, configurable at deployment time, and auditable. The 9-level context model is permission-filtered before it reaches the model. The audit substrate records what was sent, what was masked, and who authorized any unmasking. The architecture supports on-premises deployment for domains that require it. The defence against a hostile reviewer is that this is the only layer at which privacy is a property rather than a policy — the model cannot un-see what was sent to it, the protocol controls what is sent, and the protocol mandates that the boundary be enforced.

What the data-path boundary does not, on its own, solve. The protocol is honest about which privacy threats the masking gate bounds and which require separate apparatus:

Quasi-identifier deanonymization. Job title + region + uncommon incident may re-identify an actor even without name or email. PII masking on overt identifiers does not eliminate inferential re-identification — that is a separate domain modelling concern.
Insider threat via extensions. A malicious or compromised extension with declared permissions can still exfiltrate within its declared scope. This is addressed by the extension permission scoping, declared-capability boundaries, and audit substrate — not by PII masking alone.
Prompt-injection attacks on masking logic. Crafted user input attempting to instruct the system to bypass masking is bounded by the kernel's masking enforcement being outside the model's authority (the model cannot disable the gate), but adversarial robustness of the masking layer itself is a separate threat-model concern.
Telemetry leakage. PII MUST NOT appear in metric labels (§12.1 of the specification). Identifying values belong in trace attributes and audit records, not on metric series. Operators are responsible for storage-side protection of those records.
Storage-side exposure of the audit substrate. The tamper-evident hash chain protects against modification, not against unauthorized read access to the persisted records. Operators are responsible for storage-side encryption, retention, and access control.

The PII masking gate is necessary but not sufficient. The full privacy posture of a compliant implementation is the data-path boundary plus the Security Considerations of §14 of the specification, extension permission scoping, role-based access enforced on every dispatch, and operator-side deployment hardening. The specification is explicit about which is which, and the audit trail makes any privacy event reconstructable after the fact.

8.6 The meta-claim¶

The pattern repeats across all five problems. The model layer attempts to address them probabilistically; the protocol layer addresses them structurally. Both have value. Probabilistic methods can reduce frequency; structural methods can establish guarantees. The two are not in opposition. They are complementary layers. ICNLI is the layer at which a serious deployment of AI in a real domain inherits structural guarantees the model alone cannot provide — and any compliant ICNLI implementation MAY use any underlying foundation model. The protocol is implementation-neutral by design.

9. Anti-Fabrication Contract¶

The Anti-Fabrication Contract is treated separately from the Safety Layer because its concerns are different in kind. Safety governs what the system is allowed to do. Anti-fabrication governs what the system is allowed to say. Both are normative at every conformance level. Cross-link: Anti-Fabrication Requirements.

The contract has four components. Cross-turn fact preservation records every tool dispatch's structured output verbatim into a per-session fact ledger and makes the ledger available to the model on subsequent turns; the model MUST be instructed to prefer verbatim facts over paraphrased prose from earlier turns, and the ledger MUST be bounded by a per-turn aggregation cap so long sessions do not exhaust the context budget. Grounded narration binds user-facing prose to facts present in the current turn's dispatch results or in the ledger; the implementation MUST NOT permit narration to claim a tool produced a value not in that tool's output, quantify a result not enumerated in the underlying facts, or attribute a status to a resource whose status was not retrieved. Intent-routed tool selection restricts the model's tool surface to the classifier-selected subset; tools outside that subset are structurally unreachable for the current request. The PII masking gate masks personally identifiable information in context delivered to the model by default; exposure is opt-in, configurable, and auditable.

A point worth dwelling on: classifier intent routing is not only a precision optimization. It is an anti-fabrication primitive. A model that cannot see a tool cannot invent a call to it. The router is the kernel's mechanism for shaping the surface area in which fabrication is even arithmetically possible. Combined with the fact ledger and grounded narration, the result is a chat surface whose claims are bounded by what the system actually retrieved — the model can be wrong; the system cannot fabricate ungrounded claims**.

Limitations and roadmap¶

The Anti-Fabrication Contract is precise about what it guarantees and what it does not. We state this explicitly because every strong claim in this document is fence-bounded. There are three distinct layers; they are not the same architectural class, and conflating them was historically a marketing error.

Structurally guaranteed (kernel-enforced, model-independent). Three primitives in this class:

Fact ledger. Tool-call output is preserved verbatim in the fact ledger across turns. The narrator cannot invent a value that has no source in the ledger and cannot quietly substitute one value for another — the audit hash chain reveals the substitution.
Intent-routed tool surface. The kernel decides which tools the model sees on each request via classifier output before any tool call is composed. A tool the model never sees cannot be invoked; this removes entire classes of fabricated tool calls at the surface, not at the output.
PII masking gate. Personally identifiable information is filtered out of context delivered to the model by default; unmasking is explicit, opt-in, and audited. The model cannot un-see what was sent — so what is sent is bounded structurally.

These three are structural in the precise sense: they hold regardless of whether the model is well-behaved, regardless of which model is loaded, and regardless of whether any downstream LLM-based judge is correct. They survive judge failure.

Contractually enforced (runtime judges, currently LLM-based). One layer in this class:

Grounded narration. A normative MUST against claiming values, quantifications, or statuses not present in the underlying facts. Compliant implementations enforce this through dedicated runtime judges — at v2.0 these are LLM-based and therefore probabilistic. The judge operates on a smaller residual surface area than the model alone, because the structural primitives above have already removed entire fabrication classes from the input. But the judge itself is not a structural guarantee; calling it one would be the same probabilistic-dressed-as-deterministic move we criticize at the model layer. Formal-grammar enforcement and symbolic intermediate representation are the v2.1+ research direction.

Not yet formally proven. Strict mathematical impossibility of fabrication would require either (a) constrained natural-language generation against a formal grammar, or (b) a symbolic intermediate representation rather than free-form text emitted by the model. Neither is normatively required by v2.0. Both are open research directions. A compliant v2.0 implementation reduces ungrounded fabrication to a low residual surface area but does not eliminate it as a category in the mathematical sense.

What we commit to. When the residual surface is measured against a labeled corpus by a compliant implementation, we publish the rate. We do not claim impossibility before we can publish a proof. We do not call a probabilistic runtime judge a structural guarantee. The line is published here, in normative text, so any reader can hold us to it.

10. Safety by Architecture¶

The protocol's Safety Layer is the most concrete normative apparatus in the specification — where the difference between "AI that helps" and "AI that ships into a regulated domain" is decided. Cross-link: Safety Layer.

Every tool MUST be classified by safety level: 0 (READ — no side effects), 1 (SAFE_WRITE — reversible), 2 (WRITE — routine), 3 (DANGEROUS — potentially destructive), 4 (CRITICAL — irreversible). Confirmation escalates with level: optional at L1, TWO-STEP at L2, TWO-STEP with impact details at L3, danger-phrase-plus-cooling-period at L4. Audit is mandatory from L1 upward; backups are recommended at L2 and required at L3 and L4. Impact analysis MUST be performed and presented before proposing any operation at L2 or above, enumerating direct targets, cascade targets derived from L7/L8 context, reversibility, and backup availability.

For CRITICAL operations, the implementation MUST require a danger phrase demonstrating the actor understands what is about to occur — typically the target identifier or equivalent that cannot be produced by accidental typing. The cooling period (≥30 seconds at L4) is deliberate friction designed to make irreversible operations take more time than reversible ones. Role-based access is enforced on every dispatch; the canonical example roles (guest, client, admin) are illustrative, and every dispatch is checked, every authorization failure is logged, every role has a defined safety ceiling.

The cumulative shape: consequential actions take confirmation, destructive actions take impact analysis, critical actions take a danger phrase and a cooling period, every dispatch carries an audit record. AI assists; human decides; protocol enforces.

11. Channel Neutrality¶

A compliant implementation MUST support at least one channel and SHOULD support multiple with equivalent functionality. Capabilities MUST be equivalent across supported channels; response form MAY differ. Web, messaging, voice, API, terminal are examples, not a closed list. At Conformance Level 3, cross-channel continuity is mandatory: an actor begins a conversation on one channel and continues it on another with full preservation of context and the fact ledger. Voice channels require audio-appropriate phrasing, spell-out of confusable values, audio confirmation before destructive actions, and support for actor interruption. Protocol semantics — TWO-STEP, intent routing, chain orchestration, anti-fabrication — MUST remain identical across channels. The channel is the surface; the protocol is the substrate. Cross-link: Channel Support.

12. Observability + Audit¶

A Modular Proactive AI Cloud OS deployed in a real domain — especially a regulated one — needs telemetry by default, not as an afterthought. ICNLI v2.0 raises observability from advisory to normative. Cross-link: Observability and Audit Requirements.

The protocol mandates three pillars plus an audit trail. Structured metrics for core protocol events — request received and classified, tool dispatched with safety level, confirmation issued/accepted/expired/rejected, chain step started/completed/failed, alert emitted. PII MUST NOT appear in label values. Distributed traces SHOULD be emitted in OpenTelemetry-compatible form, covering the lifetime of a request, each classification step, each tool dispatch, and each chain step, with trace identifiers correlated to logs. Structured logs MUST be emitted in JSON or an equivalent format and MUST include the trace identifier of the active span. The audit trail MUST be sufficient to reconstruct after the fact what was asked, how it was classified, what was dispatched, what was confirmed, and what was produced — and MUST be tamper-evident.

One operational point is easy to get wrong: telemetry failure MUST NOT break the request path. A broken metrics backend, a degraded tracing collector, an unreachable log target — none of these MUST be permitted to break the OS. A broken collector cannot be permitted to break the operating system.

13. The ICNLI 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. Each layer below it has a name, and each one is publicly available today.

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 and constitute the v2.0 proving ground.

ICNLI — the protocol. The open specification, the normative RFC2119 contract, and the design rationale published in this whitepaper. Licensed CC BY-SA 4.0; trademark held by Imperal, Inc. Any organization may implement; any compliant implementation may use any underlying foundation model.

imperal.io — the ICNLI Engine. Available at imperal.io. The reference implementation that turns the open specification into a running operating system. As Linux is to POSIX, imperal.io (Imperal Cloud) is to ICNLI: the first ICNLI AI Cloud OS — 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; no automated conformance test suite has shipped yet — that is the v2.1 critical-path deliverable) in production today. imperal.io implements the protocol at Conformance Level 3: 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 with tamper-evident audit. imperal.io served as the reference deployment against which ICNLI v2.0 was specified — 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 (e.g., extensions must use ctx.api, must declare safety levels, must not embed orchestration loops); 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 its existence is the empirical proof that the kernel surface is a contract, not a private API. Package on PyPI; reference and quickstart on docs.imperal.io.

Webbee — the reference agent. 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 the User Intelligence Profile, anticipates thresholds, surfaces concerns, and proposes remediations through the same TWO-STEP gate as any actor-initiated dispatch.

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 validator processed 273,576 extension submissions in a representative seven-day window in May 2026 — that is real developers iterating against the contract upstream of production. The kernel surface is the contract; the extension surface is where the marketplace will live.

WebHostMost — the first enterprise production deployment. Available at webhostmost.com. 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, every email and storage operation — 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), with the full safety apparatus, proactive intelligence, and audit substrate active. 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 for transparency, and the path to independent enterprise customers is on the open-standard roadmap in §15.

The six together — protocol, engine, developer SDK, reference agent, extensions catalog, first enterprise production deployment — constitute the proof-of-life. ICNLI v2.0 is not a hypothesis. It is a description of a stack that exists.

13.5 What we measure — and what we publish¶

The protocol's credibility depends on being honest about both what works and what we cannot yet prove. Below are the operational metrics from imperal.io as deployed by its first enterprise client, WebHostMost, captured during a representative seven-day window in May 2026. These are first-published numbers; we expect them to evolve as the platform matures.

What we measure¶

Metric	Observed value	What it means
Chat turn success rate	93.2% (2,530 success / 185 error)	Turns that completed without protocol-level error. Errors include classifier confidence too low, tool dispatch failure, downstream timeout.
Intent classification distribution	read 79.0% · write 18.3% · destructive 2.6%	The classifier's output across all turns. Destructive intents — the ones that hit TWO-STEP gating — are a small minority of traffic, but the entire 2.6% routes through architectural confirmation regardless of model behaviour.
Multi-step chain executions	1,203 chain steps	Real multi-tool orchestration. Each step routes through dependency resolution, read-before-write semantics, and per-step safety classification.
Anti-fabrication judge invocations	726	Independent runtime grounding checks (multi-gate). Currently shadow-running in audit mode — measurements are collected, blocking enforcement is staged for v2.1.
Protocol contract violations caught	17 (0.63% of turns)	Runtime detection of protocol violations during dispatch. These are caught and surfaced; the production rate is low and trending down as the contract surface stabilises.
Validator-surface activity	273,576 submissions (over the same window)	Extension submissions to the Developer Portal evaluated by the v5.X validators (manifest schema, signature checks, declared-capability boundaries). Most are pre-submission CI iterations from a small in-house developer team (on the order of 1–10 unique authors over the window) — this is a measure of validator-surface activity and contract enforcement upstream of production, not a marketplace-developer count. The headline number reflects CI throughput, not adoption.
Chat turn latency	p50 ~1s · p95 ~9s · p99 ~20s	End-to-end response time including any multi-step chain orchestration and grounded narration. The long tail reflects multi-step chains that genuinely take that long; the contract does not optimise for sub-second answers when correctness requires more work.

What we do NOT yet publish — explicit gaps¶

Confirmation accept/reject ratio per safety level. The audit-event counter does not yet differentiate accepted vs rejected confirmations as a separate label. Adding it is straightforward and on the v2.1 roadmap.
Per-tool action success rate. We can observe dispatch totals and overall chain success, but per-extension success-by-tool breakdown requires per-tool labels that are not all populated yet.
Hallucination ground-truth rate. This requires a labelled corpus — a stable set of inputs with expected outputs against which we can measure how often the system's claim deviates from truth. We do not have a published corpus; the v2.1 roadmap commits to publishing both a baseline corpus and our system's measured rate on it. Until then, the figure we publish is the anti-fabrication judge rejection rate in shadow mode (the percentage of narrations the judge would have blocked if running in enforce mode) — which is a useful operational signal but not a ground-truth accuracy measurement.
Independent third-party benchmark. No external benchmark is available because no third-party implementation exists yet. The first external implementation will be invited to publish its own metrics under the same schema; comparison will follow.

These gaps are real, named, and on the roadmap. The protocol does not benefit from claiming numbers we cannot defend; this section's purpose is to publish what we have and be honest about what we do not.

14. Use Cases — Applicability Across Domains¶

The standard does not know what "infrastructure", "patient", "transaction", "evidence record", or "shipment" means. It defines context levels, safety contracts, chain semantics, and proactive primitives. The domain is what an extension places inside those levels. This section enumerates applicability examples — operational verticals whose requirements the architecture is designed to satisfy. Inclusion in this list is not a deployment claim.

What is deployed today: Hosting (WebHostMost, in production). What is applicability example only (no production deployment today): every other vertical listed below.

Domain	Architectural applicability
Hosting (deployed at WebHostMost)	Servers, websites, databases, DNS, SSL, email — managed conversationally with cascade-impact analysis and TWO-STEP confirmation.
Healthcare (applicability — no deployment)	Patients, medications, devices, schedules — clinical decision support with full consequence mapping before action.
Finance (applicability — no deployment)	Accounts, transactions, exposures, compliance windows — back-office operations with auditable execution and role-bounded authorization.
Smart City (applicability — no deployment)	Sensors, signals, services, dependencies — coordinated responses with the human in control of every dispatch.
Government (applicability — no deployment)	Cases, records, parties, decisions — auditable decision substrate with privacy enforcement by architecture.
Defense (applicability — no deployment)	Assets, missions, dependencies, escalations — air-gapped deployment with on-premises observability and tamper-evident audit.
Manufacturing (applicability — no deployment)	Lines, batches, equipment, inventories — operational intelligence with proactive anomaly surfacing and gated control.
Logistics (applicability — no deployment)	Shipments, hubs, routes, exceptions — coordination with cross-channel continuity and cascade-impact reasoning.

The standard's shape is invariant across these domains; the extensions and the context payload are not. Same kernel; different surface. Domain agnosticism is a normative principle of the specification (Core Principle 8) — the core MUST NOT encode assumptions about any specific operational domain. That is an architectural property, not a deployment claim. Each non-hosting vertical above is listed for architectural applicability — to communicate where the protocol's properties would apply if deployed — not as a claim that ICNLI is in production in that domain. This whitepaper will move a domain from "applicability example" to "deployed" only when, and only after, an independent third-party deployment in that domain exists. The current list of verticals with a live deployment is: hosting (WebHostMost).

15. Open Standard Strategy¶

ICNLI v2.0 is published as an open specification under CC BY-SA 4.0. The trademark is held by Imperal, Inc.

Current state (May 2026). One specification author. One flagship implementation (imperal.io). One enterprise client running it in production (WebHostMost). This is the starting state for every protocol that becomes a standard: HTTP began at CERN, TCP/IP among DARPA contractors, MCP at Anthropic. The path from single-vendor specification to genuine open standard is well-trodden and has clear milestones.

The path forward — three milestones in order.

1. Conformance test suite published. Target: v2.1 release, late 2026. Automated verification of every MUST and SHOULD clause in the specification, with reference fixtures and adversarial tests for the Anti-Fabrication Contract. Until this ships, "ICNLI-compliant" is a statement of intent; "ICNLI-certified" is a higher bar that requires passing the suite.

2. At least three independent compliant implementations. Target: by end of 2027. From organizations unaffiliated with Imperal, Inc., each passing the conformance test suite. Independent implementations are the empirical proof that the specification is implementable from the document alone.

3. Governance transfer to a neutral foundation. Target: when milestones 1 and 2 are met. The trademark and the specification's evolution process move to a neutral foundation with public RFC procedure, working groups, and multi-organization representation. Imperal, Inc. retains its implementation; the standard is no longer its property.

Until all three milestones are achieved, ICNLI is honestly described as a vendor-authored open specification with multi-vendor governance as a stated commitment, not a present claim. Readers and adopters should weight that distinction accordingly.

The CC BY-SA license guarantees that the specification text cannot be locked behind a single vendor. The trademark guarantees that the name carries integrity meaning during the transition. Both are intentional.

16. Future Roadmap¶

The roadmap is deliberately conservative. The protocol is too young to make speculative product announcements. The commitments below are bounded.

Short-term (remainder of 2026). Continued specification refinement based on production feedback from compliant implementations. Reference materials and conformance documentation expanded. Outreach to standards bodies and to domain communities (healthcare, finance, smart city) where the protocol's structural guarantees are most consequential.

Medium-term (2027). Publication of a conformance test suite usable by any implementer to self-attest against Levels 1–3. Engagement with third-party implementations beyond the flagship. Domain extension catalogs maintained by domain-expert communities.

Long-term. Industry-vertical extensions — specifications layered on top of the core protocol for specific regulated domains where additional normative requirements (data residency, regulator-specific audit shapes, sector-specific danger phrases) are warranted. The core protocol stays domain-agnostic; the verticals attach to it.

No promises beyond what can be defended. The protocol's credibility is its only marketing asset.

16.5 Standards Engagement and Research Collaboration¶

ICNLI is published as an open specification (CC BY-SA 4.0) precisely so that engagement, critique, and contribution from outside Imperal, Inc. can shape its evolution. The following channels are open:

For standards bodies (IETF, W3C, ISO/IEC, IEEE, CNCF, Linux Foundation AI & Data). ICNLI's open-standard milestones (§15) commit to governance transfer to a neutral foundation when independent implementations and a conformance test suite ship. Interested working groups, RFC editors, and foundation program directors are invited to contact license@icnli.org to discuss hosting, collaboration, or formal submission process. The specification text is liberal-license; the path is open.

For AI safety, alignment, and frontier-model research groups (Anthropic, Google DeepMind, OpenAI, Microsoft Research, academic AI safety labs). ICNLI's Anti-Fabrication Contract, TWO-STEP human oversight, and the structural/contractual scope distinction in §7.7 represent applied research artifacts that compose with — not compete against — model-layer alignment work. Collaboration on adversarial conformance testing, runtime grounding judges, formal-grammar enforcement, and benchmark corpora is explicitly invited. The protocol is implementation-neutral by design: any underlying foundation model may be used, and the structural primitives survive a model swap.

For regulators and policy authors (NIST, EU AI Office, ICO, ISO TC 42 AI, sector-specific regulators). The Compliance & Regulatory Mapping page enumerates how ICNLI's normative MUSTs correspond to NIST AI RMF, EU AI Act, ISO/IEC 42001, FedRAMP, DoD readiness, and MITRE ATLAS. Regulatory consultation on protocol-level vs implementation-level boundaries is invited; the specification text is publicly auditable.

For independent implementers and toy reference projects. A second implementation — even a research-grade subset — is the single most valuable contribution toward open-standard status. The CC BY-SA license permits unlimited reproduction; the trademark protects the name's integrity for conformance claims. Implementers willing to publish their conformance self-assessment as a checklist against the specification text are invited to do so under a "v2.0 compliant (self-attested)" claim.

The protocol's credibility is a function of the work invited above. Engagement is the path.

16.6 Citation¶

For academic, regulatory, or industry citation:

@techreport{icnli-spec-2026,
  author    = {Scerbacov, Valentin},
  title     = {ICNLI Specification v2.0 — Infrastructure Contextual Natural Language Interface: The Open Protocol for Modular Proactive AI Cloud Operating Systems},
  institution = {Imperal, Inc.},
  year      = {2026},
  month     = {5},
  url       = {https://icnli.org/icnli-specification/},
  type      = {Open Specification},
  note      = {First created 30 December 2025 (v1.0.0). Licensed under CC BY-SA 4.0}
}

@techreport{icnli-whitepaper-2026,
  author    = {Scerbacov, Valentin},
  title     = {ICNLI Whitepaper v2.0 — The Open Protocol for Modular Proactive AI Cloud Operating Systems},
  institution = {Imperal, Inc.},
  year      = {2026},
  month     = {5},
  url       = {https://icnli.org/icnli-whitepaper/},
  type      = {Whitepaper},
  note      = {First created 30 December 2025 (v1.0.0). Licensed under CC BY-SA 4.0}
}

Suggested in-text citation: ICNLI v2.0 (Scerbacov, 2026; first created 30 December 2025) — open specification, CC BY-SA 4.0, icnli.org.

17. Conclusion + Invitation¶

ICNLI is the open standard — a behavioral specification in the POSIX / OpenAPI / ANSI SQL standards category — for a class of system this whitepaper calls a Modular Proactive AI Cloud OS: Modular because the kernel is finite and the extension surface is unbounded; Proactive because the system watches and proposes while the human authorizes; AI Cloud OS because AI is the primary operational user of the system (with the human as authorizing principal — see §8 Safety Layer of the specification), and context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives. The specification is normative, the reference implementation exists, the first enterprise production deployment runs against it. ICNLI is currently in the anticipatory-standard phase — the same stage MCP is in today at Anthropic, the same stage Python was in for its first 17 years, the same stage POSIX was in before formal IEEE adoption. Explicit non-claims: ICNLI does not claim wire-level interoperability between independent implementations today, does not claim multi-vendor de facto standard status today, does not claim certified conformance, and does not claim production deployment in any vertical other than hosting today. The path toward de facto standard (multi-vendor adoption) and de jure standard (neutral foundation governance) is documented in §15 with explicit dated milestones. The full standards-category argument lives in Comparisons §9.

The invitation is to four audiences. Domain experts who understand a field deeply and want to make it intelligently operable — the protocol is the substrate, the extension contract is your interface. AI engineers building systems that need structural guarantees the model alone cannot provide — the conformance levels are your checklist. Organizations considering AI for a regulated or consequential domain — the safety apparatus, audit substrate, and architectural privacy boundary are what make the deployment defensible. Standards bodies considering how the next decade of AI infrastructure will be governed — the specification is published, the license is liberal, the conversation is open.

Read the ICNLI Specification v2.0 for the normative contract. Read The 5 AI Problems Bounded Structurally for the deck argument in punch-list form. Build against the protocol. Ship into your domain. The bottleneck of useful AI in 2026 is no longer the model — it is the protocol around the model, and the protocol now exists.

Appendix: Glossary¶

Term	Definition
ICNLI	Infrastructure Contextual Natural Language Interface — the open standard (a behavioral specification in the POSIX / OpenAPI standards category) defined in the specification document under CC BY-SA 4.0.
Modular	Architectural property by which extensions, channels, tools, and domains plug into a stable kernel through declared contracts.
Proactive	Architectural property by which the system watches its domain and surfaces concerns or proposals without being prompted.
AI Cloud OS	Class of system in which AI is the primary operational user — the runtime client of OS primitives — with the human as the authorizing principal for every consequential action. Context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives. The OS inversion is about who the system is built for at runtime, not who holds authority over what it executes.
Kernel	The finite, stable orchestration core of a compliant implementation.
Extension	Pluggable unit that contributes domain-specific tools, panels, or capabilities to the kernel via a declared manifest.
Actor	The authenticated entity initiating requests — a human user, a service, or an authorized system.
Channel	A communication interface (web, messaging, voice, API, etc.) through which actors interact with the system.
Context	Structured awareness of the domain state relevant to an actor and their request.
Context Level	A layer in the 9-level hierarchical context model (L0–L8).
Conformance Level	The published level (1, 2, or 3) of normative requirements an implementation satisfies.
Tool	A defined executable function with typed parameters, a safety classification, and required permissions.
Mutation	Any operation that changes domain state.
TWO-STEP	The mandatory confirmation pattern: Propose (with impact analysis) → Confirm → Execute.
Safety Level	The risk classification (0–4) of a tool or operation.
Intent Domain Router	The classification layer that resolves which operational domains are relevant before tool selection.
Chain Orchestration	The kernel-level facility for executing a sequence of typed tool calls with declared dependencies, topological ordering, and read-before-write semantics.
Step-Output Reference	A vendor-neutral mechanism allowing the output of step N in a chain to flow into the input of a later step.
Anti-Fabrication Contract	The protocol-level requirement that the system's narration MUST be grounded in verifiable facts and MUST NOT claim results not present in the fact ledger.
Fact Ledger	The structured, per-turn record of verbatim tool outputs preserved across the session.
User Intelligence Profile	A continuously maintained awareness model of an actor and their domain state.
Observability	The protocol-level requirement that compliant implementations emit structured metrics, traces, and logs sufficient to operate and audit the system.

About the Author¶

Valentin Scerbacov is the creator of ICNLI and founder of Imperal, Inc. This whitepaper was developed alongside the v2.0 specification (ICNLI was first created on 30 December 2025 as v1.0.0) based on practical experience designing and operating a Modular Proactive AI Cloud OS in a first enterprise production deployment. The flagship implementation of ICNLI v2.0 is imperal.io (Imperal Cloud), the first ICNLI AI Cloud OS, with Webbee as its reference agent; WebHostMost is imperal.io's first enterprise client, running an ICNLI-compliant deployment across multi-region hosting infrastructure.

License¶

This whitepaper 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 whitepaper but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. Webbee™ is a trademark of WebHostMost.

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

Reproduction and adaptation of this whitepaper is freely permitted under CC BY-SA 4.0. Unauthorized use of the ICNLI™ trademark for branding, commercial purposes, or conformance claims — which is separate from the content license — may result in trademark enforcement action.

END OF WHITEPAPER