The Infrastructure Contextual Natural Language Interface (ICNLI): An Open Protocol for Modular Proactive AI Cloud Operating Systems
draft-scerbacov-icnli-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Valentin Scerbacov | ||
| Last updated | 2026-06-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-scerbacov-icnli-00
Network Working Group V. Scerbacov
Internet-Draft Imperal, Inc.
Intended status: Informational 14 June 2026
Expires: 16 December 2026
The Infrastructure Contextual Natural Language Interface (ICNLI): An
Open Protocol for Modular Proactive AI Cloud Operating Systems
draft-scerbacov-icnli-00
Abstract
This document describes the Infrastructure Contextual Natural
Language Interface (ICNLI), an open protocol that defines how an
artificial intelligence (AI) agent operates as a first-class
participant inside a real-world operational system. ICNLI specifies
a hierarchical context model, request classification and a two-step
confirmation pattern for state-changing operations, multi-step chain
orchestration with read-before-write semantics, an anti-fabrication
contract that binds narration to verifiable facts, a graduated safety
layer, a modular extension contract, proactive-intelligence
requirements, channel neutrality, and observability and audit
primitives, organized into three cumulative conformance levels. The
protocol is domain-agnostic, channel-neutral, and implementation-
neutral; a compliant implementation MAY use any underlying foundation
model.
This Internet-Draft is a faithful rendering, for the IETF community,
of the ICNLI Specification version 2.0.0 published by its author. It
is an individual submission and a work in progress with an intended
status of Informational. It does not represent IETF consensus, is
not a standards-track document, and makes no claim of IETF adoption.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Scerbacov Expires 16 December 2026 [Page 1]
Internet-Draft ICNLI June 2026
This Internet-Draft will expire on 16 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Design Goals . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Acronym Etymology and Domain Scope . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Conformance Keywords . . . . . . . . . . . . . . . . . . 7
2.2. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Core Principles . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Principle 1: Context is Primary . . . . . . . . . . . . . 10
3.2. Principle 2: Modular Composition . . . . . . . . . . . . 10
3.3. Principle 3: Proactive Awareness . . . . . . . . . . . . 10
3.4. Principle 4: Safety by Design . . . . . . . . . . . . . . 10
3.5. Principle 5: Channel Neutrality . . . . . . . . . . . . . 11
3.6. Principle 6: Transparency . . . . . . . . . . . . . . . . 11
3.7. Principle 7: Graceful Degradation . . . . . . . . . . . . 11
3.8. Principle 8: Domain Agnosticism . . . . . . . . . . . . . 11
4. Context Model . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Context Hierarchy . . . . . . . . . . . . . . . . . . . . 11
4.2. Why Nine Levels . . . . . . . . . . . . . . . . . . . . . 12
4.3. Context Requirements by Conformance Level . . . . . . . . 14
4.4. Context Resolution . . . . . . . . . . . . . . . . . . . 14
5. Interaction Protocol . . . . . . . . . . . . . . . . . . . . 15
5.1. Request Types . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Request Classification . . . . . . . . . . . . . . . . . 16
5.3. Two-Step Confirmation Protocol . . . . . . . . . . . . . 17
5.4. Confirmation Tokens . . . . . . . . . . . . . . . . . . . 17
6. Intent Routing and Chain Orchestration . . . . . . . . . . . 18
6.1. Intent Routing . . . . . . . . . . . . . . . . . . . . . 18
Scerbacov Expires 16 December 2026 [Page 2]
Internet-Draft ICNLI June 2026
6.2. Domain Registry . . . . . . . . . . . . . . . . . . . . . 18
6.3. Chain Orchestration . . . . . . . . . . . . . . . . . . . 19
6.4. Step-Output References . . . . . . . . . . . . . . . . . 19
7. Anti-Fabrication Requirements . . . . . . . . . . . . . . . . 20
7.1. Cross-Turn Fact Preservation . . . . . . . . . . . . . . 20
7.2. Grounded Narration . . . . . . . . . . . . . . . . . . . 20
7.3. Intent-Routed Tool Selection . . . . . . . . . . . . . . 21
7.4. PII Masking Gate . . . . . . . . . . . . . . . . . . . . 21
7.5. Scope of Guarantee . . . . . . . . . . . . . . . . . . . 21
8. Safety Layer . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Safety Classification . . . . . . . . . . . . . . . . . . 22
8.2. Safety Requirements by Level . . . . . . . . . . . . . . 23
8.3. Impact Analysis . . . . . . . . . . . . . . . . . . . . . 23
8.4. Danger Phrases . . . . . . . . . . . . . . . . . . . . . 23
8.5. Role-Based Safety . . . . . . . . . . . . . . . . . . . . 23
9. Modular Extension Contract . . . . . . . . . . . . . . . . . 23
9.1. Modular Composition Pattern . . . . . . . . . . . . . . . 24
9.2. Extension Manifest Schema . . . . . . . . . . . . . . . . 24
9.3. Tool Registration . . . . . . . . . . . . . . . . . . . . 25
9.4. Extension Lifecycle . . . . . . . . . . . . . . . . . . . 25
10. Proactive Intelligence Requirements . . . . . . . . . . . . . 26
10.1. Background Context Refresh . . . . . . . . . . . . . . . 26
10.2. User Intelligence Profile . . . . . . . . . . . . . . . 26
10.3. Anomaly Surfacing . . . . . . . . . . . . . . . . . . . 27
10.4. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 27
11. Channel Support . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Channel Requirements . . . . . . . . . . . . . . . . . . 28
11.2. Standard Channels (Examples) . . . . . . . . . . . . . . 28
11.3. Channel Abstraction . . . . . . . . . . . . . . . . . . 28
11.4. Response Adaptation . . . . . . . . . . . . . . . . . . 28
11.5. Cross-Channel Continuity . . . . . . . . . . . . . . . . 28
11.6. Voice Considerations . . . . . . . . . . . . . . . . . . 28
12. Observability and Audit . . . . . . . . . . . . . . . . . . . 29
12.1. Structured Metrics . . . . . . . . . . . . . . . . . . . 29
12.2. Distributed Tracing . . . . . . . . . . . . . . . . . . 29
12.3. Structured Logs . . . . . . . . . . . . . . . . . . . . 29
12.4. Audit Trail . . . . . . . . . . . . . . . . . . . . . . 30
12.5. Audit Chain Tamper-Evidence . . . . . . . . . . . . . . 30
12.6. Fail-Soft Telemetry . . . . . . . . . . . . . . . . . . 31
13. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 31
13.1. Level 1 (Basic) . . . . . . . . . . . . . . . . . . . . 31
13.2. Level 2 (Standard) . . . . . . . . . . . . . . . . . . . 31
13.3. Level 3 (Advanced) . . . . . . . . . . . . . . . . . . . 31
13.4. Conformance Declaration . . . . . . . . . . . . . . . . 32
13.5. Current State of Conformance Verification . . . . . . . 32
14. Status of the Protocol and Relationship to Other Work . . . . 33
15. Security Considerations . . . . . . . . . . . . . . . . . . . 33
15.1. Authentication . . . . . . . . . . . . . . . . . . . . . 34
Scerbacov Expires 16 December 2026 [Page 3]
Internet-Draft ICNLI June 2026
15.2. Authorization . . . . . . . . . . . . . . . . . . . . . 34
15.3. Input Validation . . . . . . . . . . . . . . . . . . . . 34
15.4. Data Protection . . . . . . . . . . . . . . . . . . . . 34
15.5. Audit Integrity . . . . . . . . . . . . . . . . . . . . 34
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
17. Normative References . . . . . . . . . . . . . . . . . . . . 35
18. Informative References . . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
The normative source of truth for this protocol is the ICNLI
Specification version 2.0.0, published at https://icnli.org/icnli-
specification/ under the Creative Commons Attribution-ShareAlike 4.0
International License (CC BY-SA 4.0) and archived at Zenodo under DOI
10.5281/zenodo.20684403 [ICNLI-ZENODO]. This Internet-Draft is a
faithful rendering of that specification for the IETF community;
where this document and the published specification differ in
wording, the published specification governs. This document
deliberately omits operational metrics and any marketing framing; it
is a technical description of the protocol.
1.1. Purpose
The purpose of ICNLI is to define a protocol for AI agents that
operate as kernel-grade participants within real-world domains.
ICNLI establishes the architectural contract that a Modular Proactive
AI Cloud Operating System satisfies in order to be considered
compliant: how it acquires structured domain awareness, how it routes
natural-language intent, how it composes multi-step action chains
safely, how it preserves verbatim facts across turns, how it remains
channel-neutral, and how it produces audit-grade evidence of every
interaction.
A compliant implementation:
* Maintains hierarchical contextual awareness of its operational
domain.
* Classifies natural-language requests by intent before any tool
selection occurs.
* Executes consequential actions only with explicit human
confirmation (the two-step pattern).
* Composes multi-tool chains with explicit dependency declaration
and topological execution.
Scerbacov Expires 16 December 2026 [Page 4]
Internet-Draft ICNLI June 2026
* Preserves facts from prior turns verbatim and grounds narration in
those facts.
* Exposes at least one user-facing channel and SHOULD expose
multiple with equivalent functionality.
* Emits structured metrics, distributed traces, and structured logs
correlated by trace identifier.
* Provides a complete audit trail of every request, classification,
dispatch, and confirmation.
1.2. Scope
This document covers the 9-level context model and its resolution
algorithm; interaction patterns, request classification, and two-step
confirmation; intent routing and multi-step chain orchestration
semantics; anti-fabrication requirements binding narration to
verifiable facts; the safety classification taxonomy and graduated
response requirements; the modular extension contract; proactive-
intelligence requirements; channel abstraction and cross-channel
continuity; observability and audit primitives; and three conformance
levels with their cumulative requirements.
This document does NOT cover:
* The specific AI engine or foundation model implementation; any
compliant model MAY be used.
* Domain-specific operations, which belong to domain extensions
built on top of the protocol.
* User-interface design, which is handled by channel
implementations.
* Storage, networking, or process-orchestration architecture beneath
the protocol.
* Proprietary classifier, router, or execution mechanisms; only
their contracts are described.
Scerbacov Expires 16 December 2026 [Page 5]
Internet-Draft ICNLI June 2026
1.3. Motivation
Foundation models can reason, draft, summarize, and converse with
human-like fluency. Several open problems nonetheless remain
unsolved at the model layer because they are, by their nature, not
model problems but system problems. ICNLI addresses these system
problems with architectural commitments rather than by depending on a
particular model being well-behaved.
+===============+=================================================+
| Open problem | Why the model layer cannot solve it alone |
+===============+=================================================+
| Hallucination | Probabilistic generation can, by definition, |
| | fabricate. Structural guarantees on what a |
| | system claims must come from outside the model. |
+---------------+-------------------------------------------------+
| Multi-step | A single forward pass cannot reason about |
| reliability | transactional dependencies that span tools, |
| | time, and side effects. |
+---------------+-------------------------------------------------+
| Persistent | A context window is not memory; a protocol- |
| memory | level memory layer is required. |
+---------------+-------------------------------------------------+
| Safety and | Refusal training is statistical; architectural |
| control | human-in-the-loop is deterministic. |
+---------------+-------------------------------------------------+
| Privacy | Privacy is a property of the data path, not the |
| | model. A protocol that filters context before |
| | the model sees it can enforce privacy |
| | structurally. |
+---------------+-------------------------------------------------+
Table 1: System problems the model layer cannot solve alone
1.4. Design Goals
Domain-agnostic The protocol applies to any operational domain; no
domain assumptions appear in the core protocol.
Context-first Every interaction occurs within structured, multi-
level domain context, never blind.
Modular composition Extensions, channels, tools, and domains plug
into a finite kernel through declared contracts; the kernel
surface is stable, the extension surface is unbounded.
Proactive awareness At higher conformance levels, the system watches
Scerbacov Expires 16 December 2026 [Page 6]
Internet-Draft ICNLI June 2026
its domain, surfaces concerns, and proposes actions without
prompting.
Safe by default All state-changing operations require explicit human
confirmation; this is mandatory, not optional.
Channel-neutral Identical capabilities and identical context apply
across every supported communication interface.
Anti-fabrication The system grounds narration in verifiable facts
preserved across turns.
Auditable Every interaction, classification, dispatch, and
confirmation is logged.
Observable Structured metrics, traces, and logs are protocol-level
requirements, not optional add-ons.
Implementation-neutral Any AI engine, any storage system, and any
infrastructure MAY be used beneath the protocol.
1.5. Acronym Etymology and Domain Scope
ICNLI was coined in the infrastructure-operations domain: natural-
language interfaces for production hosting management. The acronym
preserves that origin and expands to Infrastructure Contextual
Natural Language Interface. This is the only permitted expansion of
the acronym.
The protocol's scope has since generalized. Every normative
requirement in this document is domain-agnostic by construction:
nothing in the context model, interaction protocol, safety layer,
anti-fabrication contract, chain orchestration, proactive-
intelligence requirements, or observability requirements is specific
to hosting, infrastructure, or any single vertical. The acronym is
not renamed for continuity with prior work; a future major version
MAY revise it if continuity ever costs more than clarity.
2. Terminology
2.1. Conformance Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Scerbacov Expires 16 December 2026 [Page 7]
Internet-Draft ICNLI June 2026
2.2. Key Terms
ICNLI Infrastructure Contextual Natural Language Interface; the open
protocol described herein.
Modular An architectural property by which extensions, channels,
tools, and domains plug into a stable kernel through declared
contracts. The kernel is finite; the surface is unbounded.
Proactive An architectural property by which the system watches its
domain, anticipates events, and surfaces concerns or proposals
without being prompted.
AI Cloud OS A class of system in which AI is the primary user.
Context resolution, intent routing, action execution, memory, and
audit are kernel-grade primitives.
Kernel The finite, stable orchestration core of a compliant
implementation, responsible for intent routing, action dispatch,
audit emission, recovery, and the lifecycle of extensions.
Extension A pluggable unit that contributes domain-specific tools,
panels, or capabilities to the kernel via a declared manifest.
Domain An operational environment: any field, industry, or system
the implementation manages.
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
through L8).
Tool A defined executable function with typed parameters, a safety
classification, and required permissions.
Channel A communication interface (for example web, messaging,
voice, or API) through which actors interact with the system.
Channel Neutrality The protocol property by which capabilities and
context are equivalent across channels.
Mutation Any operation that changes domain state.
Confirmation Explicit human approval required before executing a
mutation.
Two-Step The mandatory confirmation pattern: Propose (with impact
Scerbacov Expires 16 December 2026 [Page 8]
Internet-Draft ICNLI June 2026
analysis), then Confirm, then Execute.
Session A stateful interaction context maintained across one or more
requests.
Actor The authenticated entity initiating requests: a human user, a
service, or an authorized system.
Intent Domain Router A classification layer that resolves which
operational domains are relevant to a request 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 concept 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
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 and made available to subsequent
turns.
User Intelligence Profile A continuously maintained awareness model
of an actor and their domain state; the substrate for proactive
intelligence.
Observability The protocol-level requirement that compliant
implementations emit structured metrics, traces, and logs
sufficient to operate and audit the system.
3. Core Principles
ICNLI defines eight core principles. Every compliant implementation
MUST satisfy these principles directly or via the more specific
normative clauses in later sections.
Scerbacov Expires 16 December 2026 [Page 9]
Internet-Draft ICNLI June 2026
3.1. Principle 1: Context is Primary
Every ICNLI interaction MUST occur within a defined context. The
system MUST NOT process requests without first establishing actor
identity, actor permissions, and the resource context relevant to the
request. Blind execution against natural-language intent is non-
conformant. For example, a request to "delete the database" where
three databases match MUST be resolved by clarification, not by
guessing a target.
3.2. Principle 2: Modular Composition
A compliant implementation MUST be structured as a finite, stable
kernel plus a pluggable surface of extensions. Extensions declare
their tools, contributions, and required permissions through a
manifest contract (Section 9). The kernel MUST validate every
extension manifest before registration. Extensions MUST NOT be
permitted to alter kernel orchestration semantics. New domains,
channels, or capabilities SHOULD be added by registering new
extensions, not by modifying the kernel.
3.3. Principle 3: Proactive Awareness
A compliant implementation at Conformance Level 3 MUST maintain a
User Intelligence Profile that refreshes in the background,
independent of any incoming 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 the same as
autonomous: the system watches and proposes; the human authorizes.
3.4. Principle 4: Safety by Design
All state-changing operations MUST follow the two-step confirmation
pattern (Section 5). For operations classified above safety level 1,
the system MUST analyze and present impact before requesting
confirmation. For CRITICAL operations (level 4), the system MUST
require a danger phrase that demonstrates the human understands what
is about to occur.
Scerbacov Expires 16 December 2026 [Page 10]
Internet-Draft ICNLI June 2026
3.5. Principle 5: Channel Neutrality
A compliant implementation MUST expose at least one channel and
SHOULD expose multiple. Functionality MUST be equivalent across
channels: a user able to perform an operation on one channel MUST be
able to perform it on any other supported channel. Response form MAY
differ; protocol semantics MUST NOT.
3.6. Principle 6: Transparency
The system MUST be transparent about what it knows, what it intends
to do, what it actually did, and what it cannot do. Every state-
changing dispatch MUST be auditable. Every classification decision
SHOULD be inspectable in debug or audit mode.
3.7. Principle 7: Graceful Degradation
When context is incomplete or uncertain, the system MUST clearly
state what is unknown, MUST ask clarifying questions, and MUST NOT
assume or guess for destructive operations. For low-confidence
classifications targeting state-changing operations, the system MUST
request clarification rather than execute speculatively.
3.8. Principle 8: Domain Agnosticism
The core protocol MUST NOT encode assumptions about any specific
operational domain. Hosting, healthcare, finance, smart city,
government, manufacturing, defense, and any other domain are equally
addressable through domain extensions built on top of the protocol.
The protocol defines the contract; the domain defines the tools.
4. Context Model
4.1. Context Hierarchy
ICNLI defines a 9-level hierarchical context model. Each level adds
awareness; lower levels are resolved before higher levels are
referenced.
L0 PLATFORM Platform capabilities, tools, system status
L1 ACTOR Identity, authentication, roles, permissions
L2 ACCOUNT Account, subscription, quotas, limits
L3 SERVICE Services owned by the actor, status, config
L4 ENVIRONMENT Hosts, regions, environments, topology
L5 APPLICATION Apps, datasets, channels in environments
L6 RESOURCE Records, files, configurations, metrics
L7 RELATIONSHIP Connections and dependencies between entities
L8 INTERCONNECT Cross-system dependencies, cascade impact
Scerbacov Expires 16 December 2026 [Page 11]
Internet-Draft ICNLI June 2026
4.2. Why Nine Levels
The number is empirical, not arithmetic. Every operational domain
audited during the protocol's development (production hosting,
hospital operations, financial trade reconciliation, smart-city
infrastructure, and investigative case management) required at
minimum the nine distinctions above: the platform itself (L0); the
actor (L1); the actor's ownership boundary (L2); the set of relevant
operational entities (L3); the environment those entities live in
(L4); the applications or processes they expose (L5); the resources
they consume (L6); the relationships among them (L7); and the cross-
system interconnections (L8).
Collapsing any two of these levels lost expressive power in at least
one audited domain; adding more produced redundancy. Nine is the
smallest hierarchy that handled the observed set without information
loss. This is empirical inference, not a proof of universality. A
future revision MAY introduce additional levels if a domain requires
distinctions not captured by the current nine. Implementations MAY
also declare sub-levels within any level for domain-specific
structure; that is normative-extensible, not a violation.
Scerbacov Expires 16 December 2026 [Page 12]
Internet-Draft ICNLI June 2026
+================+==========+============+============+=============+
|Level |Hosting |Healthcare |Finance |Legal / |
| | | | |Investigative|
+================+==========+============+============+=============+
|L0 Platform |Cloud OS |Hospital |Trading |Case |
| | |information |platform |management |
| | |system | |system |
+----------------+----------+------------+------------+-------------+
|L1 Actor |Hosting |Physician / |Trader / |Investigator |
| |client |nurse |risk manager| |
+----------------+----------+------------+------------+-------------+
|L2 Ownership |Account |Patient |Portfolio / |Case file |
| | |record |fund | |
+----------------+----------+------------+------------+-------------+
|L3 Entities |Services /|Treatments /|Positions / |Case entities|
| |sites |encounters |instruments | |
+----------------+----------+------------+------------+-------------+
|L4 Environment |Servers / |Wards / |Markets / |Jurisdictions|
| |regions |departments |exchanges | |
+----------------+----------+------------+------------+-------------+
|L5 Applications |Web apps /|Devices / |Algorithms /|Documents / |
| |databases |procedures |order books |artifacts |
+----------------+----------+------------+------------+-------------+
|L6 Resources |Files / |Vitals / |Quotes / |Evidence / |
| |DNS / TLS |labs / |signals |records |
| | |images | | |
+----------------+----------+------------+------------+-------------+
|L7 Relationships|Dependency|Drug |Position |Entity- |
| |graph |interactions|correlations|relationship |
| | |/ allergies | |graph |
+----------------+----------+------------+------------+-------------+
|L8 |Cross- |Cross- |Systemic |Cross-case |
|Interconnections|service |department |risk |implications |
| |cascade |impact |exposure | |
+----------------+----------+------------+------------+-------------+
Table 2: Worked domain mappings
In every mapping, the protocol's requirements apply unchanged. The
domain supplies the payload; the protocol supplies the shape.
Scerbacov Expires 16 December 2026 [Page 13]
Internet-Draft ICNLI June 2026
4.3. Context Requirements by Conformance Level
+====================+=========+=========+=========+
| Context Level | Level 1 | Level 2 | Level 3 |
+====================+=========+=========+=========+
| L0 Platform | MUST | MUST | MUST |
+--------------------+---------+---------+---------+
| L1 Actor | MUST | MUST | MUST |
+--------------------+---------+---------+---------+
| L2 Account | MUST | MUST | MUST |
+--------------------+---------+---------+---------+
| L3 Service | SHOULD | MUST | MUST |
+--------------------+---------+---------+---------+
| L4 Environment | SHOULD | MUST | MUST |
+--------------------+---------+---------+---------+
| L5 Application | SHOULD | MUST | MUST |
+--------------------+---------+---------+---------+
| L6 Resource | MAY | MUST | MUST |
+--------------------+---------+---------+---------+
| L7 Relationship | MAY | SHOULD | MUST |
+--------------------+---------+---------+---------+
| L8 Interconnection | MAY | SHOULD | MUST |
+--------------------+---------+---------+---------+
Table 3: Context level requirements by
conformance level
4.4. Context Resolution
Implementations MUST resolve context in order from L0 upward. Lower
levels MUST be available before higher levels are referenced.
Implementations MAY load deeper levels lazily, eagerly, or
selectively, but MUST NOT skip levels: a request that references L5
MUST also have L0 through L4 resolved. The following pseudocode
describes the minimum resolution algorithm.
Scerbacov Expires 16 December 2026 [Page 14]
Internet-Draft ICNLI June 2026
def resolve_context(request) -> Context:
context = Context()
# L0: Platform (always available)
context.platform = get_platform_context()
# L1: Actor (from authentication)
context.actor = authenticate(request)
if not context.actor:
raise AuthenticationRequired()
# L2: Account (derived from actor)
context.account = get_account(context.actor)
# L3+: lazy, eager, or selective per implementation.
# Levels MUST NOT be skipped: a reference to Ln
# requires L0..L(n-1) to be resolved first.
if request.references_service():
context.service = resolve_service(request, context)
if request.references_environment():
context.environment = resolve_environment(request, context)
# ... continue for deeper levels
return context
Compliant implementations MAY enrich the context object with domain-
specific fields, MUST preserve the level structure, and MUST mask
personally identifiable information (PII) by default when
transmitting context to the model layer (Section 7.4).
5. Interaction Protocol
5.1. Request Types
ICNLI defines four request types.
Scerbacov Expires 16 December 2026 [Page 15]
Internet-Draft ICNLI June 2026
+============+========================+=======================+
| Type | Description | Confirmation required |
+============+========================+=======================+
| QUERY | Read-only information | No |
| | retrieval. | |
+------------+------------------------+-----------------------+
| MUTATION | State-changing | Yes (two-step) |
| | operation. | |
+------------+------------------------+-----------------------+
| NAVIGATION | Context switching | No |
| | between resources. | |
+------------+------------------------+-----------------------+
| META | System, help, or self- | No |
| | description requests. | |
+------------+------------------------+-----------------------+
Table 4: Request types
5.2. Request Classification
A compliant implementation MUST classify every incoming request
before tool selection. Classification MUST produce, at minimum, the
request type and a confidence value. For low-confidence
classifications targeting MUTATION or destructive operations, the
system MUST request clarification. The classification algorithm is
implementation-specific and MAY be proprietary; its contract is
normative.
Implementations MUST use a learned intent classifier, not substring
or keyword matching. Lexical matching on natural language is
insufficient: a request such as "show me what would happen if I
deleted the database" contains both "show" and "deleted" yet is a
query (it asks for an impact analysis), not a mutation. A classifier
that distinguishes such cases is mandatory. The classifier MUST be
deterministic for a given (request, context) pair within a session,
and MUST emit, in addition to the request type, an action type (read
/ write / destructive), a target domain drawn from the registered
operational domains, and a confidence value in the range [0, 1]. A
confidence below an implementation-defined threshold (RECOMMENDED at
most 0.7 for destructive intents) MUST trigger a clarification
request, not a best-effort dispatch.
Scerbacov Expires 16 December 2026 [Page 16]
Internet-Draft ICNLI June 2026
5.3. Two-Step Confirmation Protocol
All MUTATION requests MUST follow the two-step pattern. In Step 1
(Proposal), the request is classified and routed, context is
resolved, a plan is formed, impact is analyzed, and a proposal is
presented to the actor with a summary, the affected items, impact
notes, and a confirmation prompt. In Step 2 (Execution), the actor
confirms, the confirmation token is validated, the action executes,
and the result is reported.
5.4. Confirmation Tokens
To prevent accidental confirmations, implementations MUST issue
confirmation tokens carrying at least a unique proposal identifier,
the proposed action and target, an issue time, an expiry time, and
the set of accepted confirmation responses. An example token shape
follows.
{
"proposal_id": "prop_xyz789",
"action": "delete_resource",
"target": "res_001",
"issued_at": "2026-05-17T10:00:00Z",
"expires_at": "2026-05-17T10:05:00Z",
"valid_confirmations": ["yes", "confirm", "proceed"]
}
Implementations MUST:
* Generate a unique proposal identifier per proposal.
* Set an expiration; the RECOMMENDED expiry is five minutes.
* Reject confirmations after expiration.
* Reject confirmations whose proposal identifier does not match the
most recent unexpired proposal in the session.
* Re-classify or re-plan on receipt of a new request rather than
reusing an expired proposal.
Scerbacov Expires 16 December 2026 [Page 17]
Internet-Draft ICNLI June 2026
6. Intent Routing and Chain Orchestration
Relation to prior art: this pattern is not unique to ICNLI. The
Model Context Protocol (MCP) [MCP] standardizes tool discovery,
model-native function-calling capabilities standardize tool
invocation, and agent frameworks implement runtime tool retrieval.
ICNLI's contribution is making the routing decision a normative,
auditable, persistable protocol artifact, and binding it to the fact
ledger and to read-before-write semantics for multi-step chains.
6.1. Intent Routing
At Conformance Level 2 and above, the implementation MUST classify
request intent and route to candidate operational domains before any
tool is selected. The classification layer MUST:
1. Classify each incoming request into one or more relevant
operational domains.
2. Pass only relevant domain tools to subsequent processing stages.
3. Complete classification within a defined latency budget per
implementation.
4. Fall back to a broader tool surface if classification is
ambiguous, while never silently downgrading safety
classification.
Intent routing is the protocol's structural defence against tool mis-
selection: the AI engine never sees the full registry; it sees the
focused subset that the router determined was relevant. This is a
load-bearing input to the Anti-Fabrication Contract (Section 7),
because a tool the model never sees cannot be invented.
6.2. Domain Registry
Implementations MUST maintain a Domain Registry mapping tools to
operational domains. The schema of the registry and the number,
naming, and granularity of domains are implementation-specific. The
registry MUST be inspectable in debug or audit mode. The protocol
makes no claim about how many tools or how many domains a compliant
implementation supports; only that the mapping exists, is
inspectable, and is consulted before tool selection.
Scerbacov Expires 16 December 2026 [Page 18]
Internet-Draft ICNLI June 2026
6.3. Chain Orchestration
When a request resolves to more than one tool invocation, the
implementation MUST treat the dispatch as a chain and MUST execute it
through a single chain orchestrator. The chain orchestrator MUST
satisfy the following normative requirements:
1. Single orchestrator. All multi-tool dispatch MUST flow through
the same kernel-level orchestrator. Extensions MUST NOT
implement private multi-tool orchestration loops.
2. Explicit dependency declaration. Each step in the chain MUST
declare its dependencies on prior steps by stable identifier.
3. Topological execution order. The orchestrator MUST compute a
stable topological order over declared dependencies before
executing the chain. Reads MUST precede dependent writes.
4. Fail-fast on dropped plans for destructive operations. If a
planned step targeting a state-changing or destructive operation
is dropped during validation, the orchestrator MUST surface a
user-visible error and MUST NOT silently fall back to a single-
tool path.
5. Per-step audit emission. Every step's classification, dispatch,
result, and any confirmation MUST appear in the audit substrate
(Section 12).
6. Two-step composition. Confirmation requirements apply per step
at the safety classification of each step. A chain containing a
level-3 or level-4 step MUST request confirmation before the
destructive step executes, regardless of prior step results.
6.4. Step-Output References
A chain step MAY consume data produced by a prior step. The protocol
defines this as a Step-Output Reference: a typed connection from the
output of step N to a named input of a later step M. Implementations
MAY choose any concrete syntax for these references. The protocol
requires the following semantics regardless of syntax:
* A reference MUST identify its producer step unambiguously and MUST
remain stable under topological reordering.
* The orchestrator MUST resolve references at dispatch time using
the verbatim output of the producer step from the fact ledger
(Section 7).
Scerbacov Expires 16 December 2026 [Page 19]
Internet-Draft ICNLI June 2026
* A reference MUST NOT be expanded by paraphrasing or summarization;
it MUST carry the producer's data faithfully.
* A reference whose producer failed or was dropped MUST cause the
dependent step either to fail explicitly or to seek confirmation,
never to dispatch with placeholder data.
This protects multi-step reliability: an AI agent constructing a
chain cannot accidentally invent the data flowing between steps,
because the orchestrator binds references to verbatim outputs.
7. Anti-Fabrication Requirements
A compliant implementation MUST satisfy the Anti-Fabrication
Contract. This is the protocol's structural defence against the
class of failure commonly labelled "hallucination". The contract has
four normative components: cross-turn fact preservation, grounded
narration, intent-routed tool selection, and a PII masking gate. The
Anti-Fabrication Contract is REQUIRED at all conformance levels; it
is not a higher-tier feature.
7.1. Cross-Turn Fact Preservation
For every tool dispatch, the implementation MUST record the tool's
structured output verbatim into a per-session fact ledger. The fact
ledger MUST be made available to the model layer on subsequent turns.
The model MUST be instructed to prefer verbatim facts over
paraphrased prose from earlier turns.
* Facts MUST be preserved as structured data, not only as prose
summaries.
* The fact ledger MUST be bounded by a configurable per-turn
aggregation cap so that long-running sessions cannot exhaust the
context budget.
* Facts MUST survive across turns within a session and SHOULD
survive across sessions where supported by the implementation's
memory layer.
7.2. Grounded Narration
When the implementation produces a user-facing narrative response,
the narration MUST be grounded in facts present in the current turn's
dispatch results or in the fact ledger. The implementation MUST NOT
permit narration to claim a tool produced a value not present in that
tool's output, to quantify a result not enumerated in the underlying
facts, or to attribute a status to a resource whose status was not
Scerbacov Expires 16 December 2026 [Page 20]
Internet-Draft ICNLI June 2026
retrieved. Implementations SHOULD enforce grounded narration through
a system instruction to the model layer combined with a post-
generation check appropriate to the model and channel. The mechanism
is implementation-specific; the requirement is normative.
7.3. Intent-Routed Tool Selection
The intent-routing requirements of Section 6.1 are a load-bearing
element of the Anti-Fabrication Contract. By restricting the model's
tool surface to the classifier-selected subset, the protocol
structurally prevents the model from inventing a call to a tool that
the router did not surface. Implementations MUST NOT permit the
model to invoke tools outside the routed subset for the current
request.
7.4. PII Masking Gate
A compliant implementation MUST mask personally identifiable
information (PII) in context delivered to the model by default.
Exposure of PII to the model MUST be opt-in, configurable at
deployment time, and auditable. The default state MUST be masking
enabled; the opt-in MUST be explicit.
7.5. Scope of Guarantee
The Anti-Fabrication Contract has explicit normative scope.
Implementations and reviewers must understand the following
distinctions.
+============+=============================+========================+
| Layer | What is guaranteed | How |
+============+=============================+========================+
| Provenance | Tool-call output | Structural: fact |
| | preserved verbatim across | ledger is append-only |
| | turns; substitution is | and content-addressed. |
| | detectable. | |
+------------+-----------------------------+------------------------+
| Narration | Narrator MUST NOT claim | Contractual: enforced |
| | values absent from the | by runtime judges |
| | ledger. | (probabilistic at this |
| | | protocol version). |
+------------+-----------------------------+------------------------+
| Intent | Classifier MUST select | Contractual: enforced |
| routing | tools from the declared | before tool-surface |
| | domain set. | exposure to the model. |
+------------+-----------------------------+------------------------+
Table 5: Scope of the anti-fabrication guarantee
Scerbacov Expires 16 December 2026 [Page 21]
Internet-Draft ICNLI June 2026
The contract REDUCES ungrounded fabrication; it does NOT eliminate
the category in the formal sense. Strict structural impossibility
would require constrained generation or a symbolic intermediate
representation, neither of which is normatively required by this
protocol version. Implementations MAY exceed this baseline with
stricter enforcement (for example, entailment judges or constrained
decoding). Such enhancements MUST NOT weaken the contract surface
defined above.
8. Safety Layer
Relation to prior art: two-step confirmation patterns exist
throughout systems engineering, from interactive removal prompts in
UNIX, to the plan-and-apply workflow of infrastructure-as-code tools,
to repository-delete confirmations in source-hosting services.
ICNLI's contribution is making the gate normative at the protocol
level: classification on the 0 through 4 scale, mandatory impact
analysis from level 2 upward, cooling periods bound to the audit
trail, and cross-channel continuity of the gate so that a proposal
opened on one channel cannot be silently confirmed on another.
8.1. Safety Classification
All tools MUST be classified by safety level.
+=======+============+=====================+======================+
| Level | Name | Description | Example |
+=======+============+=====================+======================+
| 0 | READ | No side effects. | List, show, status. |
+-------+------------+---------------------+----------------------+
| 1 | SAFE_WRITE | Reversible changes. | Update a non- |
| | | | critical preference. |
+-------+------------+---------------------+----------------------+
| 2 | WRITE | Significant but | Create a resource, |
| | | routine changes. | add a record. |
+-------+------------+---------------------+----------------------+
| 3 | DANGEROUS | Potentially | Delete a record, |
| | | destructive. | drop a dataset. |
+-------+------------+---------------------+----------------------+
| 4 | CRITICAL | Irreversible, | Delete a service, |
| | | severe impact. | purge backups. |
+-------+------------+---------------------+----------------------+
Table 6: Safety classification levels
Scerbacov Expires 16 December 2026 [Page 22]
Internet-Draft ICNLI June 2026
8.2. Safety Requirements by Level
+=======+================+==========+=============+================+
| Level | Confirmation | Audit | Backup | Cooling period |
+=======+================+==========+=============+================+
| 0 | No | Optional | No | No |
+-------+----------------+----------+-------------+----------------+
| 1 | Optional | Yes | No | No |
+-------+----------------+----------+-------------+----------------+
| 2 | Yes (two-step) | Yes | Recommended | No |
+-------+----------------+----------+-------------+----------------+
| 3 | Yes, with | Yes | Required | Recommended |
| | impact details | | | |
+-------+----------------+----------+-------------+----------------+
| 4 | Yes, with | Yes | Required | Required (at |
| | danger phrase | | | least 30 s) |
+-------+----------------+----------+-------------+----------------+
Table 7: Safety requirements by level
8.3. Impact Analysis
Before proposing a mutation at level 2 or above, implementations MUST
analyze and present impact, including direct targets, cascade targets
derived from L7 and L8 context, reversibility, and backup
availability where applicable.
8.4. Danger Phrases
For CRITICAL (level 4) operations, implementations MUST require an
explicit danger phrase that demonstrates the actor understands what
is about to occur. The phrase MUST include the target identifier or
an equivalent that cannot be produced by accidental typing (for
example, requiring the actor to type a phrase containing the exact
resource identifier).
8.5. Role-Based Safety
The canonical example roles are guest, client, and admin; these are
examples only. Compliant implementations MAY define additional
roles. Implementations MUST enforce role-based access on every tool
dispatch and MUST log authorization failures. For example, a guest
role might be permitted only safety level 0, a client role levels 0
through 3, and an admin role levels 0 through 4. Role names and the
level mapping are illustrative.
9. Modular Extension Contract
Scerbacov Expires 16 December 2026 [Page 23]
Internet-Draft ICNLI June 2026
9.1. Modular Composition Pattern
A compliant implementation MUST be structured as a finite kernel plus
a pluggable surface of extensions. The kernel owns intent
classification and routing, chain orchestration, confirmation and
audit, the fact ledger and memory, and extension lifecycle and
validation. Extensions own the tools they declare, the domain
capabilities they implement, and their channel contributions (panels,
surfaces) where applicable. Extensions MUST NOT alter kernel
orchestration semantics. New domains, channels, or capabilities
SHOULD be added by registering new extensions, not by modifying the
kernel.
9.2. Extension Manifest Schema
Every extension MUST declare a manifest. The manifest is the
contract by which the kernel decides whether and how to register the
extension. The protocol requires the following manifest field
categories. Specific field names are implementation-specific;
categorical presence is normative.
Scerbacov Expires 16 December 2026 [Page 24]
Internet-Draft ICNLI June 2026
+===============+===================================+
| Category | Purpose |
+===============+===================================+
| Identity | A stable identifier and human- |
| | readable name for the extension. |
+---------------+-----------------------------------+
| Version | The extension's own version and a |
| | declared conformance level claim |
| | (for example L1, L2, or L3). |
+---------------+-----------------------------------+
| Tools | The list of declared tools, each |
| | with name, safety classification, |
| | parameters, and return shape. |
+---------------+-----------------------------------+
| Capabilities | Declared capability surface (for |
| | example contributed panels, |
| | channels, or background jobs). |
+---------------+-----------------------------------+
| Permissions | The minimum permissions the |
| | extension requires from the |
| | kernel and from the actor. |
+---------------+-----------------------------------+
| Compatibility | The minimum kernel version and |
| | the protocol version against |
| | which the extension was built. |
+---------------+-----------------------------------+
Table 8: Manifest field categories
A compliant kernel MUST validate the manifest against these
categories before registration. An invalid manifest MUST be rejected
with a structured error; the extension MUST NOT be registered
partially.
9.3. Tool Registration
A tool declared by an extension MUST be registered into the kernel's
tool registry and indexed by the Domain Registry (Section 6.2).
Registration MUST capture the tool's safety classification
(Section 8.1). A tool whose safety classification cannot be
determined MUST be rejected.
9.4. Extension Lifecycle
The kernel MUST manage the lifecycle of every extension through the
following ordered stages:
1. Load: read the manifest and the extension code.
Scerbacov Expires 16 December 2026 [Page 25]
Internet-Draft ICNLI June 2026
2. Validate: confirm manifest categorical completeness and
structural well-formedness. Validation occurs before
registration; an extension that fails validation MUST NOT be
registered.
3. Register: install tools into the registry and contributions into
the appropriate kernel surfaces.
4. Dispatch: route routed intents to the extension's tools per the
orchestration rules of Section 6.
5. Unload: remove the extension's tools and contributions
atomically; in-flight dispatches MUST complete or be cancelled
before unload finalizes.
The kernel MUST emit audit events at each stage of the lifecycle
(Section 12).
10. Proactive Intelligence Requirements
Relation to prior art: background observation and alerting is well-
established in operations engineering, from classic host monitors to
modern metrics-and-alerting stacks and the long tail of scheduled-
script monitors. ICNLI's contribution is making proactive
observation a normative protocol primitive integrated with two-step
confirmation, the fact ledger, and the same channel-neutral surface
as user-initiated actions. An anomaly does not become an unattended
automated remediation; it becomes a proposal the human still
confirms.
10.1. Background Context Refresh
At Conformance Level 3, the implementation MUST maintain a User
Intelligence Profile that is refreshed in the background, independent
of any inbound request. Refresh cadence and scope are
implementation-specific. The profile MUST be available to the
classifier and the model layer on every turn.
10.2. User Intelligence Profile
The profile MUST capture, at minimum, a summary of the actor's
relevant services, environments, and resources; a summary of recent
activity within a configurable window; and outstanding follow-ups,
pending confirmations, or alert states. The profile MUST be subject
to the PII masking gate of Section 7.4.
Scerbacov Expires 16 December 2026 [Page 26]
Internet-Draft ICNLI June 2026
10.3. Anomaly Surfacing
At Conformance Level 3, the implementation SHOULD surface anomalies
that the User Intelligence Profile is aware of. An anomaly is any
state divergence from a baseline that the implementation considers
actionable. Anomaly surfacing MUST occur through the same channel-
neutral interface as request-response traffic.
10.4. Alert Protocol
When the implementation initiates communication with an actor (an
alert, an anomaly notice, a proposed action), the following
requirements apply:
1. Same interface. Alerts MUST flow through the same protocol
surface as request-response traffic; the actor's channel
preference MUST be respected.
2. Actionable. An alert that proposes a state-changing action MUST
be paired with a two-step proposal whose confirmation token
follows Section 5.4.
3. Auditable. Alerts MUST be recorded in the audit substrate
exactly as request-response interactions are.
4. Suppressible. Actors MUST be able to opt out of alert categories
without losing access to other protocol functionality.
Proactive is not autonomous: the system watches and proposes; the
human authorizes.
11. Channel Support
Relation to prior art: separation between a surface (a UI or channel)
and the substrate that powers it is a long-established software-
engineering pattern, including the model-view-controller pattern and
ports-and-adapters (hexagonal) architecture. ICNLI's contribution is
orthogonal: cross-surface state continuity (the same session, fact
ledger, audit trail, and two-step gate preserved across channels) is
a property that those patterns do not provide on their own, because
they separate concerns within one application whereas channel
neutrality preserves them across multiple applications and surfaces.
Scerbacov Expires 16 December 2026 [Page 27]
Internet-Draft ICNLI June 2026
11.1. Channel Requirements
A compliant implementation MUST support at least one channel and
SHOULD support multiple channels with equivalent functionality.
Capabilities MUST be equivalent across supported channels; response
form MAY differ.
11.2. Standard Channels (Examples)
Example channels include a web GUI, a conversational messaging
channel, a voice channel (speech-to-text input and text-to-speech
output), a programmatic API, and a command-line interface.
Implementations MAY add or omit channels; this list is illustrative,
not normative.
11.3. Channel Abstraction
Implementations MUST abstract channel-specific details behind a
stable interface. The interface MUST cover at minimum: receiving a
message, sending a message, sending a confirmation request, and
obtaining the authenticated actor context.
11.4. Response Adaptation
Implementations MUST adapt response form to the capabilities of the
active channel: rich formatting where supported, plain text or speech
where not. Protocol semantics (two-step, intent routing, chain
orchestration, anti-fabrication) MUST remain identical across
channels.
11.5. Cross-Channel Continuity
At Conformance Level 3, the implementation MUST support cross-channel
continuity: an actor MUST be able to begin an interaction on one
channel and continue it on another with full preservation of context
and the fact ledger.
11.6. Voice Considerations
For voice channels, implementations MUST use audio-appropriate
phrasing, MUST spell out values that are easily confused
(identifiers, addresses), MUST provide audio confirmation before
level-3 or level-4 actions, and MUST support actor interruption of
long responses.
Scerbacov Expires 16 December 2026 [Page 28]
Internet-Draft ICNLI June 2026
12. Observability and Audit
12.1. Structured Metrics
A compliant implementation MUST emit structured metrics for core
protocol events at minimum: request received and classified; tool
dispatched, with safety level; confirmation issued, accepted,
expired, or rejected; chain step started, completed, or failed; and
alert emitted by the proactive subsystem. Metric names and the
labelling vocabulary are implementation-specific. Metrics MUST NOT
carry PII in label values; identifying values belong in trace
attributes or audit records, not on metric series.
12.2. Distributed Tracing
A compliant implementation SHOULD emit distributed traces compatible
with OpenTelemetry semantic conventions. Spans SHOULD cover at
minimum the lifetime of a request, each classification step, each
tool dispatch, and each chain step. Spans MUST carry a trace
identifier that correlates with structured log entries.
12.3. Structured Logs
A compliant implementation MUST emit structured logs (JSON or an
equivalent structured format) and MUST include the trace identifier
of the active span. Logs MUST capture authentication events,
classification decisions, tool dispatches and their parameters (with
sensitive values masked), confirmations, errors, and lifecycle
events. An illustrative log entry follows.
Scerbacov Expires 16 December 2026 [Page 29]
Internet-Draft ICNLI June 2026
{
"timestamp": "2026-05-17T10:15:30.123Z",
"trace_id": "0af7651916cd43dd8448eb211c80319c",
"event_type": "tool_dispatch",
"actor": {
"id": "actor_12345",
"role": "client",
"auth_method": "session_token"
},
"session_id": "sess_abc123",
"channel": "messaging",
"request_intent": "DELETE_DATABASE",
"request_text_redacted": "<masked: PII gate active>",
"resolved_target": "db_redacted_<hash>",
"tool": "resource_delete",
"safety_level": 3,
"confirmation": {
"requested": true,
"received": true,
"latency_ms": 4200
},
"parameters_masked": true,
"result": "success",
"duration_ms": 1247,
"audit_chain_hash": "<sha256:prev_block>",
"audit_block_hash": "<sha256:this_block>"
}
12.4. Audit Trail
A compliant implementation MUST maintain a complete audit trail of
every interaction sufficient to reconstruct, after the fact, what was
asked, how it was classified, what was dispatched, what was
confirmed, and what was produced. The audit trail MUST be tamper-
evident or stored in a system providing tamper-evidence at the
deployment layer.
12.5. Audit Chain Tamper-Evidence
Audit log entries MUST be linked into a hash chain where each entry's
block hash is computed over the entry's content concatenated with the
prior entry's block hash. Implementations MAY use cryptographic
signatures over hash blocks in addition to chaining. The hash chain
MUST allow detection of any single-entry tampering by chain re-
validation, SHOULD use SHA-256 or stronger as the digest function,
and SHOULD persist the chain in append-only storage or its functional
equivalent.
Scerbacov Expires 16 December 2026 [Page 30]
Internet-Draft ICNLI June 2026
This requirement applies at Conformance Level 2 and above. Level 1
implementations MAY log without chaining; if they do, they MUST NOT
describe their audit trail as tamper-evident.
12.6. Fail-Soft Telemetry
Telemetry failure MUST NOT break the request path. If a metrics
backend, tracing collector, or log target is unavailable, the
implementation MUST continue to serve requests; degraded telemetry
SHOULD itself be surfaced as a metric.
13. Conformance Levels
ICNLI defines three conformance levels. Higher levels include all
requirements of lower levels.
13.1. Level 1 (Basic)
A Level 1 implementation MUST implement two-step confirmation for all
mutations; maintain context levels L0 through L2; support at least
one channel; provide tool discovery (the manifest categories of
Section 9.2 exposed via at least one introspection surface); log all
operations with timestamps; and satisfy the Anti-Fabrication Contract
(Section 7) in full. Anti-fabrication is REQUIRED at every level.
13.2. Level 2 (Standard)
A Level 2 implementation MUST satisfy all Level 1 requirements and
additionally maintain context levels L0 through L6; implement safety
classification levels 0 through 4 with the requirements of Section 8;
satisfy the Modular Extension Contract (Section 9) in full, including
manifest validation before registration; implement intent
classification before tool selection (Section 6.1); support at least
two channels with equivalent functionality (SHOULD; one channel
remains the floor); enforce role-based access control across all
dispatches; and issue confirmation tokens with expiration per
Section 5.4.
13.3. Level 3 (Advanced)
A Level 3 implementation MUST satisfy all Level 2 requirements and
additionally maintain context levels L0 through L8 including
relationship and interconnection context; implement Chain
Orchestration (Section 6.3) including Step-Output References
(Section 6.4); satisfy the Proactive Intelligence Requirements
(Section 10) in full, including the User Intelligence Profile and the
Alert Protocol; provide cross-channel continuity (Section 11.5);
support a voice channel where the deployment context warrants
Scerbacov Expires 16 December 2026 [Page 31]
Internet-Draft ICNLI June 2026
(SHOULD); implement danger-phrase confirmation for CRITICAL
operations and the cooling period of Section 8.2; and implement the
full Observability and Audit requirements of Section 12.
13.4. Conformance Declaration
A compliant implementation MUST publish a conformance declaration in
machine-readable form. The schema is implementation-specific; the
following example illustrates the required information.
{
"icnli": {
"specification_version": "2.0.0",
"conformance_level": 3,
"channels": ["web", "messaging", "api"],
"context_levels": [0, 1, 2, 3, 4, 5, 6, 7, 8],
"safety_levels": [0, 1, 2, 3, 4],
"anti_fabrication_contract": true,
"modular_extension_contract": true,
"chain_orchestration": true,
"proactive_intelligence": true,
"observability": ["metrics", "traces", "logs", "audit"],
"vendor": "Example Compliant Implementation",
"vendor_version": "1.0.0"
}
}
13.5. Current State of Conformance Verification
Conformance to ICNLI version 2.0.0 is currently self-declared. There
is no automated test suite, no canonical reference fixtures, and no
adversarial conformance harness at the time of this document's
publication. This is a known gap. Until the test suite ships:
* "ICNLI v2.0 compliant" is a statement of intent by an implementer.
* "ICNLI v2.0 certified" is reserved for implementations that pass
the published test suite. No implementation may claim
certification before the suite exists.
* Implementations SHOULD publish their conformance self-assessment
as a checklist mapped to specific MUST and SHOULD clauses, so that
independent reviewers can evaluate the claim against the
specification text.
Implementations claiming any level of conformance MUST NOT use the
term "certified" until automated verification is available.
Scerbacov Expires 16 December 2026 [Page 32]
Internet-Draft ICNLI June 2026
14. Status of the Protocol and Relationship to Other Work
ICNLI is a vendor-authored open specification. The specification
text is published under CC BY-SA 4.0 at https://icnli.org/icnli-
specification/, which guarantees that the text cannot be locked
behind a single vendor. At the time of writing there is one
specification author, and the protocol has been described by its
author with a stated path toward broader governance.
The author has stated three governance milestones, in order: (1) a
published conformance test suite with reference fixtures and
adversarial tests; (2) at least three independent compliant
implementations from organizations unaffiliated with the author's
organization, each passing that suite; and (3) transfer of the
specification's evolution process and associated marks to a neutral
body with a public change-control procedure and multi-organization
representation. 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.
Accordingly, this Internet-Draft makes no claim that ICNLI is an
adopted standard, an IETF work item, an RFC, or a multi-vendor-
adopted protocol. It is published as an individual submission to
create a dated, citable technical description for the community and
to invite review. ICNLI composes with, rather than replaces,
adjacent work: a compliant implementation MAY use any underlying
foundation model, MAY use the Model Context Protocol [MCP] or a
model-native function-calling capability at the model-to-tool
boundary, and MAY use any orchestration runtime that can satisfy the
contract described here.
The flagship implementation referenced by the specification is
Imperal Cloud, with a reference agent named Webbee, and a public
reference toolkit and machine-readable Tool Definition schema
published as imperal-sdk [IMPERAL-SDK]; the specification names
WebHostMost as the first enterprise client running an ICNLI-compliant
deployment in production. For transparency, WebHostMost shares a
founder with Imperal, Inc. This document intentionally omits
operational metrics; any operational numbers should be sought in, and
attributed to, the ICNLI whitepaper [ICNLI-WP] as representative
figures for a stated window, never as independent benchmarks.
15. Security Considerations
Security is central to this protocol rather than incidental to it;
several normative requirements elsewhere in this document are
security controls. The considerations below summarize and
consolidate them.
Scerbacov Expires 16 December 2026 [Page 33]
Internet-Draft ICNLI June 2026
15.1. Authentication
Implementations MUST authenticate actors before processing any
request, MUST support industry-standard authentication methods, MUST
NOT store credentials in plain text, and MUST implement session
timeouts appropriate to the deployment context. Actor identity (L1
context) is a precondition for all higher-level context resolution.
15.2. Authorization
Implementations MUST verify permissions before tool dispatch, MUST
follow the principle of least privilege, MUST log authorization
failures, and MUST support permission delegation only within bounded
scopes with explicit time limits. Role-based access control
(Section 8.5) MUST be enforced on every dispatch.
15.3. Input Validation
Implementations MUST validate all input against declared schemas,
MUST sanitize input to prevent injection, MUST reject malformed
requests with structured errors, and MUST implement rate limiting
appropriate to the channel. Because the primary input is untrusted
natural language interpreted by a model, implementations should treat
prompt-injection and tool-misuse attempts as expected adversarial
input: the two-step gate (Section 5.3), intent-routed tool selection
(Section 7.3), and the requirement that the kernel rather than the
model executes actions are the structural mitigations the protocol
provides.
15.4. Data Protection
Implementations MUST encrypt sensitive data at rest, MUST use TLS for
transport, MUST mask sensitive values in logs and metric labels, MUST
implement data-retention policies appropriate to the deployment
domain, and MUST support on-premises deployment for domains that
require it. The PII masking gate (Section 7.4) is enabled by default
and limits the private data exposed to the model layer; any opt-in
exposure MUST be explicit, configurable, and auditable.
15.5. Audit Integrity
The audit trail required by Section 12.4 MUST be protected from
tampering by the implementation or by the deployment substrate, and
MUST be retained for a period appropriate to the domain. The hash-
chain requirement of Section 12.5 provides tamper-evidence at
Conformance Level 2 and above; implementations MUST NOT describe an
unchained audit trail as tamper-evident.
Scerbacov Expires 16 December 2026 [Page 34]
Internet-Draft ICNLI June 2026
16. IANA Considerations
This document has no IANA actions.
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
18. Informative References
[ICNLI-SPEC]
Scerbacov, V., "ICNLI Specification v2.0 - The Open
Protocol for Modular Proactive AI Cloud Operating
Systems", Version 2.0.0, Published Specification, licensed
under CC BY-SA 4.0, May 2026,
<https://icnli.org/icnli-specification/>.
[ICNLI-WP] Scerbacov, V., "ICNLI Whitepaper", Architecture,
rationale, deployment, and representative operational
figures; licensed under CC BY-SA 4.0, May 2026,
<https://icnli.org/icnli-whitepaper/>.
[ICNLI-ZENODO]
Scerbacov, V., "ICNLI Specification v2.0 (archived
deposit)", Zenodo deposit, DOI 10.5281/zenodo.20684403
(archived ICNLI Specification v2.0; concept DOI 10.5281/
zenodo.20684402), 2026,
<https://doi.org/10.5281/zenodo.20684403>.
[IMPERAL-SDK]
Imperal, Inc., "imperal-sdk: reference SDK and Tool
Definition JSON Schema", Python package, install via "pip
install imperal-sdk", 2026,
<https://pypi.org/project/imperal-sdk/>.
[MCP] Anthropic, PBC, "Model Context Protocol (MCP)", An open
protocol standardizing how applications provide context
and tools to AI models, 2024,
<https://modelcontextprotocol.io/>.
Scerbacov Expires 16 December 2026 [Page 35]
Internet-Draft ICNLI June 2026
Appendix A. Acknowledgements
This document is a rendering of the ICNLI Specification version 2.0.0
[ICNLI-SPEC] authored by Valentin Scerbacov. The protocol's prior-
art discussion gratefully recognizes the engineering of the Model
Context Protocol, model-native function-calling capabilities, agent
frameworks, foundation-model providers, and decades of systems-
engineering practice in confirmation gates, monitoring, and surface-
substrate separation, on which ICNLI builds and with which it is
designed to compose.
Author's Address
Valentin Scerbacov
Imperal, Inc.
Email: valentin@imperal.io
URI: https://icnli.org
Scerbacov Expires 16 December 2026 [Page 36]