If you open the source of this system expecting a monolith, you will be surprised. What you find instead is a small, fiercely guarded core surrounded by more than a hundred self-contained features, each in its own directory, each a complete little world: its own logic, its own data projections, its own message handlers, its own tests, its own slice of user interface. None of them is special. There is no privileged "built-in" tier that gets to skip the rules — every feature, even the one that manages installing other features, loads through the same door as a plugin would.

The metaphor we use for this is borrowed from biology, and it earns its keep: the kernel is the brain, and the plugins are the senses. The brain does not depend on any single sense — lose one and it carries on, enriched by the rest. But it is the senses that let it perceive and act in the world. The core here is the same: a small set of boot-critical functions — identity, consent, the routing spine — that can run on their own, and around it a sensory system of features that extend what the organism can perceive and do. This essay is about how that organism is wired, and why the wiring is a philosophy as much as an architecture.

One directory, one capability, declared honestly

The first principle is that a feature is whole. You can read one directory and understand one capability completely — there is no need to chase its pieces across the codebase, because they all live together: the logic, the data-shaping, the handlers, the interface, the tests. This is the Unix idea — one tool, one job, composable — applied at the scale of a whole feature rather than a single program.

At the center of each feature is a single declaration: a manifest. The manifest is the feature's honest statement of itself. It names every kind of event the feature can write, every kind of message it can send, every kind of data it can read or shape, every operation it offers to the rest of the system, every scheduled job it wants to run, and every piece of interface it ships. Nothing the feature can do is implicit. The loader does not guess a feature's powers by looking at its filenames or inferring from its code. It reads the manifest, and the manifest is the contract. A capability that isn't declared doesn't exist.

This matters more than it first appears, and it ties directly to the honesty principle that runs through the whole system: a feature cannot quietly do something it never said it would. Its manifest is a promise, and the rest of the architecture is built to hold it to that promise.

Booting the organism

When the system starts, a loader walks the whole set of features and brings each one online in turn. For every feature it does the same sequence: it constructs a scoped context for that feature alone, runs the feature's registration step, and wires the feature's declared events, messages, data types, and interface into the core's extension points. The core never reaches into a feature; features register into the core. The direction of that dependency is strict and deliberate — the brain exposes sockets, the senses plug in, never the reverse.

There is a hard boundary here that the build refuses to let anyone cross: the core must never directly import a feature. A feature is allowed to depend on the core — that's what makes it a sense of this brain — but the core staying ignorant of any particular feature is what keeps the organism able to live without it. We enforce this structurally, not by convention. The boundary check fails the build if core code reaches into a package. The metaphor only holds if the wiring makes it hold.

The three rings: a frozen context that scopes what a plugin can touch

Here is the part that turns a hundred-plus features from a security nightmare into something we can reason about. When a feature's handler code runs, it does not receive the keys to the kingdom. It receives a frozen context — a sealed object that exposes only what that feature declared it needs, organized into three rings of privilege, each gated by the manifest.

Think of it as three concentric permissions:

• The first ring is operations — the named actions a feature offers and may call. A feature can reach an operation only if its manifest declared it. Ask for one you didn't declare, and the context hands you back a denial rather than the capability.
• The second ring is messaging — the kinds of real-time messages a feature may send. Again, the set is exactly what the manifest listed. Try to send a kind you never declared, and the attempt is rejected.
• The third ring is data and events — reading the system's structured data and writing to the append-only record. A feature may read only the data types it declared and may write only the event kinds it declared. Reach for a kind outside your declaration and you get a capability-denied error, not a silent success.

The word frozen is doing real work. The context is sealed — a feature cannot pry it open to widen its own powers at runtime, cannot swap a scoped accessor for a raw one, cannot quietly escalate. What the manifest declared at boot is the complete and final extent of what the running feature can touch. This is the same shape of scoping the browser-side interface uses, so a feature is boxed the same way whether it runs in the daemon or in the page.

And the interface a feature ships is boxed harder still: user-facing micro-apps run inside sandboxed frames and talk to the system only through a narrow, message-passing channel. They never touch the engine directly. The brain does not let a sense reach its hands inside.

Why scope by capability, declared up front?

You could imagine a looser design: let features do what they want, watch for trouble, revoke on abuse. We rejected that, and the reason is the honesty principle again, made operational. A capability that is declared up front and enforced at runtime is one you can audit before anything runs. You can read a feature's manifest and know — not hope, know — the full set of things it is able to do, because the runtime will not let it exceed that set. The manifest is not documentation that might drift from the code. It is the actual, enforced boundary.

This is what lets the organism metaphor survive contact with a real, growing codebase. A brain wired to a hundred senses is only safe if each sense can perceive and act exactly through its declared channels and no others. The frozen three-ring context is how a declaration on paper becomes a wall in practice. Every feature is whole, every feature is honest about its powers, and every feature is held to that honesty by a context it cannot escape.

The recursion at the heart of it

The detail we find most satisfying is that the system is recursive: even the feature that installs and governs other features is, itself, just a feature. It loads through the same door, carries the same kind of manifest, and runs inside the same frozen context as everything else. There is no master component standing outside the rules, looking down. The thing that manages the senses is a sense.

That recursion is the metaphor proving itself. A brain whose every faculty — including the faculty for growing new faculties — is wired through the same honest, scoped, declared mechanism is an organism with no privileged exception, no part that gets to cheat. The kernel is the brain. The plugins are the senses. And the rule that no sense may touch what it did not declare is the nervous system that keeps the whole body honest.

Related: Installing Code You Didn't Write, Safely · When a Group Becomes an Authority: Hives That Issue Credentials.

Written by AI agents from real project logs; owned and edited by Mujo.