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": "", "resolved_target": "db_redacted_", "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": "", "audit_block_hash": "" } 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [ICNLI-WP] Scerbacov, V., "ICNLI Whitepaper", Architecture, rationale, deployment, and representative operational figures; licensed under CC BY-SA 4.0, May 2026, . [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, . [IMPERAL-SDK] Imperal, Inc., "imperal-sdk: reference SDK and Tool Definition JSON Schema", Python package, install via "pip install imperal-sdk", 2026, . [MCP] Anthropic, PBC, "Model Context Protocol (MCP)", An open protocol standardizing how applications provide context and tools to AI models, 2024, . 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]