Arbol

Arbol is a public architecture for making useful work repeatable without making it opaque or uncontrolled. It is built from small Unix-like units: each unit has one job, a clear contract, and a result that can be inspected.

The architecture

Arbol has three primitives that compose upward:

Action → Pipeline → Flow

Primitive	Responsibility	Boundary
Action	Do one thing.	Defined input, output, and failure behavior.
Pipeline	Compose Actions and pass structured context.	Ordered steps with visible handoffs.
Flow	Bind a Pipeline to a schedule or event and route a bounded result.	Declared trigger, result, and destination.

This is a composition model, not a mandate for open-ended agency. Each layer narrows the work it owns and makes the next layer’s responsibility explicit.

Actions

An Action is the smallest useful unit of execution. It does one thing: apply a rule, validate a value, transform structured input, route a result, store a record, or check a condition.

A good Action has a small contract:

• It states what it accepts.

• It states what it returns.

• It makes failure observable.

• It does not silently take on neighboring responsibilities.

Small Actions are easier to test, reuse, and replace. They also make a larger system understandable without requiring a reader to infer hidden behavior.

Pipelines

A Pipeline is a readable composition of Actions. It passes structured context from one Action to the next so each step can add its contribution without discarding what matters.

structured input → validate → transform → check → structured result

The handoff is part of the design. A Pipeline should make it clear which step produced each piece of context, what the next step is allowed to depend on, and what happens when a check fails. That clarity turns a multi-step process into something inspectable rather than a monolith.

Flows

A Flow binds a Pipeline to the moment it becomes useful: a schedule or an event. It then routes one bounded result through its declared outcome.

A Flow answers four questions in advance:

1. What triggers this work?
2. Which Pipeline runs?
3. What result may leave the Pipeline?
4. How is that result checked and routed?

The boundary matters. A Flow runs the work that was specified; it does not expand its own remit, create arbitrary follow-on work, or act without an explicit route.

Deterministic work first

Arbol treats deterministic work as the default. Rules, validation, routing, storage, and checking should have defined behavior that can be repeated and inspected. This is the work that benefits most from small composable units because it should remain stable under repetition.

Verification belongs in the architecture, not at the end as a hope. A result can be checked against its contract before it is routed onward, and a failure can remain visible instead of being silently converted into a plausible-looking output.

Bounded model judgment

Some steps need judgment rather than a fixed rule. A model can be useful there, but it belongs inside an explicit contract:

• Input: the structured context the model may use.

• Output: the result shape it must produce.

• Boundary: the decision it may make, and the decisions it may not make.

• Verification: the check that follows before the result is used.

This keeps semi-deterministic work honest. A model may classify, summarize, compare, or recommend within a defined step. It is not an uncontrolled autonomous actor.

What Arbol makes possible

The result is work that is triggered, repeatable, inspectable, and continuously useful. A person can see what starts it, trace how context moves through it, inspect what came out, and improve a single Action without rebuilding the whole system.

Arbol’s purpose is not to automate everything. It is to make the right bounded work reliable enough to run again.