Runtime·Deterministic processing

Runtime

Deterministic processing

Given the same document and the same events, any compliant processor derives the same result. This is the core guarantee that makes Blue a protocol, not just an app.

Why this matters

Without determinism, Blue would just be a nice language plus a trust story plus some runtime implementations. With determinism, Blue becomes something much stronger:

  • an interaction can be processed independently by multiple parties
  • they can still converge on the same state
  • the rules become portable
Determinism is why Blue can be a protocol, not just an app.

Inputs and outputs

Every processing pass takes:

  • Document state — the current Blue document.
  • One new timeline entry — typically a Conversation/Timeline Entry wrapping a Conversation/Operation Request.

And produces:

  • Next document state — the same shape, with state updated according to the rules.
  • Triggered events — events emitted by workflow steps that other contracts can react to.
  • Total gas — actual compute consumed by the pass.
  • Capability failure flag — set when the processor encounters a contract type it does not understand. Honest failure, not silent skipping.

Processing algorithm (sketch)

  1. Initialize on first run: load contracts, register channels, fire the lifecycle event, write the initialized marker (this is the document's epoch 0).
  2. Receive a new timeline entry.
  3. Route through channels. For each channel contract, the channel processor decides whether the entry matches and may produce a delivery for handlers.
  4. Match handlers. Sequential workflow handlers and operation handlers are evaluated against the channelized event.
  5. Run workflow steps. Steps execute in order — typically Conversation/Update Document, Conversation/Trigger Event, or Conversation/JavaScript Code — using a deterministic JSON Patch and a deterministic JS runtime.
  6. Apply patches. Apply state updates atomically.
  7. Emit triggered events. Workflow steps may push events into a triggered-event channel that other contracts (in the same document) can react to in the same pass.
  8. Update checkpoints. Channel checkpoints record the most recent processed entry per channel, so re-running the same processor on the same entries does nothing extra.

What an "epoch" is

An epoch is one processing pass: the document goes from one consistent state to the next, all triggered events are drained, all checkpoints advance. The document stepper numbers epochs starting at 0 (initialization) and increments on every entry you submit.

Why timelines matter here

Timelines are not just audit logs. They are part of the reason deterministic processing is possible:

  • they provide attributed actions
  • they provide ordered entries
  • timeline providers provide guarantees around completeness and ordering

This is one reason the timelines white paper matters so much.

Determinism does not mean "everything is simple"

A process may still be very rich:

  • many participants
  • many channels
  • workflows and conditions
  • embedded documents
  • triggered operations

What determinism means is that the result is not left to hidden platform behavior.

The stepper is this page made interactive. Open the document stepper to watch initialization, channel routing, workflow steps, state diffs, triggered events, and gas usage on every epoch.