diff --git a/MANIFEST.md b/MANIFEST.md
new file mode 100644
index 0000000..f780271
--- /dev/null
+++ b/MANIFEST.md
@@ -0,0 +1,94 @@
+## Technical Overview
+
+### Core Architecture and Memory Management
+
+The Elyz architecture is built on a strict separation of physical resource ownership and logical resource management, where the kernel acts as a passive arbiter that verifies digital signatures in the form of descriptors. All memory within the system is represented as objects with precise ownership tracking—pages, regions, or segments—and each such object is always tied to a unique owner: a process or the kernel. The owner holds a strong reference, guaranteeing the object's existence until the hierarchical reference counter with per-CPU-core local pools drops to zero, which eliminates cache misses and bus conflicts during metadata updates.
+
+Support for **revocable capabilities** allows for the forced revocation of rights via descriptor aliases: the kernel instantly invalidates access at the hardware level using Process-Context Identifiers (PCID) without traversing the ownership tree. Processes never operate with direct physical addresses; instead, they work through lightweight descriptor tokens that define access rights and the relationship type (strong, borrowed, or transferred).
+
+### Distributed Actor Model
+
+The distributed actor model (replacing a single PM) represents a network of independent PM actors that communicate asynchronously through lock-free message queues. They receive initial memory capital from the bootloader and distribute it without bottlenecks, utilizing **lazy allocation** (on-demand space reservation via page fault) and **ballooning** for the dynamic redistribution of unused memory.
+
+> **The Asynchrony Tax:** While lock-free queues minimize locking, handling a page fault via asynchronous message passing to a PM actor inherently carries higher latency than a direct, synchronous interrupt handler call in a monolithic Linux kernel.
+
+### Process Lifecycle and Optimization
+
+When an application needs to launch, it requests raw memory from PM actors, which carve it into functional objects—thread blocks and descriptor tables. To minimize overhead, an intelligent system call **batching** mechanism is implemented: requests are grouped into queues, reducing the frequency of context switches.
+
+This batching compromise introduces a baseline delay (**latency floor**) for non-critical tasks: the system appears incredibly smooth in real-time processes (multimedia and input utilize high-priority immediate-execution flags), but "raw" synthetic single-thread computation speed may lag behind Linux.
+
+### The elibc Layer
+
+To free developers from manual management, `elibc` is provided as a dynamic shared library (`libelibc.so`) with a standardized POSIX-like ABI based on `musl libc` for full portability. The translation layer inside `elibc` is optimized so that a C programmer sees the familiar `malloc`/`fork` functions, which are transparently converted into native `allocate`/`clone` calls with direct FFI-bindings for Rust/Go, avoiding double context switches.
+
+When a program requires memory, `elibc` requests a strong descriptor from the Virtual Memory Manager (within the actor model), and the kernel configures the MMU directly after the reference is created, achieving hardware speeds without intermediaries. The results of descriptor verifications are cached in parallel with the TLB, making subsequent accesses practically free.
+
+### Compatibility Layer (WinServer)
+
+For a Wine analogue, the key element is the **Personality Server (WinServer)**, which emulates Windows logic within actor isolation, supporting specific WinAPI primitives through dedicated descriptor subsystems. Thanks to descriptors, performance is maximized via borrowing, transferring, and instant revoking: instead of copying data, it performs **zero-copy** transfers of memory rights.
+
+* **Example:** When rendering a frame, the application transfers the graphics buffer descriptor to the server, or the PM actors project shared memory. Upon timeout or frame completion, access is revoked at the MMU/TLB level, followed by background lazy cleanup.
+* **Failure Handling:** If a Wine application crashes, the actor-supervision mechanism automatically cascades and annuls all related descriptors, instantly returning resources to the pool and preventing rights fragmentation.
+
+### Architectural Summary
+
+In this hierarchy:
+
+* **The Kernel** is an accountant, verifying links and rights through hardware caches without diving into the logic.
+* **The Process** is an isolated safe with descriptor-keys stored inside its wallet.
+* **Wine** is an overseer, translating external instructions into memory bank checks.
+
+The combination of the actor model, revocable capabilities, and PCID-caching allows for the local "bankruptcy" of any individual component (driver/emulator) without affecting the rest of the system. The balance between performance and convenience is achieved by hiding complex ownership mechanics inside `elibc`, preserving a familiar development style while maintaining architectural reliability at a seL4 level.
+
+### Focus Mode Feature
+
+Elyz includes a dedicated feature for manual priority management, allowing either the user or a program (via API access) to determine which actor or process receives more attention. Alternatively, users can enable **"focus mode"**, where only one selected process executes (along with its dependencies and child processes) while everything else "freezes."
+
+It does not stop; it freezes—once focus mode is deactivated, all operations resume. This serves as a developer tool designed to make compiling exceptionally heavy programs faster and easier directly under Elyz.
+
+---
+
+## Philosophy: Nomarchy
+
+### PART I. Philosophical Pillars (Elyz Axioms)
+
+#### 1. Separation of Ownership from Management
+
+In UNIX, the right to perform an action stems from identity (User ID). In Elyz, there are no identities—only assets and rights. A physical resource belongs to whoever created or received it, but logical management is delegated to a distributed network of entities. The system lives in a paradigm of separation of powers: executors (actors) manage, while the arbiter (the kernel) merely stamps digital signatures.
+
+#### 2. Principle of Total Accounting and Zero Trust
+
+Every byte of memory, every register, and every quantum of CPU time has a specific, legally bound owner. Security is not a fence around the system; it is the isolation of every single molecule within it. Resources can never be "ownerless" or "shared by default."
+
+#### 3. Ephemerality and Revocability of Rights
+
+No granted right is permanent. All trust in Elyz is a temporary loan. The ability to instantly, uncompromisingly, and via cascade annualize any permission at the hardware level is more critical than the procedure used to grant it.
+
+#### 4. Pragmatic Dualism (Architecture for robots, interface for humans)
+
+A mathematically sound and strict kernel should not make the programmer suffer. Elyz separates internal chaos from external aesthetics: under the hood lies a highly complex hierarchy of descriptors and asynchronous actors, but externally, the system must present the friendly face of classic POSIX. Rigid security must not compromise ergonomics.
+
+---
+
+### PART II. Strict System Rules (Laws of the Kernel and Environment)
+
+* **Rule 1. The Kernel is a Passive Accountant**
+The Elyz kernel is deaf and blind to application business logic. It does not know what a "text editor," a "video stream," or a "game" is. Its sole task is to verify the validity of tokens (descriptors), check reference counters, and toggle MMU levers. The kernel never initiates memory management processes on its own—it only executes the will of the actors, provided it is verified by a signature.
+* **Rule 2. Everything is an Object of Ownership (Replacing UNIX "Everything is a file")**
+The "everything is a file" concept is obsolete. In Elyz, everything is an object with a strong reference. A thread, a memory region, a page, a descriptor—these are all objects. An object exists precisely as long as its distributed reference counter is alive. When the counter drops to zero, the object is instantly and traceably erased from the physical world by the local CPU core pool.
+* **Rule 3. Isolation via the Descriptor Wallet**
+A process has no eyes to see physical memory and no hands to reach it. A process is a blind safe containing a wallet filled with lightweight tokens (descriptors).
+* *Want to write data?* Show the token.
+* *Want to transfer data?* Hand over the token (transfer) or let them hold it (borrow).
+* *Attempting to access a direct address* is a system crime punished by the immediate destruction of the context.
+
+
+* **Rule 4. Decentralization of Power (Anti-PM)**
+There is no single point of failure in the system. Instead of a monolithic Process and Memory Manager (as seen in UNIX/Linux), Elyz is governed by a federation of independent, asynchronous PM Actors. They communicate via lock-free message queues. If one actor misbehaves or becomes overloaded, the remaining actors continue carving out memory and distributing starting capital. The local bankruptcy of a component does not lead to the collapse of the state.
+* **Rule 5. Zero-Copy via Rights Migration**
+Copying bytes from user space to kernel space or between processes is an archaic overhead. Data must remain stationary. Only the rights to the data move. Passing a graphics frame or a network packet is an instantaneous tectonic shift of descriptors within the MMU/TLB tables. Ownership changes hands at the speed of CPU thought.
+* **Rule 6. The Batching Compromise (Intelligent Batching)**
+A system call is an expensive luxury. Elyz forbids processes from poking the kernel for every minor operation. Requests are packed into queues and sent in bulk (batching). However, the system knows the cost of delays: media streams (audio, frames, real-time input) are marked with an "Execute Immediately!" flag, bypassing the general queue.
+* **Rule 7. Personalities are Simply Isolated Guests**
+Elyz lacks native support for Windows, Linux, or macOS. Supporting other operating systems does not involve dirty hacks inside the kernel. Instead, isolated Personality Servers (such as WinServer) are used. To Elyz, a foreign OS is just another overseer actor that takes Elyz resources and translates them into a language the guest application understands. If the guest "dies," the actor-supervision mechanism cascades to annualize all its checks, returning memory to the pool without a single drop of fragmentation.