Skip to content

ICNLI Specification v2.0

Infrastructure Contextual Natural Language Interface — The Open Protocol for Modular Proactive AI Cloud Operating Systems

ICNLI was first created on 30 December 2025 (v1.0.0). Current specification: v2.0 (May 2026); next deliverable: v2.1.

Version: 2.0 Status: Published Specification Current specification: v2.0 (May 2026) First created: 30 December 2025 (v1.0.0 — protocol origin) Created by: Valentin Scerbacov Copyright: © 2026 Valentin Scerbacov / Imperal, Inc. License: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) Trademark: ICNLI™ is a trademark of Imperal, Inc.

Abstract

ICNLI (Infrastructure Contextual Natural Language Interface) is an open standard — a behavioral specification in the same standards category as POSIX (IEEE Std 1003.1), OpenAPI, ANSI SQL (ISO/IEC 9075), SOAP, WSDL. It defines what conformance means for systems in which AI agents take real operational action as first-class users. This version 2.0 positions ICNLI as the standard for Modular Proactive AI Cloud Operating Systems — a class of architecture in which context resolution, intent routing, action execution, memory, and audit are kernel-grade primitives rather than features bolted onto an application stack. ICNLI defines behavioral semantics, normative MUST clauses, conformance levels, and audit substrate format; wire-layer interoperability between independent implementations is implementation-specific and is not normatively required by v2.0. The detailed argument for why ICNLI is properly called an open standard lives in Comparisons §9.

The protocol is Modular by mandate: extensions, channels, tools, and operational domains plug into a finite and stable kernel through well-defined contracts. The kernel is small; the surface is unbounded. The protocol is Proactive by mandate: a compliant system watches its domain, anticipates events, surfaces concerns, and proposes actions without being asked. Background context refresh is a protocol-level requirement at higher conformance levels. The protocol is an AI Cloud OS by frame: AI is the primary user of the system, not a feature embedded inside it. Compliant implementations therefore expose OS-level primitives — process lifecycle for extensions, structured memory across sessions, dependency-aware multi-step execution, and a comprehensive audit substrate — directly to the AI agent.

ICNLI v2.0 is the current published specification. Its normative apparatus includes a Modular Extension Contract (Section 9), an Anti-Fabrication Contract (Section 7), Chain Orchestration semantics for multi-tool execution (Section 6), Proactive Intelligence requirements (Section 10), and Observability and Audit requirements (Section 12). The protocol is domain-agnostic, channel-neutral, and implementation-neutral. Any compliant implementation MAY use any underlying foundation model.

Table of Contents

  1. Introduction
  2. Terminology
  3. Core Principles
  4. Context Model
  5. Interaction Protocol
  6. Intent Routing and Chain Orchestration
  7. Anti-Fabrication Requirements
  8. Safety Layer
  9. Modular Extension Contract
  10. Proactive Intelligence Requirements
  11. Channel Support
  12. Observability and Audit Requirements
  13. Conformance Levels
  14. Security Considerations
  15. Implementation Guidelines
  16. Appendices

1. Introduction

1.1 Purpose

The purpose of this specification is to define a universal protocol for AI systems that operate as kernel-grade citizens within real-world domains. ICNLI v2.0 establishes the architectural contract a Modular Proactive AI Cloud Operating System MUST satisfy 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 MUST:

  • Maintain hierarchical contextual awareness of its operational domain.
  • Classify natural-language requests by intent before any tool selection occurs.
  • Execute consequential actions only with explicit human confirmation (TWO-STEP).
  • Compose multi-tool chains with explicit dependency declaration and topological execution.
  • Preserve facts from prior turns verbatim and ground narration in those facts.
  • Expose at least one user-facing channel and SHOULD expose multiple with equivalent functionality.
  • Emit structured metrics, distributed traces, and structured logs correlated by trace identifier.
  • Provide a complete audit trail of every request, classification, dispatch, and confirmation.

1.2 Scope

This specification covers:

  • The 9-level context model and resolution algorithm.
  • Interaction patterns, request classification, and TWO-STEP confirmation.
  • Intent routing and multi-step chain orchestration semantics.
  • Anti-fabrication requirements binding the system's narration to verifiable facts.
  • The safety classification taxonomy and graduated response requirements.
  • The modular extension contract: manifest schema categories, registration, and lifecycle.
  • Proactive intelligence: background context refresh, anomaly surfacing, and alert protocol.
  • Channel abstraction and cross-channel continuity.
  • Observability and audit primitives required of all compliant implementations.
  • Three conformance levels and their cumulative requirements.

This specification does NOT cover:

  • The specific AI engine or foundation model implementation — any compliant model may be used.
  • Domain-specific operations — those belong to domain extensions built on top of this protocol.
  • User interface design — channel implementations handle presentation.
  • Storage, networking, or process orchestration architecture beneath the protocol.
  • Proprietary classifier, router, or execution mechanisms — only their contracts.

1.3 Motivation

Artificial intelligence has achieved remarkable capability at the model layer. Foundation models can reason, draft, summarize, and converse with humanlike fluency. Yet several open problems remain unsolved at the model layer because they are not, by their nature, model problems. They are system problems:

Open problem Why the model layer cannot solve it alone
Hallucination Probabilistic generation, by definition, can 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.

ICNLI v2.0 specifies the protocol that addresses these system problems with architectural commitments. A compliant implementation does not depend on a particular model being well-behaved; it depends on the protocol contract being enforced.

1.4 Design Goals

Goal Description
Domain-Agnostic The protocol applies to any operational domain — no domain assumptions in the core spec.
Context-First Every interaction occurs within structured, multi-level domain context — never blind.
Modular Composition (NEW) Extensions, channels, tools, and domains MUST plug into a finite kernel through declared contracts; the kernel surface is stable, the extension surface is unbounded.
Proactive Awareness (NEW) At higher conformance, the system MUST watch its domain, surface concerns, and propose actions without prompting.
Safe by Default All state-changing operations require explicit human confirmation — mandatory, not optional.
Channel-Neutral Identical capabilities and identical context across every supported communication interface.
Anti-Fabrication The system MUST ground narration in verifiable facts preserved across turns.
Auditable Every interaction, classification, dispatch, and confirmation MUST be logged.
Observable Structured metrics, traces, and logs are protocol-level requirements, not optional add-ons.
Implementation-Neutral Any AI engine, any storage system, 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: Infrastructure Contextual Natural Language Interface.

The protocol's scope has since generalized. Every normative requirement in this specification is domain-agnostic by construction: nothing in the Context Model, Interaction Protocol, Safety Layer, Anti-Fabrication Contract, Chain Orchestration, Proactive Intelligence, or Observability requirements is specific to hosting, infrastructure, or any single vertical.

Readers new to the protocol may reasonably read the acronym as:

  • Interface — the noun.
  • Infrastructure Contextual Natural Language — the descriptor of operational style: structured context, multi-actor permission boundaries, consequential action gates, natural-language surface.

The acronym is not renamed for continuity with prior work. If continuity ever costs more than clarity, a future major version may revise. v2.0 retains it.

2. Terminology

2.1 Key Terms

Term Definition
ICNLI Infrastructure Contextual Natural Language Interface — the open standard (a behavioral specification in the POSIX / OpenAPI standards category) defined in this document under CC BY-SA 4.0.
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 operational user — the runtime client of the kernel-grade primitives (context resolution, intent routing, action execution, memory, audit). The human remains the authorizing principal for every consequential action; see §8 Safety Layer for the TWO-STEP confirmation contract. The inversion is about who the OS is built for at runtime, not who holds authority over what it executes.
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–L8).
Tool A defined executable function with typed parameters, a safety classification, and required permissions.
Channel A communication interface (web, messaging, voice, API, etc.) 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) → Confirm → 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 the system's narration MUST be grounded in verifiable facts and MUST NOT claim results not present in the fact ledger.
Fact Ledger The structured, per-turn record of verbatim tool outputs preserved across the session 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.

2.2 Conformance Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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.

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.

[ANTI-PATTERN]
User: "Delete the database"
System: "Deleting database..."  ❌  no context resolved

[ICNLI PATTERN]
User: "Delete the database"
System: "Three databases match. Which one — production, staging, or archive?"

3.2 Principle 2: Modular Composition (NEW)

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.

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

3.3 Principle 3: Proactive Awareness (NEW)

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 the web 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:

┌─────────────────────────────────────────────────────────────┐
│ Level 0: PLATFORM CONTEXT (Global)                          │
│ Platform capabilities, available tools, system status       │
├─────────────────────────────────────────────────────────────┤
│ Level 1: ACTOR CONTEXT (Who)                                │
│ Identity, authentication, roles, permissions                │
├─────────────────────────────────────────────────────────────┤
│ Level 2: ACCOUNT CONTEXT (Ownership)                        │
│ Account, subscription, quotas, limits                       │
├─────────────────────────────────────────────────────────────┤
│ Level 3: SERVICE CONTEXT (What)                             │
│ Services owned by the actor, their status and configuration │
├─────────────────────────────────────────────────────────────┤
│ Level 4: ENVIRONMENT CONTEXT (Where)                        │
│ Hosts, regions, environments, deployment topology           │
├─────────────────────────────────────────────────────────────┤
│ Level 5: APPLICATION CONTEXT (Apps)                         │
│ Applications, datasets, channels deployed in environments   │
├─────────────────────────────────────────────────────────────┤
│ Level 6: RESOURCE CONTEXT (Details)                         │
│ Records, files, configurations, metrics                     │
├─────────────────────────────────────────────────────────────┤
│ Level 7: RELATIONSHIP CONTEXT (Between)                     │
│ Connections and dependencies between entities               │
├─────────────────────────────────────────────────────────────┤
│ Level 8: INTERCONNECTION CONTEXT (Across)                   │
│ Cross-system dependencies and cascade impact analysis       │
└─────────────────────────────────────────────────────────────┘

4.1.1 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, investigative case management) required at minimum:

  1. The platform itself — what is handling the request (L0)
  2. The actor making the request — identity and permissions (L1)
  3. The actor's ownership boundary — what they are entitled to operate on (L2)
  4. The set of relevant operational entities — services, encounters, cases, accounts (L3)
  5. The environment those entities live in — virtual or physical infrastructure (L4)
  6. The applications or processes they expose — software, devices, workflows (L5)
  7. The resources they consume — files, configs, signals, data (L6)
  8. The relationships among them — what depends on what (L7)
  9. The cross-system interconnections — cascade effects (L8)

Collapsing any two of these levels lost expressive power in at least one of the audited domains. 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 / SSL 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 MUSTs apply unchanged. The domain supplies the payload; the protocol supplies the shape.

4.2 Context Requirements by Conformance Level

Context Level Conformance Level 1 Conformance Level 2 Conformance 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

4.3 Context Resolution

Implementations MUST resolve context in order from L0 upward. Lower levels MUST be available before higher levels are referenced. The following pseudocode describes the minimum resolution algorithm:

def resolve_context(request: Request) -> Context:
    context = Context()

    # Level 0: Platform (always available)
    context.platform = get_platform_context()

    # Level 1: Actor (from authentication)
    context.actor = authenticate(request)
    if not context.actor:
        raise AuthenticationRequired()

    # Level 2: Account (derived from actor)
    context.account = get_account(context.actor)

    # Level 3+: Lazy or eager loading per implementation
    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

Implementations MAY load deeper levels lazily, eagerly, or selectively. Implementations MUST NOT skip levels: a request that references L5 MUST also have L0–L4 resolved.

4.4 Context Example

A domain-agnostic example context for the request "Show me what depends on service A":

{
  "platform": {
    "name": "ExampleCompliantImpl",
    "specification_version": "2.0",
    "conformance_level": 3,
    "status": "operational"
  },
  "actor": {
    "id": "actor_12345",
    "role": "client",
    "authenticated_via": "web",
    "session_id": "sess_abc123"
  },
  "account": {
    "id": "acc_67890",
    "type": "standard",
    "services_count": 3
  },
  "services": [
    {
      "id": "svc_A",
      "type": "compute",
      "status": "active",
      "environment_id": "env_eu_west"
    },
    {
      "id": "svc_B",
      "type": "datastore",
      "status": "active",
      "environment_id": "env_eu_west"
    }
  ],
  "resources": [
    {
      "id": "res_001",
      "kind": "application",
      "service_id": "svc_A"
    }
  ],
  "relationships": {
    "svc_A": {
      "depends_on": ["svc_B"],
      "impacts": ["res_001"]
    }
  }
}

The shape above is illustrative. Compliant implementations MAY enrich it with domain-specific fields, MUST preserve the level structure, and MUST mask personally identifiable information by default when transmitting context to the model layer.

5. Interaction Protocol

5.1 Request Types

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

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 (see Section 3.7). The classification algorithm is implementation-specific and MAY be proprietary; its contract is normative.

Normative. Implementations MUST use a learned intent classifier, not substring or keyword matching. Lexical matching on natural language is insufficient: "show me what would happen if I deleted the database" contains both show and deleted and is a query (it asks for an impact analysis), not a mutation. A classifier that distinguishes such cases is mandatory.

def classify_request(request: NaturalLanguageRequest, context: Context) -> RequestType:
    """
    Request classification — normative algorithm sketch.

    Implementations MUST use a learned classifier (LLM-based or trained
    intent model) that emits a typed RequestType. Substring or regex
    keyword matching is INSUFFICIENT and MUST NOT be used as the sole
    classification mechanism — natural language is too ambiguous for
    lexical matching to reach the precision the protocol requires.

    The classifier MUST be deterministic for a given (request, context)
    pair within a session — implementations may use temperature=0 or
    equivalent for the classification step.

    The classifier MUST emit, in addition to the RequestType:
      - action_type:    "read" | "write" | "destructive"
      - target_domain:  one of the registered operational domains
      - confidence:     a value in [0, 1]

    Confidence below an implementation-defined threshold (RECOMMENDED <= 0.7
    for destructive intents) MUST trigger a clarification request, NOT
    a best-effort dispatch.
    """
    classifier_output = run_intent_classifier(
        text=request.text,
        context=context,
        registered_domains=context.platform.domains,
    )

    if classifier_output.confidence < context.platform.confidence_threshold:
        return RequestType.CLARIFICATION_NEEDED

    return RequestType(
        type=classifier_output.request_type,
        action_type=classifier_output.action_type,
        target_domain=classifier_output.target_domain,
        confidence=classifier_output.confidence,
    )

5.3 TWO-STEP Confirmation Protocol

All MUTATION requests MUST follow the TWO-STEP pattern:

┌─────────────────────────────────────────────────────────────┐
│                    TWO-STEP PROTOCOL                        │
└─────────────────────────────────────────────────────────────┘

Step 1: PROPOSAL
────────────────
Request → Classify → Resolve Context → Plan → Analyze Impact
                                                    ↓
                                            Generate Proposal
                                                    ↓
                                            Present to Actor
                                            ┌─────────────────┐
                                            │ Summary         │
                                            │ Affected Items  │
                                            │ Impact Notes    │
                                            │ Confirmation?   │
                                            └─────────────────┘

Step 2: EXECUTION
─────────────────
Actor Confirms → Validate Confirmation Token → Execute
                                                  ↓
                                            Report Result

5.4 Confirmation Tokens

To prevent accidental confirmations, implementations MUST issue confirmation tokens with the following properties:

{
  "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_id per proposal.
  • Set an expiration. The RECOMMENDED expiry is five minutes.
  • Reject confirmations after expiration.
  • Reject confirmations whose proposal_id 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.

5.5 Conversation Flow

┌──────────┐     ┌───────────┐     ┌──────────┐     ┌──────────┐
│  START   │────▶│  CONTEXT  │────▶│ CLASSIFY │────▶│ DISPATCH │
└──────────┘     │  RESOLVE  │     │ + ROUTE  │     └──────────┘
                 └───────────┘     └──────────┘           │
                       │                 │                ▼
                       ▼                 ▼          ┌──────────┐
                 ┌───────────┐    ┌────────────┐    │ NARRATE  │
                 │  Missing  │    │ MUTATION?  │    │ + AUDIT  │
                 │  Context  │    │  TWO-STEP  │    └──────────┘
                 └───────────┘    └────────────┘          │
                       │                 │                ▼
                       ▼                 ▼          ┌──────────┐
                 ┌───────────┐    ┌────────────┐    │  AWAIT   │
                 │   ASK     │    │  CONFIRM?  │◀───│  INPUT   │
                 │ CLARIFY   │    │  EXECUTE   │    └──────────┘
                 └───────────┘    └────────────┘

6. Intent Routing and Chain Orchestration

Relation to prior art. This pattern is not unique to ICNLI: MCP standardises tool discovery, OpenAI Function Calling standardises tool invocation, and frameworks such as LangChain 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 produces higher precision and 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.

domain_registry:
  domain_a:
    - tool_a_status
    - tool_a_update
  domain_b:
    - tool_b_list
    - tool_b_create
  # additional domains per implementation

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

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

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 to either fail explicitly or 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

7.1 The Anti-Fabrication Contract

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.

7.2 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.3 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.
  • Quantify a result not enumerated in the underlying facts.
  • 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.4 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.5 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 mask = on; the opt-in MUST be explicit.

7.6 Applicability

The Anti-Fabrication Contract is REQUIRED at all conformance levels. It is not a higher-tier feature; it is the minimum bar for a compliant Modular Proactive AI Cloud OS implementation.

7.7 Scope of guarantee

The Anti-Fabrication Contract has explicit normative scope. Implementations and reviewers MUST understand the following distinctions. Structural and contractual are not synonyms here — they describe different architectural classes of enforcement.

Layer What is guaranteed Enforcement class
Provenance (fact ledger) Tool-call output preserved verbatim across turns; substitution detectable Structural — kernel-enforced, append-only hash chain; survives any LLM judge failure
Tool surface (intent routing) Model can invoke ONLY tools the classifier surfaced; tools outside the routed subset are structurally unreachable Structural — kernel decides surface before model sees it; model cannot widen it
PII masking gate PII filtered from context delivered to model by default; unmasking explicit, opt-in, audited Structural — kernel filters context before transmission; model never sees masked values in default mode
Grounded narration Narrator MUST NOT claim values, quantities, or statuses absent from the ledger Contractual — runtime judge (LLM-based at v2.0) on a smaller residual surface; itself probabilistic, not structural

Why the distinction matters. The three structural layers hold regardless of whether the LLM judge is correct, regardless of which foundation model is loaded, and regardless of whether the narration judge passes or fails on a given turn — they remove fabrication classes at the surface, before they can occur. The contractual narration layer further constrains residual fabrication, but it is enforced by another LLM and is therefore itself probabilistic. A compliant implementation MUST NOT describe the runtime judge as a structural guarantee. The contract REDUCES ungrounded fabrication to a low residual surface area; it does NOT eliminate the category in the formal sense.

Strict structural impossibility of fabrication would require constrained generation against a formal grammar or a symbolic intermediate representation, neither of which is normatively required by v2.0. Implementations MAY exceed this baseline with stricter enforcement (e.g., NLI/entailment judges, constrained decoding, formal-grammar emission). Such enhancements MUST NOT weaken the contract surface defined in §§7.1–7.5, and MUST be honestly classified as structural or contractual according to the criteria above.

8. Safety Layer

Relation to prior art. TWO-STEP confirmation patterns exist throughout systems engineering — from UNIX rm -i (1979), to Terraform plan/apply, to GitHub's repository-delete confirmation. ICNLI's contribution is making the gate normative at the protocol level: classification on the 0–4 scale, mandatory impact analysis from L2 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 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.

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 impact details Yes Required Recommended
4 Yes with danger phrase Yes Required Required (≥30 s)

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

System: "⚠ CRITICAL OPERATION

         You are about to permanently delete the resource 'res_001'.
         This action cannot be undone.

         To confirm, type exactly: DELETE res_001"

8.5 Role-Based Safety

The canonical example roles are guest, client, and admin — examples only. Compliant implementations MAY define additional roles. Implementations MUST enforce role-based access on every tool dispatch and MUST log authorization failures.

# Example role configuration; role names are illustrative.
roles:
  guest:
    allowed_safety_levels: [0]
  client:
    allowed_safety_levels: [0, 1, 2, 3]
  admin:
    allowed_safety_levels: [0, 1, 2, 3, 4]

8.6 Classifier Dependency and Defense-in-Depth

The TWO-STEP confirmation gate is enforced structurally by the kernel — once invoked, no prompt can talk it out of asking, no extension can bypass it, no model output can substitute for the explicit human confirmation token. This part is structural.

The decision to invoke the gate at the correct safety level, however, depends on the request classifier output (§5.2). The classifier is normatively required to be a learned/LLM-based intent model rather than substring matching, and is therefore probabilistic in nature. This creates a genuine attack surface that this specification MUST disclose honestly: a misclassified destructive operation (classified as read) bypasses the gate that would otherwise have fired at the correct level.

The protocol's defense-in-depth response operates on three layers:

  1. Confidence threshold + clarification fallback (§5.2). Confidence below an implementation-defined threshold (RECOMMENDED ≤0.7 for destructive intents) MUST trigger a clarification request, NOT a best-effort dispatch. Low-confidence cases are routed to the human rather than to the wrong gate.
  2. Per-step safety classification at chain orchestration (§6.3). Chains containing a level-3 or level-4 step MUST request confirmation before the destructive step executes, regardless of the chain's overall classification. A misclassified individual step still surfaces if the step-level classification is correct.
  3. Audit substrate observation (§12). Every classification decision is recorded. Misclassification patterns are observable in the audit trail and can be measured against ground truth as the conformance test suite (v2.1 roadmap) ships an adversarial harness.

This is a defense-in-depth design, not a claim that misclassification cannot occur. The gate itself is deterministic; the trigger condition is probabilistic and bounded by the three layers above. A compliant implementation MUST disclose this dependency in its conformance declaration (§13.4) and MUST instrument the classifier outputs in the audit substrate for adversarial evaluation by reviewers.

8.7 Impact Analysis Groundedness

The Impact Analysis presented to the actor before any L2+ confirmation (§8.3) enumerates direct targets, cascade targets derived from the Context Model (§4), reversibility, and backup status. The actor uses this presentation to decide whether to authorize the operation. The Impact Analysis itself is, by construction, generated content — composed by the implementation from facts in the fact ledger (§7.2) and the resolved Context Model (§4.3).

This creates a critical attack surface that this specification MUST disclose honestly: an actor authorizing on the basis of an Impact Analysis that contains a fabricated cascade count, an omitted dependency, or an incorrect reversibility assertion has been deceived by the system the protocol was built to make trustworthy. The deterministic TWO-STEP gate does not, on its own, defend against a misleading Impact Analysis. This is the central remaining hole in the safety model, and the protocol names it explicitly here so implementers, reviewers, and authorizing principals understand exactly what the gate does and does not guarantee.

The protocol's defense-in-depth response operates on four layers:

  1. Provenance constraint (structural — kernel-enforced). Impact Analysis contents MUST be drawn from verbatim fact-ledger entries (§7.2). An implementation SHOULD render the source ledger entries inline (e.g., "2 dashboards depend on this host — dashboard_id=d7a3, dashboard_id=f9c1") so the actor can visually verify the count against the underlying facts before authorizing.
  2. Context Model contract (structural — kernel-enforced). Cascade targets at L7/L8 MUST be resolved by the kernel from declared dependency graphs in the Context Model (§4.3), not generated from the model's prose. An implementation that derives cascade counts from generated text rather than from kernel-resolved relationships is non-conformant.
  3. Grounded narration MUST (contractual — probabilistic). The narration layer presenting the Impact Analysis is bound by the grounded-narration MUST (§7.3) — it MUST NOT quantify a result not enumerated in the underlying facts. Runtime judges (currently LLM-based) check for adherence; this is contractual, not structural, and operates on a smaller residual surface but does not, on its own, eliminate the category in the formal sense.
  4. Audit substrate observation (forensic). Every Impact Analysis MUST be recorded in the audit trail with both the rendered narration and the underlying fact-ledger entries it was composed from (§12). Post-hoc divergence is detectable; the audit chain reveals fabrication. Forensic detection is not user-time protection — but it is the substrate against which adversarial conformance harnesses (v2.1 roadmap) measure rate.

Layers 1 and 2 are structural; Layer 3 is contractual; Layer 4 is forensic. A compliant implementation MUST disclose this design in its conformance declaration (§13.4) and SHOULD render Impact Analysis with inline ledger references so the authorizing principal sees verifiable provenance, not narration alone. Naming this hole explicitly is itself part of the contract — implementations that present Impact Analysis without provenance reference and without the four-layer disclosure are conformance-incomplete.

8.8 Aggregate / Cascade Danger Across Chain Steps

The safety classification (§8.1) applies per tool. A chain of individually-classified-safe steps may nonetheless produce a cumulatively destructive outcome — ten L2 writes that together rewrite a critical configuration, three L2 deletes that together remove a dataset, a series of L1 updates that compose to disable a safety system. None of these individually trigger an L4 danger phrase, but their aggregate effect MAY exceed any individual step's classification. This is the chain-decomposition attack class: structure a destructive operation as many individually-safe steps to evade the L4 phrase requirement.

The protocol's normative response:

  1. Per-chain aggregate classification. A chain orchestrator (§6.3) MUST evaluate whether the aggregate effect of all chain steps elevates the chain's effective safety level above any individual step's classification. Heuristics MAY include: same-resource cumulative writes, sequence of state mutations on a single ownership boundary, or implementation-declared aggregate-danger patterns derived from §4.3 cascade context.
  2. Confirmation escalation. If the aggregate classification exceeds the highest individual step's classification, the chain MUST request confirmation at the aggregate level before the first state-changing step executes. A chain producing aggregate L4 effect MUST require an L4 danger phrase even if no individual step is classified L4.
  3. Audit recording. The aggregate classification, the heuristics applied, and the resulting confirmation level MUST be recorded in the audit substrate (§12) so reviewers can verify the elevation logic post-hoc.

Aggregate-danger heuristics are a normative-presence requirement; specific heuristics are implementation-specific and SHOULD be documented in the implementation's conformance declaration (§13.4). Implementations that do not elevate confirmation for aggregate effect are conformance-incomplete and MUST disclose this gap explicitly.

9. Modular Extension Contract

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.
  • Fact ledger and memory.
  • Extension lifecycle and validation.

Extensions own:

  • The tools they declare.
  • The domain capabilities they implement.
  • 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.

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 (e.g., L1 / L2 / L3).
Tools The list of declared tools, each with name, safety classification, parameters, and return shape.
Capabilities Declared capability surface (e.g., contributed panels, contributed channels, contributed 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.

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. Proactive Intelligence Requirements

Relation to prior art. Background observation and alerting is well-established in operations engineering — Nagios (1999), Prometheus + Alertmanager, Datadog, and the long tail of CRON + script-driven 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.
  • Outstanding follow-ups, pending confirmations, or alert states.

The profile MUST be subject to the PII masking gate of Section 7.5.

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 (UI/channel) and the substrate that powers it is a long-established software engineering pattern — MVC (1979), hexagonal architecture, ports-and-adapters. ICNLI's contribution is orthogonal to those patterns: cross-surface state continuity (same session, same fact ledger, same audit trail, same TWO-STEP gate preserved across channels) is a property that traditional architectural separations do not provide on their own — those patterns separate concerns within one application; channel neutrality preserves them across multiple applications and surfaces.

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)

Channel Type Input Output
Web GUI Text + interaction Rich HTML
Messaging Conversational Text + commands Markdown + interactive elements
Voice Audio Speech (STT) Speech (TTS)
API Programmatic Structured request Structured response
CLI Terminal Text Plain text

Implementations MAY add or omit channels. The list above 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. Observability and Audit Requirements

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

{
  "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,
    "response_token": "<<one-time>>",
    "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 audit_block_hash is computed over the entry's content concatenated with the prior entry's audit_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.
  • Use SHA-256 or stronger as the digest function (SHOULD).
  • Persist the chain in append-only storage or its functional equivalent (SHOULD).

This requirement applies at L2 conformance and above. L1 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. A broken collector cannot be permitted to break the OS.

13. Conformance Levels

ICNLI v2.0 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–L2.
  • Support at least one channel.
  • Provide tool discovery (Section 9 manifest categories exposed via at least one introspection surface).
  • Log all operations with timestamps.
  • 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–L6.
  • Implement safety classification levels 0–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.
  • 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–L8 including relationship and interconnection context.
  • Implement Chain Orchestration (Section 6.3) including Step-Output References (Section 6.4).
  • Satisfy Proactive Intelligence Requirements (Section 10) in full, including 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.
  • 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",
    "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

A normative MUST defines the contract surface — not the certification of any specific implementation. This distinction is load-bearing. A specification's MUST clauses state what an implementation must satisfy in order to claim compliance; they do not, on their own, certify that any specific implementation in fact satisfies the contract. The specification is the published text; certification is the automated verification of the contract against an implementation. Both have value; neither substitutes for the other.

Conformance to ICNLI v2.0 is currently self-declared. There is no automated test suite, no canonical reference fixtures, no adversarial conformance harness at the time of this specification's publication.

This is a known gap. It is the v2.1 critical-path deliverable, not "as time permits." Until the test suite ships:

  • "ICNLI v2.0 compliant" is a self-attested 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, regardless of self-assessed completeness against the MUST clauses.
  • Implementations SHOULD publish their conformance self-assessment as a checklist mapped to specific MUST/SHOULD clauses, so independent reviewers can evaluate the claim against the specification text without having to reconstruct the mapping.

Implementations claiming any level of conformance MUST NOT use the term "certified" until automated verification is available. Reviewers MUST NOT treat a self-attested claim as equivalent to a verified one; the specification is honest about which is which.

14. Security Considerations

14.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 timeout appropriate to the deployment context.

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

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

14.4 Data Protection

Implementations MUST encrypt sensitive data at rest, MUST use TLS for transport, MUST mask sensitive values in logs and metrics labels, MUST implement data retention policies appropriate to the deployment domain, and MUST support on-premises deployment for domains that require it.

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

15. Implementation Guidelines

15.1 Architecture Recommendation (Domain-Agnostic)

The following diagram illustrates a recommended architecture for a compliant implementation. Component names are generic; the diagram is normative only at the level of the layered separation it shows.

┌─────────────────────────────────────────────────────────────┐
│                     ICNLI-COMPLIANT SYSTEM                  │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │   Web    │  │ Messaging│  │   Voice  │  │   API    │    │
│  │  Channel │  │  Channel │  │  Channel │  │  Channel │    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
│       └─────────────┴─────────────┴─────────────┘          │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │   Channel Gateway     │                      │
│              │  (Auth, Rate Limit)   │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │  Context Aggregator   │                      │
│              │   (Resolve L0–L8)     │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │  Classifier + Router  │                      │
│              │   (Intent + Domain)   │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │   Chain Orchestrator  │                      │
│              │  (Topo, References)   │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │    Safety + Confirm   │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │ Extension Registry +  │                      │
│              │     Tool Dispatch     │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │   Fact Ledger + UIP   │                      │
│              └───────────┬───────────┘                      │
│                          ▼                                  │
│              ┌───────────────────────┐                      │
│              │  Audit + Observability│                      │
│              └───────────────────────┘                      │
└─────────────────────────────────────────────────────────────┘

15.2 Context Caching

Implementations SHOULD cache frequently accessed context, MUST invalidate cache entries on relevant mutations, SHOULD use TTL-based expiration appropriate to the data, and SHOULD pre-warm cache for common patterns where the deployment justifies it.

15.3 Error Handling

Implementations MUST handle errors with structured types and structured responses. Errors MUST be surfaced to the actor in a form appropriate to the channel and SHOULD include suggestions for remediation where possible.

15.4 Testing Requirements

Implementations SHOULD include unit tests for each declared tool, integration tests for the TWO-STEP and chain flows, security tests for authorization, load tests for concurrent dispatch, and channel-equivalence tests confirming that the same action through different channels produces equivalent results.

Appendices

Appendix A: Example Conversation

A domain-agnostic dialogue exercising context resolution, intent routing, chain orchestration, impact analysis, TWO-STEP confirmation, and grounded narration.

[Context: Actor "Alex" authenticated; account has multiple services.]
[Conformance Level 3 implementation.]

────────────────────────────────────────────
Alex: What would be affected if I retire service A?

System (QUERY → routed to relationship + dependency domains;
        chain composed: list_dependents → list_consumers → summarize):

       Service A has the following dependents:
       • Resource res_001 (status: active)
       • Service B (depends on A for upstream data)
         └─ Service B in turn supports res_004 and res_005.

       3 direct dependents, 2 cascade dependents. No backups required for
       a retirement (resources remain intact); however, dependents will
       lose their upstream during the retirement window.

────────────────────────────────────────────
Alex: OK, retire service A then.

System (MUTATION classified at safety level 3; TWO-STEP triggered):

       Proposal: retire service A.

       Direct impact:
         • Service A → state = retired
       Cascade impact:
         • res_001 → upstream becomes unavailable
         • Service B → degraded mode

       This action is reversible within 24 hours from the audit log.

       To proceed, confirm by replying "yes" within the next 5 minutes.

────────────────────────────────────────────
Alex: yes

System (confirmation token validated; chain executed in topological order:
        notify_dependents → retire_service_a → write_audit):

       Service A retired.
         • Dependents notified: res_001, Service B
         • Audit record: aud_2026_05_17_001
         • Reversal window: until 2026-05-18T10:00:00Z

       Narration grounded in the chain's verbatim outputs; no value above
       was synthesized.

Appendix B: Tool Reference Template

The following YAML is a vendor-neutral template for a tool definition declared inside an extension manifest. Field names are illustrative; the categories of information are normative per Section 9.2.

Machine-readable schema. A reference Tool Definition schema is published as part of the imperal-sdk package on PyPI (pip install imperal-sdk), at imperal_sdk/schemas/imperal.schema.json. The YAML example below is illustrative; the published JSON Schema is the reference for implementations that wish to validate tool definitions programmatically. Implementations validating tool definitions SHOULD use a published JSON Schema and MUST report the schema version they validated against.

tool:
  name: ""                        # snake_case, globally unique within the extension
  display_name: ""                # human-readable
  description: ""                 # full description
  category: ""                    # standard category
  safety_level: 0                 # 0-4 per Section 8.1

  parameters:
    - name: ""
      type: ""                    # string | integer | boolean | array | object
      required: false
      description: ""
      default: null
      validation: {}

  returns:
    type: ""
    description: ""
    schema: {}

  requires_context:
    - ""                          # required context levels: L0..L8

  permissions:
    - ""                          # minimum permissions required from the actor

  examples:
    - input: ""
      parameters: {}
      output: ""

  errors:
    - code: ""
      description: ""

Appendix C: Context Schema (Domain-Agnostic)

Status of this schema. The schema below is an illustrative draft showing the top-level shape of the Context object. It is NOT the normative schema; the reference machine-readable schema lives in the SDK's published JSON Schema (see Appendix B). A formally-typed, deeply-validated Context schema is on the v2.1 roadmap. Implementations should not rely on this appendix for production validation.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ICNLI Context v2.0",
  "type": "object",
  "properties": {
    "platform": {
      "type": "object",
      "properties": {
        "name": {"type": "string"},
        "specification_version": {"type": "string"},
        "conformance_level": {"type": "integer", "minimum": 1, "maximum": 3},
        "status": {"type": "string"}
      },
      "required": ["name", "specification_version", "conformance_level"]
    },
    "actor": {
      "type": "object",
      "properties": {
        "id": {"type": "string"},
        "role": {"type": "string", "description": "Example values: guest, client, admin"},
        "authenticated_via": {"type": "string"},
        "session_id": {"type": "string"}
      },
      "required": ["id", "role"]
    },
    "account": {
      "type": "object",
      "properties": {
        "id": {"type": "string"},
        "type": {"type": "string"}
      },
      "required": ["id"]
    },
    "services": {
      "type": "array",
      "items": {"type": "object"}
    },
    "resources": {
      "type": "array",
      "items": {"type": "object"}
    },
    "relationships": {
      "type": "object",
      "additionalProperties": {
        "type": "object",
        "properties": {
          "depends_on": {"type": "array", "items": {"type": "string"}},
          "impacts": {"type": "array", "items": {"type": "string"}}
        }
      }
    },
    "fact_ledger": {
      "type": "array",
      "description": "Verbatim per-turn tool outputs preserved within the session.",
      "items": {"type": "object"}
    }
  },
  "required": ["platform", "actor"]
}

Appendix D: Revision History

Version Date Status
1.0.0 2025-12-30 First created — protocol origin. The first public release of the ICNLI specification under the Modular Proactive AI Cloud OS framing.
2.0 2026-05-31 Current published specification — see Section 13 for normative conformance levels.

ICNLI was first created on 30 December 2025 as v1.0.0 — the protocol's origin and first public release under the Modular Proactive AI Cloud OS framing. The current published specification is v2.0 (May 2026). The normative contract is defined in Sections 1 through 15; conformance levels are defined in Section 13; the modular extension contract is defined in Section 9; the anti-fabrication contract is defined in Section 7; chain orchestration is defined in Section 6.

Future revisions will be listed here with their normative deltas. Implementations targeting v2.0 declare conformance per the machine-readable form in Section 13.4 and audit against the test suite delivered in v2.1 (roadmap milestone — see whitepaper §15).

About the Author

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

License

© 2026 Valentin Scerbacov / Imperal, Inc.

This specification is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You are free to share and adapt this material for any purpose, including commercial, under the terms of attribution and share-alike.

Full license: https://creativecommons.org/licenses/by-sa/4.0/

ICNLI™ is a trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this specification but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. Webbee™ is a trademark of WebHostMost.

  • Creator: Valentin Scerbacov
  • Trademark Owner: Imperal, Inc.
  • Website: icnli.org
  • Trademark inquiries: license@icnli.org
  • Flagship implementation: imperal.io
  • Reference agent: Webbee
  • First enterprise production deployment: WebHostMost

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

END OF SPECIFICATION