The Infrastructure Contextual Natural Language Interface (ICNLI): An Open Protocol for Modular Proactive AI Cloud Operating Systems

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

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

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

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

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

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

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

4.3. Context 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.¶

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.1. Request Types

ICNLI defines four 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.¶

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

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

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

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.1. Safety Classification

All tools MUST be classified by safety level.¶

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

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

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

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

{
  "timestamp": "2026-05-17T10:15:30.123Z",
  "trace_id": "0af7651916cd43dd8448eb211c80319c",
  "event_type": "tool_dispatch",
  "actor": {
    "id": "actor_12345",
    "role": "client",
    "auth_method": "session_token"
  },
  "session_id": "sess_abc123",
  "channel": "messaging",
  "request_intent": "DELETE_DATABASE",
  "request_text_redacted": "<masked: PII gate active>",
  "resolved_target": "db_redacted_<hash>",
  "tool": "resource_delete",
  "safety_level": 3,
  "confirmation": {
    "requested": true,
    "received": true,
    "latency_ms": 4200
  },
  "parameters_masked": true,
  "result": "success",
  "duration_ms": 1247,
  "audit_chain_hash": "<sha256:prev_block>",
  "audit_block_hash": "<sha256:this_block>"
}

12.4. Audit Trail

A compliant implementation MUST maintain a complete audit trail of every interaction sufficient to reconstruct, after the fact, what was asked, how it was classified, what was dispatched, what was confirmed, and what was produced. The audit trail MUST be tamper-evident or stored in a system providing tamper-evidence at the deployment layer.¶

12.5. Audit Chain Tamper-Evidence

Audit log entries MUST be linked into a hash chain where each entry's block hash is computed over the entry's content concatenated with the prior entry's block hash. Implementations MAY use cryptographic signatures over hash blocks in addition to chaining. The hash chain MUST allow detection of any single-entry tampering by chain re-validation, SHOULD use SHA-256 or stronger as the digest function, and SHOULD persist the chain in append-only storage or its functional equivalent.¶

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

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