ICNLI Whitepaper¶
Infrastructure Contextual Natural Language Interface¶
The Operating System Between Artificial Intelligence and the Real World¶
Version: 1.1.3
Date: March 2026
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 registered trademark of Imperal, Inc.
Executive Summary¶
Every major revolution in computing began with a new foundational layer.
The operating system abstracted hardware so that applications didn't need to understand transistors. TCP/IP abstracted networks so that applications didn't need to understand routing. HTTP abstracted communication so that browsers didn't need to understand servers.
Each layer unlocked an entirely new era — not by making the layer below faster, but by making it universally accessible.
We are at the next inflection point.
Artificial intelligence has matured to the point where machines understand human language with remarkable accuracy. Yet this intelligence remains fundamentally disconnected from the real world it is meant to serve. AI models know about your domain in general. They do not know your domain specifically. They can reason about what you describe. They cannot perceive what you have not told them. They act on instructions. They do not act on awareness.
The missing layer between artificial intelligence and the real world is not more intelligence. It is context, structured domain awareness, and a safe execution contract.
ICNLI (Infrastructure Contextual Natural Language Interface) is that layer.
ICNLI is an open protocol — not a product, not a chatbot, not an AI model. A protocol. One that any system, in any domain, can implement to gain something AI alone cannot provide: genuine situational awareness of the environment it operates in, the relationships within it, and the consequences of acting upon it.
The result is a system that does not merely respond to what you say. It understands what you mean, within the full context of your world — and proposes action with complete awareness of what that action will touch, change, and affect.
HTTP transports documents. TCP/IP transports data. ICNLI transports decisions.
This whitepaper describes the protocol, its architecture, and the paradigm shift it represents.
Core Protocol Innovations¶
- 9-Level Context Model — A formal hierarchy from platform identity to cross-system interconnections, mandatory for all compliant implementations
- Intent Domain Router — Proprietary classification layer that focuses the AI engine on relevant domain tools before each request
- Proactive Domain Intelligence — Systems maintain a continuously updated awareness of their domain before being asked
- TWO-STEP Safety Protocol — Every state-changing operation requires explicit human confirmation — mandated by the protocol, not optional policy
- Channel Neutrality — Identical capabilities and context across every interface: web, mobile, voice, messaging, API
- ICNLI Worker — Durable, fault-tolerant workflow execution that survives failures and maintains state across complex multi-step operations
What This Enables¶
A hospital system that knows every patient, every drug interaction, every device — and proposes clinical decisions with full consequence mapping before a single action is taken.
An investigative platform that connects data across sources, surfaces relationships automatically, and presents structured, auditable action proposals to the operator.
A hosting platform where a client says "my site is slow" and receives a specific diagnosis of their site, with an actionable fix, executable on confirmation.
A city infrastructure that watches itself, detects anomalies proactively, and proposes coordinated responses — with a human in control of every decision.
One protocol. Any domain. The only limit is the domain you choose to map.
Table of Contents¶
- The Problem
- Evolution of Infrastructure Interfaces
- Introducing ICNLI
- Core Concepts
- The Context Advantage
- Safety by Design
- Multi-Channel Freedom
- Technical Architecture
- Comparison with Alternatives
- Use Cases
- Implementation: Webbee
- Open Standard Strategy
- Future Roadmap
- Conclusion
1. The Problem¶
1.1 The Complexity Crisis¶
Modern digital infrastructure is more capable than ever—and more complex than ever. A typical small business website involves:
- Domain registration and DNS configuration
- Server provisioning and security hardening
- Web server configuration (nginx/Apache)
- SSL certificate management
- Database setup and optimization
- Email configuration (SPF, DKIM, DMARC)
- Backup strategies
- Performance monitoring
- Security scanning
- Content management systems
Each component has its own interface, terminology, and best practices. Managing this stack requires expertise that most users don't have and don't want to acquire.
1.2 The Interface Gap¶
Current solutions fall into three categories:
| Solution | Pros | Cons |
|---|---|---|
| Control Panels (cPanel, Plesk, etc.) | Visual, discoverable | Complex, click-heavy, context-switching |
| CLI/APIs | Powerful, automatable | Steep learning curve, no guidance |
| Managed Services | No expertise needed | Expensive, limited control, slow |
None of these provide: - Natural interaction in human language - Understanding of YOUR specific infrastructure - Guidance based on your actual situation - The ability to act on your behalf safely
1.3 The AI Promise (Unfulfilled)¶
Modern AI assistants are remarkable at understanding language and providing advice. However, they:
- Don't know your infrastructure — They can't see your servers, websites, or databases
- Can't take action — They can only suggest commands, not execute them
- Lack persistence — Every conversation starts from zero
- Provide generic advice — They don't know if you have 1 or 100 websites
The result: users get advice that may not apply to their specific situation and must still manually execute every action.
1.4 The Cost¶
This complexity has real costs:
- Time: Hours spent on tasks that should take minutes
- Errors: Misconfiguration leading to downtime or security breaches
- Expertise: Need for specialized staff or expensive consultants
- Opportunity: Features not implemented because "it's too complicated"
2. Evolution of Infrastructure Interfaces¶
2.1 A Brief History¶
1970s-80s: Command Line
└─ Powerful but requires memorization
1990s: GUI Control Panels
└─ Visual but complex, click-heavy
2000s: Web-Based Panels
└─ Accessible but overwhelming options
2010s: APIs + Infrastructure as Code
└─ Automatable but requires development skills
2020s: AI Chatbots
└─ Natural language but no context or action
2025+: ICNLI
└─ Natural language WITH context AND action
2.2 The Missing Layer¶
Each evolution added capabilities but didn't solve the fundamental problem: interfaces require users to think like machines.
- CLI requires knowing exact commands
- GUIs require knowing which button does what
- APIs require understanding data structures
- Even AI chatbots require users to provide context manually
ICNLI inverts this relationship. The system maintains context about YOU and YOUR infrastructure, allowing natural requests without manual context-setting.
2.3 The New Layer¶
Every major computing revolution introduced a new foundational layer — not to replace what existed below, but to make it universally accessible above.
1970s: Operating Systems
└─ Abstracted hardware → anyone could write software
1980s: TCP/IP
└─ Abstracted networking → any machine could communicate
1990s: HTTP / World Wide Web
└─ Abstracted communication → any person could access information
2000s: Cloud Computing
└─ Abstracted infrastructure → any team could deploy at scale
2010s: Large Language Models
└─ Abstracted language → any system could understand text
2025+: ICNLI
└─ Abstracts domain complexity → any AI can act with genuine awareness
Each layer did not make the previous layer obsolete. It made it accessible to an order of magnitude more people and use cases. ICNLI does not replace AI models — it gives them the layer they need to be genuinely useful in real operational domains.
2.4 Paradigm Shift¶
| Traditional Approach | ICNLI |
|---|---|
| User navigates to feature | User states intent |
| User provides all context | System maintains complete domain context |
| User executes the action | System proposes, user confirms, system executes |
| User interprets the result | System explains outcome with full context |
| User tracks system state | System maintains awareness continuously |
| Reactive — responds to problems | Proactive — surfaces problems before they escalate |
| Blind execution | Consequence-aware execution |
3. Introducing ICNLI¶
3.1 What ICNLI Is¶
ICNLI is an open protocol for building systems that possess genuine domain awareness — enabling natural language interaction, structured contextual understanding, safe execution, and proactive intelligence across any operational domain.
It is not an AI model. It does not generate text or reason about general knowledge.
It is the architectural contract that defines how an AI engine should receive context, how it should route intent, how it should propose action, and how it should execute — safely, auditably, and with a human in control.
The operating system analogy is precise: just as an OS does not perform the computation itself but provides the structured environment in which computation happens reliably, ICNLI does not provide the intelligence itself — it provides the structured environment in which intelligence operates with domain awareness.
Without ICNLI:
AI Engine + User Request → Response
(intelligent, but blind — no domain knowledge)
With ICNLI:
AI Engine + 9-Level Domain Context + Intent Routing
+ Safety Contract + Action Execution
→ Aware Response + Safe Action + Audit Trail
(intelligent AND contextually grounded)
3.2 The Protocol Formula¶
| Component | What it defines |
|---|---|
| Context | 9 mandatory levels of domain awareness — who, what, where, how, why, relationships, dependencies |
| Intent | Natural language understanding with domain-specific routing to relevant tools |
| Action | Real execution with full consequence analysis before any state change |
| Safety | Mandatory human-in-loop confirmation — architectural requirement, not optional policy |
3.3 The Fundamental Distinction¶
AI models are trained to understand language. That is a remarkable capability.
ICNLI is designed to understand your domain. That is a different capability entirely.
| Aspect | AI Model alone | ICNLI-compliant system |
|---|---|---|
| Domain knowledge | General — knows about your domain type | Specific — knows your actual domain state |
| Actions | Executes what you describe | Executes with full awareness of consequences |
| Persistence | Stateless between sessions | Continuously aware across all sessions and channels |
| Proactivity | Responds when asked | Monitors and surfaces issues before you ask |
| Safety | Depends on how you prompt | Mandated by protocol — always enforced |
| Relationship awareness | Reasons about what you tell it | Maps actual live dependencies in your system |
| Applicability | General purpose | Deep purpose — any domain, completely |
3.4 Domain Agnosticism¶
The protocol does not know what "infrastructure" means. It does not know what "investigation," "patient," or "transaction" means either.
It defines context levels, safety contracts, and execution patterns. What you place inside those levels — that is the domain. And the domain can be anything.
"Check if my SSL certificates are expiring"
→ Protocol resolves: who is asking, which certificates are theirs,
current expiry status, impact of expiry, renewal action available
→ Response: specific, actionable, personalized
"Summarize the status of this investigation"
→ Protocol resolves: who is asking, their authorization level,
all entities in the case, current relationships, recent developments
→ Response: complete situational picture, proposed next actions
"Is patient 4471 stable for surgery tomorrow?"
→ Protocol resolves: patient record, current medications,
recent vitals, contraindications, surgical risk factors
→ Response: risk assessment with specific supporting data,
action proposal for physician confirmation
Same protocol. Different domains. Different data. Identical architecture.
4. Core Concepts¶
4.1 Context-First Architecture¶
Every ICNLI interaction occurs within rich context:
┌─────────────────────────────────────────────────────────────┐
│ USER REQUEST │
│ "Restart my database" │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ CONTEXT RESOLUTION │
├─────────────────────────────────────────────────────────────┤
│ Who is asking? │
│ └─ John Doe, Premium Client, Telegram Auth │
│ │
│ What databases does John have? │
│ └─ myapp_prod (MySQL, 2.3GB, Active) │
│ └─ myapp_staging (MySQL, 500MB, Idle) │
│ │
│ Which one likely needs restart? │
│ └─ myapp_prod has high CPU usage (possible issue) │
│ │
│ What depends on this database? │
│ └─ example.com (WordPress) │
│ └─ api.example.com (Backend) │
│ │
│ What's the risk? │
│ └─ ~30 seconds downtime for 2 websites │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ INFORMED RESPONSE │
│ │
│ "I'll restart your 'myapp_prod' database. This will │
│ briefly interrupt example.com and api.example.com │
│ (~30 seconds). Proceed?" │
└─────────────────────────────────────────────────────────────┘
4.2 The TWO-STEP Protocol¶
ICNLI mandates a confirmation step for all operations that change infrastructure:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ USER │ │ ICNLI │ │ INFRA │
│ REQUEST │────────▶│ PROPOSAL │────────▶│ EXECUTE │
└──────────┘ └──────────┘ └──────────┘
│
User Reviews
User Confirms
│
▼
(Only then does action execute)
Step 1: Propose - System analyzes request - System gathers all relevant context - System presents clear plan with impact
Step 2: Execute - User explicitly confirms - System performs operation - System reports results
This ensures AI assists, human decides.
4.3 Tools as First-Class Citizens¶
ICNLI systems expose infrastructure operations as "Tools"—well-defined functions with:
- Clear purpose and description
- Typed parameters with validation
- Safety classification
- Required permissions
- Example usage
tool: website_create
description: Creates a new website on the user's server
safety_level: 2 (significant change)
parameters:
- domain (required): The domain name
- php_version (optional): PHP version, default 8.2
- ssl_enabled (optional): Enable SSL, default true
4.4 Channel Independence¶
ICNLI provides identical capabilities regardless of access method:
┌───────────┐
Web ──────▶│ │
Telegram ──────▶│ ICNLI │──────▶ Same Capabilities
Discord ──────▶│ Core │──────▶ Same Context
Voice ──────▶│ │──────▶ Same Safety
API ──────▶│ │
└───────────┘
5. The Context Advantage¶
5.1 The 9-Level Context Model¶
ICNLI defines nine levels of context, from general to specific:
┌─────────────────────────────────────────────────────────────┐
│ L0: PLATFORM │
│ System capabilities, version, status │
├─────────────────────────────────────────────────────────────┤
│ L1: ACTOR │
│ Who is this? Authentication, roles, permissions │
├─────────────────────────────────────────────────────────────┤
│ L2: ACCOUNT │
│ Billing, subscription, quotas │
├─────────────────────────────────────────────────────────────┤
│ L3: SERVICES │
│ Purchased products (hosting, domains, etc.) │
├─────────────────────────────────────────────────────────────┤
│ L4: SERVERS │
│ Physical/virtual servers, IPs, resources │
├─────────────────────────────────────────────────────────────┤
│ L5: APPLICATIONS │
│ Websites, databases, email, apps on servers │
├─────────────────────────────────────────────────────────────┤
│ L6: RESOURCES │
│ Files, records, configurations, metrics │
├─────────────────────────────────────────────────────────────┤
│ L7: RELATIONSHIPS │
│ Connections and dependencies between entities │
├─────────────────────────────────────────────────────────────┤
│ L8: INTERCONNECTIONS │
│ Cross-system dependencies and cascade impacts │
└─────────────────────────────────────────────────────────────┘
5.2 Context in Action¶
Without ICNLI Context:
User: "My website is slow"
Generic AI: "Here are common causes of slow websites:
1. Large images - optimize them
2. Too many plugins - disable unused ones
3. Server issues - contact hosting
4. Database problems - optimize tables
..."
With ICNLI Context:
User: "My website is slow"
ICNLI: "I analyzed example.com on server prod-web-01:
Found Issues:
1. ❌ PHP memory limit: 128MB (low for WooCommerce)
→ Recommend: 512MB
2. ⚠️ Database: 847 slow queries in last hour
→ 3 tables need optimization: wp_posts, wp_postmeta, wp_options
3. ⚠️ Image optimization: 23 images > 1MB
→ Total: 47MB could be reduced to ~8MB
4. ✅ Server resources: Normal (CPU 34%, RAM 58%)
Quick fix: I can increase PHP memory and optimize the database now.
This will take ~2 minutes with no downtime.
Proceed? (yes/no)"
5.3 Relationship Awareness¶
The deepest context level—relationships—enables cascade impact analysis:
User: "Delete the myapp_prod database"
ICNLI: "⚠️ CAUTION: This database has dependencies.
Deleting myapp_prod will break:
├─ example.com (WordPress site, 50K monthly visitors)
│ └─ Contact forms will stop working
│ └─ User accounts will be inaccessible
│ └─ Orders history will be lost
└─ api.example.com (Backend API)
└─ Mobile app will stop functioning
└─ 3 third-party integrations will fail
Data at risk: 2.3GB including:
- 1,247 customer accounts
- 8,934 orders
- 156 products
Last backup: 2 hours ago
This is a CRITICAL operation. To proceed, type exactly:
DELETE DATABASE myapp_prod"
5.4 Webbee Worker Intelligence¶
Historical context enables predictive capabilities:
User: "How's my server doing?"
ICNLI: "📊 Server prod-web-01 Health Report:
Current Status: 🟢 Healthy
├─ CPU: 45% (normal)
├─ RAM: 62% (normal)
├─ Disk: 67% used
⚠️ Trends & Predictions:
├─ Disk usage growing 2.3GB/week
│ └─ At this rate: Full in ~47 days
│ └─ Suggestion: Review logs or add storage
│
├─ Traffic spike expected Friday
│ └─ Based on last 4 weeks pattern
│ └─ Peak usually: 3PM-7PM UTC
│
└─ SSL certificates expiring:
└─ blog.example.com: 5 days ⚠️
└─ shop.example.com: 12 days
Recommended actions:
1. Renew SSL for blog.example.com (I can do this now)
2. Set up log rotation to save disk space
3. Consider CDN for traffic spikes
Would you like me to handle any of these?"
5.5 Intent Domain Router¶
One of ICNLI's core innovations is the Intent Domain Router — a proprietary classification layer that operates before the primary AI engine processes any request.
The fundamental challenge of a 131-tool system: presenting all capabilities to the AI simultaneously degrades precision, increases latency, and introduces noise. The Intent Domain Router solves this elegantly.
┌─────────────────────────────────────────────────────────────┐
│ USER REQUEST │
│ "Why is my WordPress site slow?" │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ INTENT DOMAIN ROUTER │
├─────────────────────────────────────────────────────────────┤
│ Classifies intent into relevant domains: │
│ │
│ ✅ Applications domain (WordPress analysis) │
│ ✅ Servers domain (resource check) │
│ ✅ Databases domain (query analysis) │
│ ❌ Billing domain (not relevant) │
│ ❌ DNS domain (not relevant) │
│ ❌ Email domain (not relevant) │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ AI ENGINE │
│ Receives: focused context + relevant tools only │
│ Result: precise, fast, accurate response │
└─────────────────────────────────────────────────────────────┘
Why this matters:
| Without Intent Domain Router | With Intent Domain Router |
|---|---|
| AI sees all 131 tools | AI sees only relevant tools |
| Generic, slower reasoning | Focused, precise reasoning |
| Higher chance of wrong tool | Domain-accurate selection |
| Higher processing cost | Optimized efficiency |
The routing logic is proprietary to ICNLI implementations. The specification only mandates that implementations MUST perform intent classification before tool selection.
5.6 Proactive User Intelligence¶
Traditional AI systems are reactive — they respond when asked. ICNLI introduces a fundamentally different paradigm: proactive intelligence.
An ICNLI-compliant system at Conformance Level 3 maintains a continuously updated User Intelligence Profile that collects contextual data about the user's infrastructure in the background — not when asked, but while the user is active in any session.
Traditional AI: ICNLI Proactive Intelligence:
User: "How are my sites?" [Background, before user asks]
System: collecting account state...
AI: "I don't know your sites. System: checking server health...
Please provide details." System: scanning SSL expiry...
System: analyzing traffic patterns...
User: "How are my sites?"
ICNLI: "Here's your full picture:
• example.com ✅ healthy
• shop.com ⚠️ SSL expires in 5 days
• blog.com 🔴 response time up 40%
I've already prepared fixes for
the SSL and the slow blog. Ready?"
The User Intelligence Profile covers 9 dimensions:
- Identity — Who the user is, their role, their history
- Account State — Billing, quotas, active services
- Service Portfolio — Everything they own
- Server Health — Real-time resource status
- Application Status — All websites, databases, apps
- Resource Inventory — DNS, SSL, files, configurations
- Relationship Map — What depends on what
- Interconnection Graph — Cross-system dependencies
- Behavioral Patterns — Trends, anomalies, predictions
The technical implementation of profile storage, refresh cycles, and collection methodology is proprietary to each ICNLI implementation.
Proactive Alerts:
ICNLI systems with active User Intelligence SHOULD proactively notify users of:
- Infrastructure anomalies detected during background collection
- Approaching resource limits (disk, quota, SSL expiry)
- Security concerns identified during monitoring
- Optimization opportunities
[No prompt from user]
ICNLI: "⚠️ Heads up: I noticed your disk on prod-server-01
is at 89% and growing ~2GB/week.
At this rate: full in ~18 days.
Quick options:
1. Clean old logs (saves ~8GB, safe)
2. Archive old backups (saves ~15GB)
3. Expand storage
Want me to start with option 1?"
This transforms ICNLI from a tool you use into an infrastructure partner that watches your back.
6. Safety by Design¶
6.1 The Safety Problem¶
AI systems with infrastructure access are powerful but dangerous. A misunderstood command could:
- Delete production databases
- Take websites offline
- Expose sensitive data
- Corrupt configurations
ICNLI addresses this with multiple safety layers.
6.2 Safety Classification¶
Every tool has a safety level:
| Level | Name | Example | Confirmation |
|---|---|---|---|
| 0 | READ | List servers, check status | None |
| 1 | SAFE_WRITE | Update email, change setting | Optional |
| 2 | WRITE | Create website, add database | Required |
| 3 | DANGEROUS | Delete files, drop database | Required + Details |
| 4 | CRITICAL | Delete server, purge backups | Explicit phrase + Cooling |
6.3 Graduated Response¶
Safety mechanisms scale with risk:
Level 0 (Read):
Level 2 (Write):
User: "Create a database"
ICNLI: "I'll create database 'newdb' on prod-web-01.
Proceed? (yes/no)"
User: "yes"
ICNLI: "✅ Database created"
Level 4 (Critical):
User: "Delete my server"
ICNLI: "⚠️ CRITICAL OPERATION ⚠️
You are about to PERMANENTLY DELETE server prod-web-01.
THIS WILL DESTROY:
- 12 websites (including example.com)
- 5 databases (15GB of data)
- 3 email accounts (2,500 emails)
- All local backups
THIS ACTION CANNOT BE UNDONE.
To confirm, type exactly: DELETE SERVER prod-web-01"
User: "DELETE SERVER prod-web-01"
ICNLI: "⏳ Server deletion will begin in 30 seconds.
Type 'CANCEL' to abort.
[=====> ] 30s remaining"
6.4 Role-Based Boundaries¶
Different user roles have different safety boundaries:
┌─────────────────────────────────────────────────────────────┐
│ ROLE PERMISSIONS │
├──────────────┬──────────────────────────────────────────────┤
│ GUEST │ Level 0 only (read) │
│ │ Cannot make any changes │
├──────────────┼──────────────────────────────────────────────┤
│ CLIENT │ Levels 0-3 │
│ │ Can manage their own resources │
│ │ Cannot delete servers or accounts │
├──────────────┼──────────────────────────────────────────────┤
│ ADMIN │ Levels 0-4 │
│ │ Full access with audit logging │
│ │ Can manage all resources │
└──────────────┴──────────────────────────────────────────────┘
6.5 Audit Trail¶
Every action is logged with full context:
{
"timestamp": "2026-01-03T10:15:30.123Z",
"actor": {
"id": "user_12345",
"name": "John Doe",
"role": "client"
},
"channel": "telegram",
"request": "Delete the old backup database",
"resolved_intent": "delete_database",
"target": "backup_old_20251201",
"safety_level": 3,
"confirmation": {
"requested": true,
"response": "yes",
"response_time_seconds": 4.2
},
"result": "success",
"duration_ms": 1247
}
7. Multi-Channel Freedom¶
7.1 The Channel Problem¶
Traditional infrastructure management ties you to specific interfaces:
- At your desk? → Use the web panel
- On mobile? → Terrible experience
- In a meeting? → Can't manage infrastructure
- Hands busy? → No option
7.2 ICNLI Channel Neutrality¶
ICNLI mandates equivalent functionality across all channels:
┌─────────────────────────────────────────────────────────────┐
│ SAME POWER │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌐 Web Same context │
│ 📱 Telegram Same tools │
│ 💬 Discord Same safety │
│ 🎤 Voice Same results │
│ 🔌 API Same audit │
│ │
└─────────────────────────────────────────────────────────────┘
7.3 Channel Examples¶
Same operation across channels:
┌─────────────────────────────────────────────────────────────┐
│ WEB INTERFACE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ You: Restart my production server │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Webbee: I'll restart server 'prod-web-01'. │ │
│ │ │ │
│ │ ⚠️ Impact: │ │
│ │ • 12 websites will be offline (~2-3 min) │ │
│ │ • 3 background jobs will restart │ │
│ │ │ │
│ │ [Confirm Restart] [Cancel] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ TELEGRAM │
├─────────────────────────────────────────────────────────────┤
│ │
│ You: Restart my production server │
│ │
│ 🤖 Webbee: │
│ I'll restart server 'prod-web-01'. │
│ │
│ ⚠️ Impact: │
│ • 12 websites will be offline (~2-3 min) │
│ • 3 background jobs will restart │
│ │
│ [✅ Confirm] [❌ Cancel] │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ VOICE │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🎤 You: "Hey Webbee, restart my production server" │
│ │
│ 🔊 Webbee: "I'll restart your production server, │
│ prod-web-01. This will take your 12 websites │
│ offline for about 2 to 3 minutes. Do you │
│ want me to proceed?" │
│ │
│ 🎤 You: "Yes, go ahead" │
│ │
│ 🔊 Webbee: "Restarting now. I'll notify you when │
│ it's back online." │
│ │
└─────────────────────────────────────────────────────────────┘
7.4 Cross-Channel Continuity¶
Context persists across channels:
[Web - Morning]
User: "I'm having issues with my WordPress site"
ICNLI: "I see example.com has some problems. Let me analyze..."
[Telegram - Afternoon, same user]
User: "Any update on my site?"
ICNLI: "Yes, continuing from this morning—I found that
your WordPress site example.com has..."
[Voice - Evening]
User: "Did you fix my website?"
ICNLI: "I've identified the issues with example.com
that we discussed today. Ready to apply fixes?"
8. Technical Architecture¶
8.1 System Architecture¶
┌─────────────────────────────────────────────────────────────┐
│ ICNLI ARCHITECTURE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ╔═══════════════════════════════════════════════════════╗ │
│ ║ CHANNELS ║ │
│ ║ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ║ │
│ ║ │ Web │ │ TG │ │ DC │ │Voice│ │ API │ ║ │
│ ║ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ║ │
│ ╚═════╪════════╪═══════╪════════╪════════╪══════════════╝ │
│ └────────┴───────┴────────┴────────┘ │
│ │ │
│ ╔══════════════════════╪═══════════════════════════════╗ │
│ ║ GATEWAY (Auth, Rate Limit, Route) ║ │
│ ╚══════════════════════╪═══════════════════════════════╝ │
│ │ │
│ ╔══════════════════════╪═══════════════════════════════╗ │
│ ║ CONTEXT AGGREGATOR ║ │
│ ║ ┌─────────────────────────────────────────────────┐ ║ │
│ ║ │ Collect: Actor → Account → Services → Servers │ ║ │
│ ║ │ → Apps → Resources → History │ ║ │
│ ║ └─────────────────────────────────────────────────┘ ║ │
│ ╚══════════════════════╪═══════════════════════════════╝ │
│ │ │
│ ╔══════════════════════╪═══════════════════════════════╗ │
│ ║ AI ENGINE (Advanced AI + Tools) ║ │
│ ║ ┌─────────────────────────────────────────────────┐ ║ │
│ ║ │ Intent Recognition → Tool Selection → Planning │ ║ │
│ ║ └─────────────────────────────────────────────────┘ ║ │
│ ╚══════════════════════╪═══════════════════════════════╝ │
│ │ │
│ ╔══════════════════════╪═══════════════════════════════╗ │
│ ║ SAFETY LAYER ║ │
│ ║ ┌─────────────────────────────────────────────────┐ ║ │
│ ║ │ Classify → Confirm → Validate → Audit │ ║ │
│ ║ └─────────────────────────────────────────────────┘ ║ │
│ ╚══════════════════════╪═══════════════════════════════╝ │
│ │ │
│ ╔══════════════════════╪═══════════════════════════════╗ │
│ ║ TOOL ORCHESTRATOR ║ │
│ ║ ┌─────────────────────────────────────────────────┐ ║ │
│ ║ │ Execute → Monitor → Report → Rollback │ ║ │
│ ║ └─────────────────────────────────────────────────┘ ║ │
│ ╚══════════════════════╪═══════════════════════════════╝ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ │ │ │ │
│ ┌─────┴─────┐ ┌──────┴─────┐ ┌──────┴─────┐ │
│ │ Server │ │ Billing │ │ Domain │ │
│ │ Control │ │ System │ │ Registry │ │
│ └───────────┘ └────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
8.2 Component Responsibilities¶
| Component | Responsibility |
|---|---|
| Channels | Receive input, deliver output, format for medium |
| Gateway | Authentication, authorization, rate limiting, routing |
| Context Aggregator | Build complete context from all data sources |
| AI Engine | Understand intent, select tools, plan execution |
| Safety Layer | Classify risk, request confirmation, validate actions |
| Tool Orchestrator | Execute operations, handle errors, report results |
| Infrastructure APIs | Actually perform operations on real infrastructure |
8.3 Data Flow¶
1. User sends message via Channel
2. Gateway authenticates and routes to Context Aggregator
3. Context Aggregator builds full context (9 levels)
4. AI Engine receives message + context
5. AI Engine determines intent and required tools
6. Safety Layer classifies operation risk
7. If confirmation needed, response sent to user
8. User confirms (or not)
9. Safety Layer validates confirmation
10. Tool Orchestrator executes operation
11. Results flow back through layers to user
12. Audit log records complete interaction
8.4 Durable Workflow Execution¶
ICNLI implementations SHOULD use durable workflow execution for:
- Long-running operations (server setup, migration)
- Multi-step workflows (create site → setup database → install CMS)
- Automatic retry on transient failures
- State recovery after system restart
┌─────────────────────────────────────────────────────────────┐
│ DURABLE WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ start_workflow("setup_wordpress_site") │
│ │ │
│ ├──▶ Activity: create_website() │
│ │ └─ Retry up to 3x on failure │
│ │ │
│ ├──▶ Activity: create_database() │
│ │ └─ Rollback website if fails │
│ │ │
│ ├──▶ Activity: install_wordpress() │
│ │ └─ Compensate: delete database, website │
│ │ │
│ ├──▶ Activity: configure_ssl() │
│ │ │
│ └──▶ Complete: return success + details │
│ │
└─────────────────────────────────────────────────────────────┘
9. Comparison with Alternatives¶
9.1 ICNLI vs Traditional Control Panels¶
| Aspect | Traditional Control Panels | ICNLI |
|---|---|---|
| Learning Curve | High (100s of features) | Natural conversation |
| Context Switching | Constant navigation | Single conversation |
| Expertise Required | Moderate-High | Low |
| Automation | Manual scripting | Natural language |
| Mobile Experience | Poor | Native |
| Bulk Operations | Click each item | "Update all sites" |
| Error Prevention | User responsibility | Built-in safety |
9.2 ICNLI vs CLI/API¶
| Aspect | CLI/API | ICNLI |
|---|---|---|
| Power | High | High |
| Discoverability | Low (read docs) | High (ask system) |
| Syntax | Exact commands | Natural language |
| Context | User provides all | System knows context |
| Safety | User responsibility | Built-in confirmation |
| Learning | Hours to days | Minutes |
9.3 ICNLI vs Generic AI Assistants¶
| Aspect | Generic AI | ICNLI |
|---|---|---|
| Language Understanding | Excellent | Excellent |
| YOUR Infrastructure Knowledge | None | Complete |
| Action Capability | Suggestions only | Real execution |
| Persistence | None | Full context |
| Safety Mechanisms | None | TWO-STEP + Levels |
| Accuracy | Generic advice | Specific to YOUR setup |
9.4 Summary Matrix¶
Ease of Use Power Context Safety Mobile
─────────── ───── ─────── ────── ──────
Control Panel ★★ ★★★★ ★★ ★★ ★
CLI/API ★ ★★★★★ ★ ★ ★
Generic AI ★★★★ ★★ ★ ★ ★★★
ICNLI ★★★★ ★★★★ ★★★★★ ★★★★★ ★★★★★
10. Use Cases¶
10.1 Small Business Owner¶
Persona: Maria runs an online boutique. No technical background.
Traditional Approach: 1. Google "how to set up email for domain" 2. Watch YouTube tutorial 3. Log into control panel 4. Navigate through menus 5. Hope she didn't break anything
With ICNLI:
Maria: "I want email addresses for my new domain shopbymaria.com"
ICNLI: "Great! I'll set up email for shopbymaria.com.
What email addresses would you like?
• info@
• orders@
• Custom address?"
Maria: "info and orders"
ICNLI: "Creating:
• info@shopbymaria.com
• orders@shopbymaria.com
I'll also configure:
✅ Spam filtering
✅ Email forwarding to your Gmail
✅ Professional security (SPF, DKIM)
Proceed? (yes/no)"
Maria: "yes"
ICNLI: "✅ Done! Your email is ready.
📧 info@shopbymaria.com
📧 orders@shopbymaria.com
I've sent setup instructions to your Gmail.
Would you like me to add these to your phone?"
10.2 Developer/DevOps¶
Persona: Alex manages 15 client websites.
Traditional Approach: - SSH into servers one by one - Run update commands - Check logs for errors - Document changes
With ICNLI:
Alex: "Update PHP to 8.3 on all production WordPress sites"
ICNLI: "Found 12 WordPress sites on 3 servers running PHP < 8.3.
Compatibility check:
✅ 9 sites ready for PHP 8.3
⚠️ 2 sites have plugins needing updates first
❌ 1 site uses deprecated functions
Recommended plan:
1. Update 9 ready sites now
2. Update plugins on 2 sites, then PHP
3. Show deprecated code in 1 site
Start with the 9 ready sites? (yes/no)"
Alex: "yes"
ICNLI: "Updating PHP on 9 sites...
✅ client1.com - PHP 8.3 ✓
✅ client2.com - PHP 8.3 ✓
✅ client3.com - PHP 8.3 ✓
...
✅ client9.com - PHP 8.3 ✓
All 9 sites updated. Average response time improved 12%.
Ready to handle the 2 sites with plugin updates?"
10.3 Emergency Response¶
Scenario: Website down at 3 AM, developer is on mobile.
[Telegram Notification]
🚨 Alert: example.com is DOWN (HTTP 500)
Developer: "What's wrong with example.com?"
ICNLI: "🔍 Analyzing example.com...
Issue found: Database connection failed
• MySQL server is running
• Too many connections (max 100, active 100)
• Long-running queries blocking pool
Root cause: Backup job + traffic spike
Last change: None in 24h
Quick fixes available:
1. Kill idle connections (instant fix)
2. Increase max connections (needs restart)
3. Kill backup job and reschedule
Recommend option 1. Proceed?"
Developer: "yes do it"
ICNLI: "✅ Killed 45 idle connections.
example.com is back online.
• Response time: 340ms
• Active connections: 55/100
Shall I:
• Set up monitoring for connection limits?
• Reschedule backup to low-traffic time?
• Add alerts for similar issues?"
10.4 Voice Control (Hands-Free)¶
Scenario: Sysadmin in server room with hands full.
👨💻: "Hey Webbee"
🔊: "Yes, I'm listening."
👨💻: "Restart the staging server"
🔊: "I'll restart staging-web-01. This will take
the 3 staging sites offline for about 2 minutes.
Say 'confirm' to proceed or 'cancel' to abort."
👨💻: "Confirm"
🔊: "Restarting staging-web-01 now.
I'll let you know when it's back online."
[2 minutes later]
🔊: "Server restart complete. All 3 staging sites
are back online and healthy."
👨💻: "Thanks"
🔊: "You're welcome. Anything else?"
11. Implementation: Webbee¶
11.1 Overview¶
Webbee is the reference implementation of ICNLI, developed for web hosting infrastructure management.
| Aspect | Details |
|---|---|
| Version | 11.1 |
| Conformance Level | 3 (Advanced) |
| Tools | 131 infrastructure operations across 22 domains |
| Channels | Web, Telegram, Discord, Voice |
| Context Depth | All 9 levels |
| Safety | Full TWO-STEP with 5 levels |
| Intent Routing | Proprietary domain router (pre-classification) |
| User Intelligence | Proactive 9-dimension profile with real-time alerts |
| Workflow Engine | ICNLI Worker (durable, fault-tolerant execution) |
11.2 Tool Categories¶
Webbee implements 131 tools across 22 operational domains:
📊 WEBBEE TOOL DISTRIBUTION
Servers (15) ████████████████ 12%
├─ server_status, server_restart, server_resources
├─ server_reboot, server_processes, server_suspend
└─ ...
Websites (18) ████████████████████ 14%
├─ website_create, website_delete, website_list
├─ website_configure, website_backup
└─ ...
Databases (12) █████████████ 9%
├─ database_create, database_delete, database_backup
├─ database_restore, database_optimize
└─ ...
DNS (10) ███████████ 8%
├─ dns_records_list, dns_record_add, dns_record_update
├─ dns_zone_export, dns_verify
└─ ...
SSL (8) █████████ 6%
├─ ssl_issue, ssl_renew, ssl_status
├─ ssl_install, ssl_csr_generate
└─ ...
Email (14) ███████████████ 11%
├─ email_create, email_delete, email_forwarders
├─ email_autoresponder, email_quota
└─ ...
Files (10) ███████████ 8%
├─ file_read, file_write, file_permissions
├─ file_manager, file_search
└─ ...
CMS (15) ████████████████ 12%
├─ wordpress_install, wordpress_plugins
├─ cms_detect, cms_backup, cms_migrate
└─ ...
Monitoring (12) █████████████ 9%
├─ traffic_stats, error_logs, uptime_check
├─ performance_report, alert_configure
└─ ...
Billing (8) █████████ 6%
├─ invoice_list, invoice_pay, balance_check
├─ service_upgrade, payment_method
└─ ...
System (6) ███████ 5%
├─ help, capabilities, feedback
├─ settings, language
└─ ...
TOTAL: 131 Tools
11.3 Architecture¶
┌─────────────────────────────────────────────────────────────┐
│ WEBBEE v11.1 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Channels │
│ ├─ Web Chat Interface │
│ ├─ Telegram Bot (@WebHostMostBot) │
│ ├─ Discord Bot │
│ └─ Voice (STT: Whisper, TTS: Custom) │
│ │
│ Gateway │
│ └─ whm-chat-proxy (Auth, Routing, Multi-tenant) │
│ │
│ Context Aggregator │
│ └─ UCG (Unified Context Gatherer) │
│ └─ Collects from Billing, Control Panel, DNS, etc. │
│ │
│ AI Engine │
│ └─ Advanced AI with 131 Function Tools │
│ │
│ Tool Execution │
│ └─ Webbee AI Worker (Durable Workflows) │
│ └─ 4 Workflows, 131 Tools │
│ │
│ Infrastructure APIs │
│ ├─ Billing System Integration │
│ ├─ Control Panel Integration │
│ └─ Domain Registry APIs │
│ │
└─────────────────────────────────────────────────────────────┘
11.4 Context Depth Example¶
Real context from Webbee:
{
"actor": {
"id": 12345,
"name": "John Doe",
"email": "john@example.com",
"role": "client",
"language": "en",
"telegram_id": 98765432
},
"account": {
"balance": 150.00,
"currency": "USD",
"services_count": 3,
"tickets_open": 0
},
"services": [
{
"id": 1001,
"name": "VPS Premium",
"status": "active",
"server": {
"hostname": "vps-12345.webhostmost.com",
"ip": "192.168.1.100",
"os": "Ubuntu 22.04",
"panel": "Web Control Panel",
"resources": {
"cpu_cores": 4,
"ram_gb": 8,
"disk_gb": 100,
"usage": {
"cpu_percent": 45,
"ram_percent": 62,
"disk_percent": 67
}
},
"websites": [
{
"domain": "example.com",
"type": "wordpress",
"php_version": "8.2",
"ssl": {
"enabled": true,
"expires": "2026-03-15",
"issuer": "Let's Encrypt"
},
"database": "example_wp",
"traffic_30d": 125000
}
],
"databases": [
{
"name": "example_wp",
"type": "mysql",
"size_mb": 450,
"tables": 52
}
],
"emails": [
{
"address": "info@example.com",
"quota_used_mb": 234,
"quota_total_mb": 1000
}
]
}
}
],
"history": {
"last_login": "2026-01-02T15:30:00Z",
"last_actions": [
"checked_server_status",
"updated_dns_record",
"created_email_account"
],
"open_issues": []
}
}
12. Open Standard Strategy¶
12.1 Why Open?¶
We believe ICNLI should be an open standard because:
- Interoperability — Different systems should speak the same language
- Trust — Users should understand how the system works
- Innovation — The community can extend and improve the specification
- Adoption — Open standards spread faster than proprietary ones
12.2 Open Core Model¶
Following successful open source projects, we propose:
┌─────────────────────────────────────────────────────────────┐
│ OPEN (Standard) │
│ │
│ • ICNLI Specification │
│ • Context Model Schema │
│ • Tool Interface Contract │
│ • TWO-STEP Protocol │
│ • Safety Classification │
│ • Conformance Test Suite │
│ • Reference Documentation │
│ │
├─────────────────────────────────────────────────────────────┤
│ COMMERCIAL (Webbee) │
│ │
│ • Full Implementation │
│ • 131 Production-Ready Tools │
│ • Multi-Channel Integration │
│ • Enterprise Features │
│ • Support & SLA │
│ • Hosting Infrastructure │
│ │
└─────────────────────────────────────────────────────────────┘
12.3 Ecosystem Vision¶
┌─────────────────┐
│ ICNLI Standard │
│ (Open Spec) │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Webbee │ │ Cloud │ │ Other │
│ Hosting │ │ Provider │ │ Vendor │
└──────────┘ └──────────┘ └──────────┘
│ │ │
│ │ │
▼ ▼ ▼
┌───────────────────────────────────────────────┐
│ ICNLI-Compatible │
│ Ecosystem │
│ │
│ • Monitoring Tools (ICNLI-aware) │
│ • Deployment Pipelines (ICNLI-integrated) │
│ • Security Scanners (ICNLI context) │
│ • Backup Solutions (ICNLI safety) │
│ │
└───────────────────────────────────────────────┘
12.4 Business Model¶
| Stream | Model | Target |
|---|---|---|
| Webbee SaaS | Subscription | SMB, Hosting Clients |
| Webbee Enterprise | License + Support | Hosting Providers |
| ICNLI Certification | Testing + Badge | Third-Party Vendors |
| Training | Courses + Certification | Developers, Admins |
13. Future Roadmap¶
13.1 Short-Term (2026)¶
- [ ] ICNLI 1.0 Specification Release
- [ ] Reference Implementation (Open Source)
- [ ] Conformance Test Suite
- [ ] Multi-Language Support (10 languages)
- [ ] Enhanced Voice Channel
13.2 Medium-Term (2027)¶
- [ ] ICNLI 2.0 with Predictive Context
- [ ] Workflow Templates Marketplace
- [ ] Third-Party Tool Ecosystem
- [ ] Mobile Native Apps
- [ ] Enterprise Features (SSO, Compliance)
13.3 Long-Term Vision¶
- [ ] ICNLI Mesh — Interconnected ICNLI systems
- [ ] Proactive Management — AI suggests actions before problems
- [ ] Natural Automation — "Set up CI/CD" creates full pipeline
- [ ] Cross-Platform Context — Unified view across providers
- [ ] Industry Extensions — ICNLI for healthcare, finance, etc.
14. Conclusion¶
14.1 What We Have Built¶
The history of computing is a history of layers.
Each layer in the stack was, at the time of its creation, misunderstood as something narrow and specific. TCP/IP was described as "a way for military computers to communicate." HTTP was described as "a document-sharing system for physicists." Both turned out to be something far larger: universal infrastructure for an entirely new era.
ICNLI was first implemented to manage web hosting infrastructure. That framing, while accurate, describes only one domain of a domain-agnostic protocol.
The correct frame is this:
ICNLI is the operating system between artificial intelligence and the real world.
It defines how any AI engine should receive structured domain awareness, how it should route intent to the appropriate capabilities, how it should analyze consequences before proposing action, and how it should execute — with a human in control, every time, without exception.
The AI engine is the brain. ICNLI is the nervous system. The domain — whatever it is — is the body.
14.2 Why This Matters Now¶
AI has reached the capability threshold. Models today understand language, reason about complex situations, and generate sophisticated responses. The bottleneck is no longer intelligence. The bottleneck is grounding — connecting that intelligence to actual, specific, real-world context — and safety — ensuring that action is taken with full awareness of consequences.
ICNLI solves both problems at the protocol level.
This is not an incremental improvement to existing systems. It is the layer that makes AI genuinely operational — not advisory, not conversational, but capable of acting within a domain with the same situational awareness that a human expert would require before making a consequential decision.
14.3 The Scope of Application¶
The protocol is domain-agnostic by design. Any system that manages complex state, serves users with varying permissions and context, and requires safe execution of consequential operations is a candidate for ICNLI implementation.
The domains are not limited. The imagination of the implementer is the only boundary.
Infrastructure management, investigative case systems, clinical decision support, financial operations, government services, logistics, manufacturing — every domain where complexity, context, and consequence intersect is a domain where ICNLI belongs.
14.4 The Invitation¶
ICNLI is an open specification. The protocol is available to any organization that wishes to implement it.
We invite:
- Domain experts — who understand a field deeply and want to make it intelligently operable
- AI engineers — who want to build systems that act with genuine awareness, not just generate responses
- Organizations — who need safe, auditable, human-in-loop AI operations at any scale
- Standards bodies — who want to help govern the evolution of this specification
14.5 Getting Started¶
- Experience it — Webbee at webhostmost.com is the reference implementation
- Read the specification — icnli.org/icnli-specification
- License and implement — contact license@icnli.org
- Build the ecosystem — the protocol is open; the domains are yours
Appendix: Glossary¶
| Term | Definition |
|---|---|
| Actor | The entity (user, service, system) making requests |
| Channel | Communication medium (web, telegram, voice, etc.) |
| Context | Complete state of user's infrastructure and session |
| Context Level | Hierarchy layer (0-8) in the context model |
| Conformance | Degree of compliance with ICNLI specification |
| ICNLI | Infrastructure Contextual Natural Language Interface |
| Mutation | Operation that changes infrastructure state |
| NLI | Natural Language Interface |
| Query | Read-only information request |
| Safety Level | Risk classification (0-4) of operations |
| Tool | Defined function that performs infrastructure operation |
| TWO-STEP | Confirmation protocol: Propose → Confirm → Execute |
| UCG | Unified Context Gatherer |
| Webbee | Reference ICNLI implementation |
Contact¶
- Creator: Valentin Scerbacov
- Creator of: ICNLI, Webbee, WebHostMost, Blue Bee Web
- Trademark Owner: Imperal, Inc.
- First production implementation: Webbee — live at webhostmost.com
- Website: icnli.org
- Email: license@icnli.org
- Reference Implementation: webhostmost.com (Webbee)
Created by Valentin Scerbacov • Imperal, Inc.
Document Version: 1.1.3
Last Updated: March 2026
Copyright: © 2026 Valentin Scerbacov / Imperal, Inc.
License: CC BY-SA 4.0
Trademark: ICNLI™ is a registered trademark of Imperal, Inc.
Legal Notice¶
This whitepaper 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.
ICNLI™ is a registered trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this document but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission.
Webbee™ is a trademark of WebHostMost.
For trademark inquiries: license@icnli.org