Runtime Design Principles
These principles govern every implementation decision in ElastOS Runtime. When two choices both work technically, the one that better satisfies these principles wins.
1. Capsules Over Monoliths
Each function is a separate capsule: separate repo, separate CID, separate developers. The core runtime stays "boring" like Bitcoin Core -- only changes under extreme scrutiny.
Storage is a capsule. Networking is a capsule. The desktop is a capsule. Each app is its own capsule. Each AI agent is its own capsule. Each capsule has its own version number and can be updated independently. If you fix a bug in the media player capsule, nothing else changes.
2. Mechanism, Not Policy
The Carrier layer enforces tokens. The Shell decides who gets tokens. Separating enforcement from decision-making means you can upgrade the policy brain (shell) without touching the trust base.
This is a microkernel design principle: the runtime provides the mechanism for security enforcement, but the policy decisions ("should this app get access?") are made by the shell capsule, which itself can be upgraded, replaced, or even made intelligent (AI agent shell) without changing the trusted core.
3. Actor Equality
Humans and AI agents are treated identically. Same capability tokens, same sandboxes, same audit trail. No shortcuts for agents, no second-class treatment either.
A person using the shell and an AI agent running in the background both operate under the same capability model. Both must hold valid tokens for every action. Both are subject to the same scoping, expiration, and revocation rules. Both produce the same audit trail.
4. Content-Addressed Everything
Every capsule, every piece of content, every update is identified by its cryptographic hash (CID). "Which version?" is never ambiguous.
Content addressing removes the possibility of silent substitution. If someone gives you a CID, you can verify that the content you received matches exactly. This applies to capsule binaries, shared files, published sites, and update packages.
5. Zero Ambient Authority
Every capsule starts with zero permissions. Must explicitly request and receive signed tokens to do anything -- read a file, open a socket, talk to another capsule.
Most operating systems and application platforms start with broad access. An installed app can typically read large parts of the filesystem, make arbitrary network requests, and access system services without asking. ElastOS Runtime takes the opposite approach: no access by default, explicit grants for everything, fail-closed when a token is missing.