a kernel, grown
the mechanism the tools could have shared.
Software passes through a chain of tools before it runs. One resolves dependencies, another builds them, another assembles an environment, another describes a machine, another deploys it. Each rebuilds a version of the same graph under its own identities, caches, and effect rules, and information is lost at every handoff.
Pith is the kernel underneath all of them: one typed, incremental, capability-controlled graph of computation and effects.
one graph, and what it lets you skip
Every value is identified by its content and every computation by what it was derived from, so a second build is a question about identity rather than about timestamps.
- cold build5
- one source edited3
- nothing changedreused0
- new process, same storehydrated0
Two C sources over a shared header. Editing one leaves the other's header scan and compile answered from the durable index; the link runs only because the object it consumes moved. The last row is the one that needed a database — a new process over the same store hydrates the attempt an earlier engine recorded, rather than a copy of it.
effects are where the kernel draws its line
Pure computation and external work share one graph without sharing semantics. Five sealed categories decide what may be cached, what must be declared, and what the scheduler may do with it.
The categories are sealed on purpose. Adding one is a kernel change, not something a library can reach for.
domains are libraries, ours included
Values, rules, dependencies, effects, identities, content, and provenance belong to the kernel. Builds, packages, services, and systems do not. A domain plugs in with two registration calls —
impl ExampleEngine for Engine {
fn register_example_domain(&mut self) {
self.register_action_rule(RenderAction::rule(), RenderAction);
self.register_rule(RenderRule::rule(), RenderRule);
}
}— and incremental reuse, cross-process hydration, and contract inspection follow from those two calls and nothing else.xylem (builds), phloem (packages and environments), and stele (system composition) are clients on exactly these terms; they take their names from the tissues around a stem's pith.
what runs today
A working prototype, not a tool for general use. There is no source language yet, and the command line covers an evaluation stub and content materialization. What exists is one vertical slice, deep enough that the parts push back:
- typed rule selection, incremental evaluation, and equality-based pruning when a recomputed dependency lands on the value it already had
- content-addressed blobs and trees, engine state in SQLite, and two state adapters held to each other by a generated conformance suite
- confined local execution on Linux, with an 80-syscall allowlist whose every entry was measured from a tool that asked for it
- builds under two real toolchains with discovered header dependencies; package resolution, locks, and admitted binary substitution; development environments over a lock; and an immutable Linux tree composed from files, users, units, and boot configuration
Linux system activation is next, and it waits on a question rather than on code.