ICNLI™¶
"The operating system between artificial intelligence and the real world."
Start here. This is the simplest way to understand it.¶
Every revolution in computing started with a new foundational layer.
The operating system abstracted hardware — so anyone could write software without understanding transistors.
TCP/IP abstracted networking — so any machine could communicate without understanding routing.
HTTP abstracted communication — so any person could access information without understanding servers.
Each layer made the one below it universally accessible. Each layer unlocked an entirely new era.
ICNLI is the next layer.
It abstracts domain complexity — so any AI can act with genuine awareness of the real world it operates in.
That is the cleanest way to understand what this is.
Read the Whitepaper View Specification
ICNLI is not an AI. It is a Protocol.¶
This distinction matters more than anything else on this page.
AI models — Claude, GPT, Gemini — understand language. That is remarkable. But understanding language is not the same as understanding your world.
An AI model knows about databases in general. It does not know your database, your data, your business logic, or what changed yesterday.
An AI model can execute commands. It cannot know whether executing that command will break three other systems that depend on it.
An AI model responds when asked. It cannot watch your environment proactively and warn you before something goes wrong.
ICNLI is the protocol that solves all of this — not by making AI smarter, but by giving AI something to be smart about.
Any system that implements ICNLI gains structured, persistent, proactive awareness of its domain — whatever that domain is.
The AI is the brain. ICNLI is the nervous system. The domain is the body.
What "awareness" means¶
A traditional system — a database, an API, even a large language model — processes requests blindly. It receives input. It produces output. It has no persistent knowledge of where it is, who is asking, or what the consequences are.
ICNLI mandates a 9-Level Context Architecture that any compliant system must maintain at all times:
Without ICNLI: Request → Response
(intelligent, but blind)
With ICNLI: Request
+ WHO is asking (identity, permissions)
+ WHAT they own (account, services)
+ WHERE it runs (servers, resources)
+ WHAT depends on what (relationships)
+ WHAT the consequences are (interconnections)
→ Aware Response + Consequence-mapped Action
This is not consciousness. It is structured situational awareness — the same thing that separates a brilliant expert who knows your business from a brilliant expert who has never seen your office.
The difference is not intelligence. The difference is awareness.
Why people think Claude or other AI can do this. They can't.¶
This confusion is everywhere. People say: "I use Claude Code — it already does what you're describing."
It doesn't. Here's exactly why:
| Claude / GPT / Gemini / Claude Code | ICNLI-compliant system | |
|---|---|---|
| What it is | A language model or AI coding assistant | A protocol + its implementation |
| Can execute actions? | ✅ Yes — runs commands, edits files, calls APIs | ✅ Yes — but with mandatory structured safety |
| Knows YOUR specific system? | ❌ Only what you describe in the prompt | ✅ Knows it completely, always, before you ask |
| Context between sessions? | ❌ Starts fresh (or limited memory plugins) | ✅ Full persistent awareness across all channels |
| Watches proactively? | ❌ Waits for your prompt | ✅ Monitors and alerts before you notice problems |
| Knows real dependencies? | ❌ Reasons about what you describe | ✅ Maps actual live relationships in your system |
| Safety built into protocol? | ❌ Depends entirely on how you prompt it | ✅ TWO-STEP confirmation mandated by spec — always |
| Domain-aware tool routing? | ❌ Uses all capabilities for every request | ✅ Intent Domain Router focuses only relevant tools |
| Scope | General purpose — anything, everywhere | Deep purpose — YOUR domain, completely |
Claude Code can execute. ICNLI knows what to execute and why.
Claude Code is powerful — it can run commands, edit files, call APIs. But it acts on what you tell it in the moment. It has no persistent knowledge of your system. It doesn't know what changed yesterday, what depends on what, or what the safe approach is for your specific setup.
Ask Claude Code "is my database healthy?" — it will run some checks if you tell it how. Ask an ICNLI system the same question — it already knows, it's been watching, and it will tell you exactly what's wrong with your specific database and offer a targeted fix.
Claude Code is a brilliant assistant that executes what you describe. ICNLI is a protocol that makes any system deeply aware of what it manages — so that execution is always contextual, always safe, and never blind.
The difference is not capability. The difference is awareness.
AI models are the brain. ICNLI is the nervous system that connects that brain to reality.
The architecture of awareness¶
┌─────────────────────────────────────────────────────────────┐
│ THE REQUEST │
│ "Why is my service degraded?" │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ ICNLI CONTEXT RESOLUTION (9 Levels) │
│ │
│ L0 Platform → What system is handling this? │
│ L1 Actor → Who is asking? What are their rights? │
│ L2 Account → What do they own? What are their limits? │
│ L3 Services → What services are relevant here? │
│ L4 Servers → Which infrastructure is involved? │
│ L5 Apps → What applications are affected? │
│ L6 Resources → What specific configs/data matter? │
│ L7 Relations → What depends on what? │
│ L8 Interconn. → What are the cascade effects? │
│ │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ INTENT DOMAIN ROUTER │
│ Focuses the AI on relevant tools only (not all 131) │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ AI ENGINE (any compliant model) │
│ Receives complete context. Produces specific response. │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ SAFETY LAYER (TWO-STEP mandatory) │
│ Propose → Human approves → Execute → Audit │
└────────────────────────┬────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ RESULT │
│ "Database node 2 has 847 slow queries since 14:30. │
│ Root cause: missing index on orders table. │
│ Fix available: 2 minutes, zero downtime. │
│ Proceed?" │
└─────────────────────────────────────────────────────────────┘
From data aggregation to operational intelligence¶
Many organizations already have powerful data aggregation systems — platforms that collect and surface information from dozens of sources simultaneously. Records, patterns, networks, relationships. Enormous volumes of data, available on demand.
These systems are valuable. But they share a fundamental limitation: they are passive. They return data. They do not understand it. They do not connect it. They do not act on it. The analyst does all of that — manually, slowly, at human speed.
ICNLI transforms a passive data aggregation system into an active, aware operational platform.
Data aggregator alone: Data aggregator + ICNLI:
Returns search results. Understands results in full context.
Shows records. Maps relationships between records.
Operator reads and analyzes. System surfaces connections automatically.
Operator decides what to do. System proposes action. Operator confirms.
No pattern memory. Proactive anomaly detection and alerts.
A concrete example — investigative operations:
[Without ICNLI:]
Operator: "Search entity REF-4471"
System: 847 records returned across 6 sources.
Operator: *manually reviews for 40 minutes*
Operator: *may or may not find the relevant connection*
[With ICNLI:]
Operator: "What do we know about REF-4471?"
System: "Complete operational picture — REF-4471:
→ 3 registered variants. 2 active documentation sets.
⚠️ Relationship flag: Connected to 4 entities
with active status in separate case files.
[Relationship graph available]
📍 Location inconsistency: Source A records presence
in Region X. Administrative records show
Region Y registration. Delta: 72 hours.
🔗 Pattern similarity: Profile matches 3 closed cases
from prior period at 87% structural similarity.
Available actions:
1. Cross-reference with travel records
2. Escalate for multi-case review
3. Generate full relationship report
Proceed with any of these? [1] [2] [3] [ALL]"
The data was always there. The connections were always there. What was missing was the protocol that surfaces them, structures them, and presents them with proposed actions — while keeping the human in complete control of every decision.
ICNLI does not replace the analyst. It gives the analyst 40 minutes back.
Three examples that show why this is different¶
The 3 AM emergency¶
[Generic AI:]
You: "My service is down, what do I do?"
AI: "There are many possible reasons a service goes down.
Common causes include: overload, database issues,
network problems, configuration errors..."
[you debug for 45 minutes alone]
[ICNLI — proactive, no prompt needed:]
System: "🚨 service-prod is DOWN since 03:14
Root cause: connection pool exhausted
(100/100 active — backup job + traffic spike)
Fix: release 45 idle connections
Result: service restored in ~10 seconds, safe.
Proceed? [YES] [NO]"
You: "YES"
System: "✅ Restored. Downtime: 4 min 12 sec.
Schedule backup to 4AM to prevent recurrence?"
Bulk operations across complex systems¶
[Generic AI:]
You: "Update all production instances to latest config"
AI: "To update configurations, you should first..."
[500 word tutorial you execute manually]
[ICNLI:]
You: "Update all production instances to latest config"
System: "Found 12 production instances across 3 regions.
Compatibility check:
✅ 9 instances — safe to update now
⚠️ 2 instances — dependency conflict, update order matters
❌ 1 instance — custom override in place, needs review
Proceed with the 9 safe instances? [YES/NO]"
You: "yes"
System: "Updating...
✅ instance-01 through instance-09 — done
Performance improved avg 8%.
Ready to handle the remaining 3?"
Proactive awareness — no prompt needed¶
[Generic AI:]
*cannot do this — it watches nothing*
[ICNLI — Tuesday morning, unprompted:]
System: "Three things you should know:
⚠️ Certificate on service-api expires in 5 days
→ Can renew now, 30 seconds, no downtime
📈 Storage growing 2.3GB/week on node-01
→ At this rate: critical in 18 days
→ 12GB cleanable safely (old logs)
🔴 Payment failed for Account #8821, 2 days ago
→ Service suspension triggers tomorrow per policy
→ Send automated reminder?
Handle all three? [YES] [ONE BY ONE] [LATER]"
No one asked. The system was aware.
Any domain. Any scale. Zero limits.¶
This is the part that most people miss when they first encounter ICNLI.
ICNLI doesn't know what "hosting" is. It doesn't know what "infrastructure" means.
It only knows context levels, tools, channels, and safety rules. What you put inside those levels — that's entirely up to you.
The 9-level context model is completely domain-agnostic:
L0 What system is this?
L1 Who is asking?
L2 What do they own or control?
L3 What services/entities are relevant?
L4 What physical or virtual resources exist?
L5 What applications or processes run on them?
L6 What specific data, configs, or states matter?
L7 What are the relationships between all of this?
L8 What are the cross-system dependencies?
Fill those levels with anything. Anything.
The same protocol. Infinite worlds.¶
HOSTING INFRASTRUCTURE HOSPITAL SYSTEM
────────────────────── ───────────────
L1: Hosting client L1: Doctor / Nurse
L2: Hosting account L2: Patient record
L3: Active services L3: Active treatments
L4: Servers L4: Medical devices
L5: Websites, databases L5: Medications, procedures
L6: Files, DNS, SSL L6: Test results, vitals
L7: What depends on what L7: Drug interactions, allergies
L8: Cross-system impact L8: Cross-department effects
"Restart my database" "Adjust insulin dosage for bed 14"
→ TWO-STEP confirmation → TWO-STEP confirmation
→ Impact: 2 websites down → Impact: interacts with medication X
→ Proceed? → Proceed?
SMART CITY MILITARY OPERATIONS
────────────── ───────────────────
L1: City operator L1: Commander
L2: District / Zone L2: Unit / Division
L3: City services L3: Active operations
L4: Physical infrastructure L4: Assets, vehicles, personnel
L5: Traffic, utilities, alerts L5: Active missions
L6: Sensor data, metrics L6: Intel, coordinates, status
L7: Service dependencies L7: Chain of command, dependencies
L8: Cascade failure analysis L8: Strategic impact analysis
"There's a blackout in Zone 4" "Reposition unit Alpha"
→ System maps cascade effects → System maps strategic impact
→ Proposes: reroute + alert → Proposes: full consequence map
→ Proceed? → Proceed?
FINANCIAL TRADING SPACE OPERATIONS
───────────────── ────────────────
L1: Trader / Risk manager L1: Mission controller
L2: Portfolio / Fund L2: Mission parameters
L3: Active positions L3: Active subsystems
L4: Markets, exchanges L4: Spacecraft hardware
L5: Instruments, derivatives L5: Software, telemetry
L6: Live prices, signals L6: Sensor data, fuel, trajectory
L7: Correlated positions L7: System interdependencies
L8: Systemic risk exposure L8: Mission-critical cascades
"Close all EUR exposure" "Adjust orbital trajectory"
→ Impact: 47 positions → Impact: fuel + timing + comms
→ Market impact estimate → Full consequence analysis
→ Proceed? → Proceed?
What stays the same across every domain¶
No matter what you plug in, ICNLI guarantees:
| What stays constant | What you customize |
|---|---|
| 9-level context structure | What each level contains |
| TWO-STEP safety protocol | What counts as "dangerous" |
| Intent Domain Router | Which domains exist |
| Proactive Intelligence | What to watch proactively |
| Channel Neutrality | Which channels to support |
| Natural language interface | The language of your domain |
The protocol is the skeleton. Your domain is the flesh.
The real question is not "can ICNLI work here?"¶
The real question is: "What would change if this system was aware?"
If the answer is "everything" — then ICNLI belongs there.
A hospital where the system knows every patient, every drug interaction, every device status — and proposes actions safely.
A city where the infrastructure understands itself — and responds to problems before humans notice them.
A military command where every decision comes with full situational awareness and consequence mapping — before the order is given.
A factory where the production line is a conversation — where you say "maximize output for order #4471" and the system maps every constraint, proposes the plan, and executes it on your approval.
The only thing ICNLI cannot do is imagine the application for you.
Security and data privacy — built into the protocol¶
A common and entirely valid question: if ICNLI uses AI, does my data get sent somewhere?
The answer is no — and here is why, structurally.
Your data never leaves your domain¶
ICNLI defines an architectural boundary between your domain data and the AI engine. The protocol specifies that the AI engine receives structured, permission-filtered context — not raw database dumps, not file contents, not unstructured data.
What the AI sees is what the protocol allows it to see, shaped by the actor's role and permission level. Nothing more.
Your domain data ICNLI context layer AI engine
───────────────── ────────────────── ──────────
Raw databases → Permission-filtered → Structured
Internal records → structured context → context only
Sensitive files → Role-bounded → No raw data
PII and sensitive data — protected by design¶
The protocol mandates that implementations handle sensitive data according to the actor's authorization level. Data that an actor is not permitted to see is not passed to the AI engine. What is not in the context cannot be revealed in the response.
Implementations may additionally apply data masking, tokenization, or anonymization at the context layer — before any AI processing occurs. This is a protocol-level requirement, not an afterthought.
Every action requires human confirmation¶
The TWO-STEP protocol is not optional. It is mandatory for every operation that changes state.
No ICNLI-compliant system can execute a consequential action without explicit human confirmation. The AI proposes. The human decides. This is enforced at the architectural level — not by policy, not by UI design, but by the protocol specification itself.
Complete audit trail — always¶
Every interaction in an ICNLI-compliant system is logged with:
- Actor identity and authentication method
- Full context at the time of the request
- Exact action proposed and confirmed
- Result of execution
- Timestamp and session reference
Nothing happens without a record. Every decision is traceable to the human who made it.
On-premise deployment — fully supported¶
The ICNLI protocol does not require cloud infrastructure. Implementations may run entirely within a private network, air-gapped environment, or government-certified infrastructure. The protocol defines behavior, not deployment topology.
Your data can remain entirely within your own controlled environment.
The principle in one sentence¶
ICNLI brings intelligence to your data. It does not bring your data to the intelligence.
Key innovations in this protocol¶
| Innovation | What it defines |
|---|---|
| 9-Level Context Model | The mandatory structure for contextual awareness |
| Intent Domain Router | How to focus AI on what matters for each specific request |
| Proactive User Intelligence | How systems should build and maintain awareness before being asked |
| TWO-STEP Safety Protocol | The mandatory confirmation architecture for any state-changing operation |
| Channel Neutrality | How identical capabilities must be delivered across all interfaces |
| ICNLI Worker | How long-running operations must be executed with durability and fault tolerance |
Reference Implementation¶
Webbee 🐝 by WebHostMost is the first production ICNLI implementation — running live, serving real clients, managing real infrastructure.
| Tools | 131 infrastructure operations |
| Domains | 22 operational domains |
| Channels | Web, Telegram, Discord, Voice |
| Context | All 9 levels |
| Version | 11.1 |
Created By¶
Valentin Scerbacov — Creator of ICNLI, Webbee, WebHostMost, and Blue Bee Web
Imperal, Inc. — Owner of the ICNLI™ registered trademark
First production implementation: Webbee — running live at webhostmost.com
Licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
ICNLI™ is a registered trademark of Imperal, Inc. Webbee™ is a trademark of WebHostMost.