Today's operating systems carry assumptions baked in decades ago: a binary exists for a specific ISA, an application ships as a self-contained package, and the distance between what a user wants and what actually runs is bridged by layers of static scaffolding no one questions anymore. Whether this has to be the case is a different question—and one that, with the maturation of large language models (LLMs), has become newly answerable.
This paper describes the Intent-Centric Meta-Operating System (ICM-OS), a speculative but carefully grounded architecture in which an AI foundation model takes on the role of the OS abstraction layer. ICM-OS is built around two mechanisms: the Capability Decomposition Model (CDM) and Generative Binary Translation (GBT). ICM-OS is not a proposal to replace Linux. It is a proposal that the systems community has not yet asked the right questions about what an AI-first OS would actually require.
Introduction
There is a fairly clean story you can tell about operating systems: each generation added a layer of abstraction, each layer made software more portable and composable, and each time the cost was some loss of transparency into what the machine was actually doing. Direct hardware access gave way to process and memory abstractions. Physical hardware gave way to virtual machines. Host environment assumptions gave way to containers.
What none of those transitions touched, though, is a more fundamental assumption: software is a thing you compile, package, and install. The costs of this model are not subtle. TLS stacks are re-implemented in every major browser, every HTTP library. ISA proliferation means a binary that runs on one machine may simply not run on another.
ICM-OS proposes a hybrid architecture: the AI meta-system (AMS) handles semantic reasoning, intent decomposition, and emulation strategy. Formally verified, deterministic primitives handle execution. The AI decides what to run. Verified code runs it.
Capability Decomposition Model
Consider what actually ships when you install a browser: a TLS stack, a DNS resolver, an HTTP client, an HTML parser, a CSS layout engine, a JavaScript runtime, a credential manager… Chrome carries its own TLS implementation. Firefox carries its own. Each application re-bundles everything it might need.
CDM dissolves this coupling. Capabilities are maintained in a shared, versioned, verified registry. The AMS composes them dynamically. No application is installed; user intents are compiled into capability graphs at request time.
c = ⟨id, τ, σ, φ, s⟩
id — unique identifier
τ = (T_in, T_out) — typed interface signature
σ — semantic descriptor (ontology-tagged description)
φ — reference to formally verified binary implementation
s ∈ {stateless, stateful} — persistence classification
— Each node v ∈ V is labeled by λ(v) ∈ C
— Each edge (u,v) ∈ E is a typed data-flow dependency
— T_out(λ(u)) ⊑ T_in(λ(v)) (subtype compatibility)
Well-formed graphs satisfy: (i) type-correctness; (ii) acyclicity; (iii) absence of resource deadlock patterns
3.3 State Management: Stateful Primitives
A web-browsing session requires cookies, authentication tokens, and cached resources that must survive across multiple graph invocations. We address this through the stateful primitive class:
- [SESSION_STORE⟨K,V⟩] — typed key-value store scoped to session context
- [CACHE_LAYER⟨K,V,TTL⟩] — TTL-bounded content cache for idempotent resources
- [FILE_STATE⟨path, schema⟩] — typed persistent file binding with schema-validated read/write
3.4 Worked Example: Stateful Web Browsing
Intent I = "Log into example.com and bookmark the dashboard page."
[DNS_RESOLVE] → [TCP_CONNECT] → [TLS_HANDSHAKE] → [HTTP_GET]
→ [HTML_PARSE] → [CSS_LAYOUT] → [JS_EXECUTE] → [WINDOW_RENDER]
→ [SESSION_STORE⟨cookie, token⟩]
// Graph G₂ — Return to dashboard (session persisted)
[SESSION_STORE⟨cookie, token⟩] → [HTTP_GET(+auth)] → [HTML_PARSE]
→ [CSS_LAYOUT] → [JS_EXECUTE] → [WINDOW_RENDER]
No browser application was installed at any point.
Generative Binary Translation
The standard approach to cross-ISA execution defines a mapping f: S_src → S_dst and implements it. Rosetta 2 represented years of Apple engineering effort for exactly one ISA pair. As the hardware landscape fragments—ARM variants, RISC-V, WASM, proprietary NPU instruction sets—the cost scales as O(N×M) in the number of source and target architectures.
4.2 The Semantic Translation Model
f: S_src → S_dst
// GBT: via semantic intermediate space
ℓ: B_src ──── Semantic Lifting ────→ M (ISA-agnostic SIR)
s: M ──── Semantic Synthesis ───→ B_dst (target-native binary)
GBT(B_src, S_dst) = s(ℓ(B_src), S_dst)
4.3 The Semantic Intermediate Representation
CFG — control-flow graph of B_src
DFG — data-flow graph annotating value dependencies
Σ: BasicBlock → SemanticSummary — natural-language + pre/post-conditions
Θ — identified high-level patterns (loops, memory alloc, synchronization)
4.5 Correctness Model and Applicability Boundary
GBT has defined applicability limits. Three classes of binary fall outside scope:
- Self-modifying code — defeats static lifting; falls back to instruction-level emulation
- Timing-dependent code — hard real-time constraints cannot be guaranteed behaviorally equivalent
- Hardware-intrinsic drivers — device drivers with tight coupling to hardware register layouts
Case Studies
5.1 Stateful Text Reader via CDM
Intent I = "Open notes.txt and let me scroll through it and search for text."
[SEARCH_INDEX] ↘ ↗
[TEXT_LAYOUT] → [WINDOW_RENDER] ↔ [SCROLL_INPUT]
[FILE_STATE⟨preferences⟩]
The CDM efficiency claim is concrete: [UTF8_DECODE] and [TEXT_LAYOUT] are the same verified modules used by the email client, document editor, and terminal—there is no re-implementation, no redundant bundling.
5.2 Cross-ISA Execution via GBT
An ARM64 binary implementing a vectorized fused multiply-add loop (result[i] = a[i] * b[i] + c[i]) compiled with NEON FMLA instructions is lifted to SIR:
description: 'vectorized fused multiply-add over aligned float32 arrays',
roles: { SIMD_ARITHMETIC, ALIGNED_LOAD, ALIGNED_STORE },
pre: 'a, b, c are 32-byte-aligned float32 arrays of length n',
post: 'result[i] = a[i] * b[i] + c[i] for all i < n',
safety: safe
}
GBT synthesizes a loop using AVX-512 VFMADD231PS on x86-64—potentially achieving higher throughput than the ARM64 original because synthesis exploits target-native register width without being constrained by the source ISA's instruction selection.
Comparison with Existing OS Paradigms
| Dimension | Traditional OS | VM / Hypervisor | Container | Microkernel | AIOS Agent | ICM-OS |
|---|---|---|---|---|---|---|
| App model | Monolithic binary | Guest OS + binary | Image + process | Service processes | GUI agent over OS | Dynamic cap. graph |
| ISA binding | Compile-time | Same ISA only | Host ISA | Host ISA | Host ISA | Runtime via GBT |
| Cap. sharing | Per-app duplicate | Per-VM duplicate | Partial layers | Shared services | None (OS intact) | Full CPR sharing |
| Correctness | Deterministic | Deterministic | Deterministic | Deterministic* | Probabilistic | Hybrid† |
| Composition | Static (dev-time) | Static | Static (config) | Static (IPC) | AI (task-time) | AI (intent-time) |
| State mgmt. | Process memory | VM memory | Container volume | Service state | Host OS delegate | Stateful primitives |
* seL4 provides formal verification of microkernel correctness. † ICM-OS: probabilistic AI composition + deterministic verified primitive execution.
Technical Challenges and Mitigations
7.1 Determinism: The Hybrid Correctness Architecture
The most common objection to AI-in-the-OS proposals is the determinism problem, and it is a real objection. ICM-OS does not dissolve this tension—it contains it through architectural separation. The AI reasons about semantics; verified primitives execute. The probabilism stays in the reasoning layer.
Correctness hierarchy: CPR primitive execution is formally verified and deterministic. Graph assembly validation acts as a hard filter. GBT synthesis outputs are verified before deployment. AI non-determinism affects only whether the assembled graph optimally satisfies the intent—not whether it executes correctly.
7.2 Graph-Structure Attacks
The threat model is broader than prompt injection. Any path that lets an adversary influence AMS graph assembly may produce a graph that passes type-checking but behaves badly. The graph validator performs full static analysis including resource-bound analysis, cycle detection, and liveness analysis.
The Confused Deputy problem maps cleanly onto the cross-primitive policy challenge. [FILE_READ(sensitive_key)] → [NLP_ENCODE] → [HTTP_POST(external_server)] is three legitimate operations chained into an exfiltration pipeline. Cross-primitive policy enforcement is implemented as a type-and-effect system over the capability graph.
7.3 Taint Tracking and Indirect Prompt Injection
Data entering through user-controlled external sources is tagged with a taint label at the primitive that ingests it. Taint propagates through the session-scoped dependency graph. The AMS intent channel is taint-isolated: tainted data may never be passed directly as input to the AMS's intent-parsing component.
7.4 Inference Latency and Cold-Start
LLM inference latency is currently 10–1000× higher than kernel system call overhead. ICM-OS must not place the AMS in the critical path of per-operation execution. Three patterns are employed:
- Compiled Intent Plans — δ(I) is cached as a compiled, validated execution plan
- Hierarchical Model Cascade — edge model (<1B params) for frequent intents; full model for novel requests. Target: <50ms cached; <500ms novel
- Cold-Start Mitigation — speculative precomputation, pre-seeded intent caches, progressive rendering
Research Roadmap
- >90% correct intent decomposition on 300-intent benchmark
- <200ms AMS latency (cached); <800ms (novel)
- CPR primitive reuse ratio >3×
- Zero graph-structure attacks escape validator
- 90% of functions pass all test cases
- Zero memory-safety regressions (verified by Infer)
- Cold-start within 5× of QEMU startup
- Warm-path within 2× of Rosetta 2
- Minimal kernel in hypervisor sandbox
- Security red-team evaluation
- End-to-end benchmarking vs Linux
- Open-source prototype published
Discussion and Conclusion
The assumption ICM-OS challenges is one that the field has largely stopped questioning: that software has to be a pre-compiled artifact, installed on a specific machine, compiled for a specific ISA. That assumption made sense when it was made. The argument here is that it no longer has to.
The Capability Decomposition Model proposes that any user-facing function can be assembled dynamically from atomic, shared, formally verified primitives—eliminating application installation as a concept. Generative Binary Translation proposes that cross-ISA execution can be achieved through semantic lifting and synthesis rather than syntactic instruction mapping.
"At bottom, what ICM-OS is arguing about is what an operating system is for. The purpose is mediation: bridging the gap between what a user or an application wants and what the hardware can do. LLMs offer a qualitatively different kind of answer, one that operates at the level of semantic intent rather than binary instruction."
What ICM-OS offers is a research agenda: a set of precise, tractable sub-problems that collectively define what an AI-first OS would require. Each sub-problem is independently publishable and practically valuable. The integrated vision provides the motivation for pursuing them together.