Imperal, Inc.

valentin@imperal.io https://icnli.org

Internet ICNLI natural language interface AI agent context model anti-fabrication audit 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.

Introduction The normative source of truth for this protocol is the ICNLI Specification version 2.0.0, published at 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 . 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.

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.
• 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.

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.

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. System problems the model layer cannot solve alone

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 reliability	A single forward pass cannot reason about transactional dependencies that span tools, time, and side effects.
Persistent memory	A context window is not memory; a protocol-level memory layer is required.
Safety and control	Refusal training is statistical; architectural 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.

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 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.

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.

Terminology

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 when, and only when, they appear in all capitals, as shown here.

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 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.

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.

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.

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 (). 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.

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.

Principle 4: Safety by Design All state-changing operations MUST follow the two-step confirmation pattern (). 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.

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.

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.

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.

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.

Context Model

Context Hierarchy ICNLI defines a 9-level hierarchical context model. Each level adds awareness; lower levels are resolved before higher levels are referenced.

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. Worked domain mappings

Level	Hosting	Healthcare	Finance	Legal / Investigative
L0 Platform	Cloud OS	Hospital information system	Trading platform	Case management system
L1 Actor	Hosting client	Physician / nurse	Trader / risk manager	Investigator
L2 Ownership	Account	Patient record	Portfolio / fund	Case file
L3 Entities	Services / sites	Treatments / encounters	Positions / instruments	Case entities
L4 Environment	Servers / regions	Wards / departments	Markets / exchanges	Jurisdictions
L5 Applications	Web apps / databases	Devices / procedures	Algorithms / order books	Documents / artifacts
L6 Resources	Files / DNS / TLS	Vitals / labs / images	Quotes / signals	Evidence / records
L7 Relationships	Dependency graph	Drug interactions / allergies	Position correlations	Entity-relationship graph
L8 Interconnections	Cross-service cascade	Cross-department impact	Systemic risk exposure	Cross-case implications

In every mapping, the protocol's requirements apply unchanged. The domain supplies the payload; the protocol supplies the shape.

Context Requirements by Conformance Level Context level 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

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. 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 ().

Interaction Protocol

Request Types ICNLI defines four request types. Request types

Type	Description	Confirmation required
QUERY	Read-only information retrieval.	No
MUTATION	State-changing operation.	Yes (two-step)
NAVIGATION	Context switching between resources.	No
META	System, help, or self-description requests.	No

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.

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.

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. 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.

Intent Routing and Chain Orchestration Relation to prior art: this pattern is not unique to ICNLI. The Model Context Protocol (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.

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 (), because a tool the model never sees cannot be invented.

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.

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 ().
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.

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 ().
• 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.

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.

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.

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 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.

Intent-Routed Tool Selection The intent-routing requirements of 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.

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.

Scope of Guarantee The Anti-Fabrication Contract has explicit normative scope. Implementations and reviewers must understand the following distinctions. Scope of the anti-fabrication guarantee

Layer	What is guaranteed	How
Provenance	Tool-call output preserved verbatim across turns; substitution is detectable.	Structural: fact ledger is append-only and content-addressed.
Narration	Narrator MUST NOT claim values absent from the ledger.	Contractual: enforced by runtime judges (probabilistic at this protocol version).
Intent routing	Classifier MUST select tools from the declared domain set.	Contractual: enforced before tool-surface exposure to the model.

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.

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.

Safety Classification All tools MUST be classified by safety level. Safety classification levels

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 routine changes.	Create a resource, add a record.
3	DANGEROUS	Potentially destructive.	Delete a record, drop a dataset.
4	CRITICAL	Irreversible, severe impact.	Delete a service, purge backups.

Safety Requirements by Level 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 impact details	Yes	Required	Recommended
4	Yes, with danger phrase	Yes	Required	Required (at least 30 s)

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.

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).

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.

Modular Extension Contract

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.

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. Manifest field categories

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.

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.

Tool Registration A tool declared by an extension MUST be registered into the kernel's tool registry and indexed by the Domain Registry (). Registration MUST capture the tool's safety classification (). A tool whose safety classification cannot be determined MUST be rejected.

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.
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 .
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 ().

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.

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.

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 .

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.

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 .
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.

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.

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.

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.

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.

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.

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.

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.

Observability and Audit

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.

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.

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. ", "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": "" } ]]>

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.

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. 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.

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.

Conformance Levels ICNLI defines three conformance levels. Higher levels include all requirements of lower levels.

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 exposed via at least one introspection surface); log all operations with timestamps; and satisfy the Anti-Fabrication Contract () in full. Anti-fabrication is REQUIRED at every level.

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 ; satisfy the Modular Extension Contract () in full, including manifest validation before registration; implement intent classification before tool selection (); 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 .

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 () including Step-Output References (); satisfy the Proactive Intelligence Requirements () in full, including the User Intelligence Profile and the Alert Protocol; provide cross-channel continuity (); support a voice channel where the deployment context warrants (SHOULD); implement danger-phrase confirmation for CRITICAL operations and the cooling period of ; and implement the full Observability and Audit requirements of .

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.

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.

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 , 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 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 ; 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 as representative figures for a stated window, never as independent benchmarks.

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.

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.

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 () MUST be enforced on every dispatch.

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 (), intent-routed tool selection (), and the requirement that the kernel rather than the model executes actions are the structural mitigations the protocol provides.

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 () is enabled by default and limits the private data exposed to the model layer; any opt-in exposure MUST be explicit, configurable, and auditable.

Audit Integrity The audit trail required by 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 provides tamper-evidence at Conformance Level 2 and above; implementations MUST NOT describe an unchained audit trail as tamper-evident.

IANA Considerations This document has no IANA actions.

Normative References Harvard University Huawei Technologies Informative References Imperal, Inc. Version 2.0.0, Published Specification, licensed under CC BY-SA 4.0 Imperal, Inc. Zenodo deposit, DOI 10.5281/zenodo.20684403 (archived ICNLI Specification v2.0; concept DOI 10.5281/zenodo.20684402) Imperal, Inc. Architecture, rationale, deployment, and representative operational figures; licensed under CC BY-SA 4.0 Imperal, Inc. Python package, install via "pip install imperal-sdk" Anthropic, PBC An open protocol standardizing how applications provide context and tools to AI models

Acknowledgements This document is a rendering of the ICNLI Specification version 2.0.0 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.