JIXU DOCUMENTATION
Core model
The small set of concepts that define Jixu.
Jixu uses one term for one responsibility. These boundaries are the foundation of every API and every durable transition.
| Concept | Responsibility |
|---|---|
| Harness | Owns exactly one immutable Agent and binds Stores and Drivers to the Kernel. It is not durable authority. |
| Agent | Immutable instructions, model identity, capabilities, Tools, Skills, and Context Policy. |
| Thread | One durable, multi-turn history for that Agent. |
| Event | An immutable durable fact appended to a Thread. |
| State | The deterministic projection of ordered Events. |
| Reducer | Pure domain logic that derives State and requests Effects. |
| Effect | A durable request for external work. |
| Driver | The adapter that performs an Effect and returns an outcome. |
| Tool | A capability that acts outside the Kernel. |
| Plan | Optional Event-backed coordination data for one Agent's current execution hypothesis. It never performs or authorizes work. |
| Signal | A transient observation for presentation; never authority. |
| Checkpoint | A disposable recovery cache; never authority. |
| Replay | Rebuild State from Events without performing Effects. |
| Fork | Create a new child Thread from an explicit parent Event. |
One Agent per Harness
An Agent is frozen before Thread creation. Its model capability profile and Context Policy become part of the durable compatibility boundary.
If an application needs a different Agent, it creates a different Harness. A Thread never changes Agent identity halfway through its history.
One authority per Thread
The Event log is the only canonical history. Provider state, UI state, traces, in-memory objects, Signals, and Checkpoints may help Jixu operate or explain itself, but none of them can decide the durable truth.
That rule prevents two components from independently deciding whether a request ran, whether a Tool completed, or whether a Thread is safe to continue.
State is a projection
State can be deleted and rebuilt from Events. It contains the current lifecycle, messages, active Plan, pending Effects, mode, metrics, and recovery boundary, but it is not edited directly.
const state = await thread.state();
const rebuilt = await thread.replay();Both values must describe the same durable Thread. Replay reaches that result without live external work.
A Plan is coordination, not execution
An active Plan helps one Agent keep non-trivial work aligned with its objective, evidence, blockers, and next safe action. It remains part of the same Thread State and the same Event history.
A Plan cannot dispatch an Effect, approve a Tool, widen user scope, or create another lifecycle. The ordinary Event → Reducer → Effect → Driver → Event path remains the only way work happens. See Execution Plans for revision and recovery semantics.