Execution model

Every externally observable action follows one causal path:

Event → Reducer → Effect → Driver → Event

1. Append a fact

Jixu accepts an input only after input.received is durable. The Event records what became true; it does not execute the provider or Tool.

2. Reduce deterministically

The Reducer consumes ordered Events and derives State. It may request the next Effect, but it cannot perform I/O, read a clock, generate a random ID, or call an SDK.

The same compatible Event history therefore projects the same State.

3. Persist the Effect before dispatch

A model or Tool request becomes durable before its Driver is allowed to run. This ordering gives recovery an explicit identity and request boundary.

model.requested → provider dispatch → model.completed
tool.requested  → tool dispatch     → tool.completed

Failures, cancellations, and uncertain outcomes also return as typed Events. They are not hidden inside an adapter retry loop.

4. Append the outcome

The Driver performs external work. Its bounded result is appended as another Event, then the Reducer decides what is valid next.

This keeps provider-specific protocols behind typed adapter boundaries. Core semantics do not depend on OpenAI- or Anthropic-shaped state.

What this model prevents

• A live Driver cannot be called during Replay.
• A Checkpoint cannot override Event history.
• A transient Signal cannot make a Thread complete.
• An unknown schema cannot be guessed into compatibility.
• A non-idempotent, indeterminate Effect cannot be silently retried.

Inspect the path

The Framework exposes thread.events() and thread.state(). The reference TUI exposes the same durable history through /events and the current projection through /state.