Arbol
An execution layer built from small Unix-like composable units.
Arbol is LifeOS’s execution layer: a way to turn a useful piece of work into a small system that can run again without becoming a black box. It takes the Unix idea seriously. Small units have clear jobs, compose through a shared contract, and leave work visible enough to inspect.
Why it exists
Useful work often starts as a one-off: collect something, validate it, make a decision, put the result where it belongs. Repeating that by hand is wasteful; handing it to an unconstrained agent is worse. The missing middle is a system that can run when needed, do only the work it was designed to do, and make its result easy to check.
Arbol exists for that middle. It makes recurring execution explicit: what starts the work, what each step receives and returns, where the result may go, and how success is verified.
How it works
Arbol composes three primitives upward:
Actions are the smallest useful unit. An Action applies one deterministic rule, validates a payload, routes a result, stores a record, or checks a condition. Its contract is narrow enough that you can understand its input, output, and failure case without reading the rest of the system.
Pipelines connect Actions without flattening their context. Each step receives the structured result of the prior work, adds only what it is responsible for, and passes a coherent result onward. That makes a multi-step process readable as a composition rather than a single opaque procedure.
Flows make a Pipeline continuously useful. A Flow binds it to a trigger — a schedule or an event — and routes only a bounded result to its declared destination. A Flow is not permission for the system to invent more work; it is the explicit boundary around work that has already been designed.
Deterministic work and judgment
Most operational work should be deterministic: apply rules, validate, route, store, and check. These steps are repeatable precisely because the same input should produce the same behavior, with a result that can be inspected later.
Some work genuinely needs a model’s judgment. Arbol keeps that judgment bounded too. A model step names its input, its expected output, the decision boundary it may cross, and the verification that follows. The model can classify, summarize, compare, or recommend inside that contract; it does not gain an open-ended mandate to act.
Where it fits
Arbol gives LifeOS a dependable way to carry useful work beyond a single interaction. The Algorithm defines and verifies what done means; Arbol runs bounded pieces of that work when their trigger arrives. Together they make work triggered, repeatable, inspectable, and continuously useful — without mistaking automation for uncontrolled autonomy.
What it feels like
Work you used to redo by hand starts arriving already done, and — this is the part that matters — you can still see inside it. When a result looks off, you read the run: which step, which input, which decision. Fixing it means changing one Action, not re-prompting a black box and hoping. Over time you accumulate a shelf of small, trusted machines, each one boring in exactly the way infrastructure should be.